HA Floating IP cim /30 as subneten

Linux-kezdő

Hello!

Van 2 debian szerverunk, publikus IP cimen. Node A es Node B. A ket szerver nek van 1 darab Floating IP je, ami szinten a publikus neten figyel.

KB 10 darab /30 as kis haloztatot szeretnenk a szerverekkel szurni. Mindegyikben lenne 1 szerver, es 1 db Gateway.

Van arra mod, hogy Floating IP-t hasznaljunk a 2 node kozott es beleferjunk a /30 as subnetbe? Valahogy csak a floating IP interface-et huzzuk fel a 2 node kozott, es ne legyen kulon cim node-onkent abban a subnetben ahol a szerver van?

Lehet picit bonyolult a kerdes, de remelem valaki erteni fogja :)

Koszi!

  • 929 megtekintés

( bAndie9100 | 2020. 07. 30., cs – 17:21 )

egy interfészre fel tudsz venni több ip címet is. teszem azt,

node A: eth0 -> 10.0.1.2/30, 10.10.0.1/24

node B: eth0 -> 10.10.0.2/24

ahol 10.0.1.0/30 az mini subnet, 10.10.0.0/24 egy másik subnet mondjuk adminisztratív célokra, és a 10.0.1.2 a floating IP ebben a subnetben.

erre gondolsz?

Igen nagyjabol erre.

csak az a furcsasag, hogy a /30 as subnetben nem tudok meg 2 cimet felvenni a 2 node nak. Csak a floating van. Ez igy mukodhet? Hogy fogom felhuzni azt a floating cimet a 10.0.1.2/30 ba ha nincs benne csak 2 hasznalhato, es az HA-ban hogy fog “vandorolni” az eppen aktiv node-ra, NodeA es NodeB kozott?

( Mcsiv v | 2020. 07. 30., cs – 17:40 )

Lehet hogy én nem vagyok képben, de a floating ip önmagában nem mond semmit azon felül, hogy egy megadott ip cím a node-ok között vándorolhat és azok gondoskodnak arról, hogy az arp announcing megfelelően végigmenjen a hálózaton ha váltás van.

Az alapján amit mondtál, te CARP-ot használsz (de lehet még ez is téves következtetés). Lehet egyszerűbb ha onnan indulunk, mi a jelenlegi beállítás :)

// Happy debugging, suckers
#define true (rand() > 10)

Jelenleg nincs semmi meg.

A floating IP hez 3 cim kell:

1.) NodeA

2.) NodeB

3.) Floating IP
 

a /30 al viszont csak 2 cim hasznalhato. Az egyiet szeretnenk a floating IP re a masiknak pedig egy Host ot, amin mondjuk web szerver futna. Vagy ftp, vagy mind1 mi.

a Floating Ip-t szeretnenk hasznalni gateway kent, hogy redundansan legyen megoldva a /30 as subnet.

 

Nagyjabol ez lenne.

Ahogy fentebb leírták, neked CARP-ra van szükséged!
Mivel OS-t nem írtál, nézd meg hogy adott OS-nál ez hogyan van implementálva.

WAN, és LAN oldalakon is fel kell húznod egy CARP interface-t, erre fogod a "floating IP"-ket konfigurálni.
Ha ügyesebben akarod megoldani, és adott OS tudja, akkor WAN oldalon a forgalmat szinkronizálod (states), erre kell egy dedikált interface a két gép közé. Ebben az esetben master node kiesése esetén minden kapcsolat szakadás nélkül átvándorol backup node-ra.

Amiket még ilyenkor érdemes megoldani:

- DHCP szinkronizálása (ha van)
- VPN szinkronizálása (ha van)
- valamilyen daemon ami CARP-on felül figyeli master->backup váltást, szükség esetén bizonyos szolgáltatásokat backup elindítt, majd leállít.

Vannak OS-ok amik a fentieket csuklóból tudják, pl. OpenBSD (carp, pfsync, sasync, ifstated, dhcpd, ....)

Ami még fontos, WAN és LAN oldalon se legyenek szűrve mulicast csomagok! (WAN oldalon előfordul hogy szolgáltató szűri)

Irtam, hogy 2 debian van tervben.

De meg mindig nem ertem, hogy akkor csak egy interface-t huzok fel mind a 2 gepen a CRAP-nak. pl eth0:1 es valojaban eth0 meg csak ures es ott "csucsul"

A ket gepet meg ossze tudjuk kotni egy kabellel is hogy a szinkronizalas meglegyen egy dedikalt interface-en.

Ezt a peldat neztem:

https://debian-administration.org/article/678/Virtual_IP_addresses_with…

Ezek szerint a CARP interface-nek meg mindig kell egy fizikai interface, amire IP-t kell felhuzni. es pont ez a gond... hogy a /30 as subnetben nem tudunk majd kiosztani 2 ipt a ket node nak, 1 et a CARP nak es 1 et meg a HOST nak ami abban a subnetben van.

Vagy meg lehet ugy is oldani a configot, hogy eth0-ra nem huzok fel ipt-, csak be van kotve, es csak a CARP nak van egy IP-je ami vandorol?

# /etc/network/interfaces
# ..

# The primary network interface
auto eth0
iface eth0 inet static
address  <EZT A RESZ URES>
netmask  <EZT A RESZ URES>
gateway  <EZT A RESZ URES>

  #######################
  # ucarp configuration
  #######################
  ucarp-vid      1
  ucarp-vip      1.2.3.4
  ucarp-password mypass32
  ucarp-advskew  1
  ucarp-advbase  1
  ucarp-master   no

# The carp network interface, on top of eth0
iface eth0:ucarp inet static
        address 1.2.3.4
        netmask 255.255.255.252

CARP, VRRP, … és társaik egy virtuális interface-t hoznak létre, az minden egyes member-en fent van. (akár 2-nél több member is lehet!).
Súlyozással határozod meg hogy melyik a master, melyik a slave/backup interface.
A virtuális interface-ek fizikai interface-re „bind”-elnek, de ettől még a fizikai interface-en is lehet pl. dedikált IP cím.
A carp member-ek egymás között multicast csomagokkal kommunikálnak, minden CARP-nak van egy ID-je, és normális esetben egy jelszava. Itt beszélik meg hogy látják-e egymást, ha valamiért szétszakadnak, akkor backup gépen, master állapotra fog váltani a CAPR interface.
Tehát innentől ott van az IP címed, ha van a két gép között csomag állapot szinkronizáció, akkor a meglévő kapcsolataid sem szakadnak!

Nagyon sok jó leírás, videó, etc … van erről neten.
Keress rá, hozz létre valamilyen virtuális környezetben egy teszt rendszert és próbáld ki.

Egyszerű mint a faék!

Amire figyelni kell!
Ha egy CARP interface állapota változik, akkor azon a gépen lévő többi CARP-nak is illik vele mennie.
Tehát ha pl. WAN oldali CARP master A gépről átkerül B gépre, akkor a LAN oldali CARP interface(ek)-nek is utána kell mennie!

( bazso | 2020. 07. 31., p – 07:37 )

Ez valami nagyon zöld, védjük az IP-ket mozgalom? Legyél bátor és pazarló, szerencsére a belső IP-k újra felhasználhatók ;)

Ha ez hálózatos vizsgafeladat, akkor szép kérdés, le a kalappal. Ha nem, akkor egyszerűbb elkerülni a problémát. 

1. /29

2. Ha mindenképpen /30, akkor vidd alsóbb szintre a belépő pont redundanciáját - egy db virtuális gép, ami tud sétálni az 1db IP-jével együtt

( hunti v | 2020. 08. 01., szo – 09:39 )

Ha spórolni akarsz a publikus ip címmel, nem kell publikus ip címmel megoldani a routolást, GW címe lehet bármi akár privát ip cím is, a kliens pedig használhat egyetlen /32-es publikus IP címet, ugyan ehhez manuálisan kell beállítanod a routingot a kliens gépen, pl linuxon:

auto eth0
iface eth0 inet static
        address 87.229.115.255
        netmask 255.255.255.255
        up ip ro add 172.16.0.1 dev eth0
        up ip ro add default via 172.16.0.1

Ugyan nem mostanában csináltam ilyet, pár évvel ezelőtt egy korábbi melóhelyen kellett, de akkor működött a linuxokon, freebsd-n, és windowson is (utóbbin nem kellett semmi extra mágia, csak beállítani a GW-t). A hátránya ennek a megoldásnak, hogy tudtommal nem lehet pl DHCP-n kiadni az IP címeket a statikus routing szabályok miatt, viszont ha külön privát IP címeket használsz mindenhova, akkor később egyszerűbb lesz skálázni, ugyanis könnyű lesz ezt a float IP-t átrakni más GW-re.

( tibby | 2020. 12. 01., k – 23:20 )

Hat valahogy ez nem akar mukodni.

Ahogy latom az a problema, hogy ens224-nek nincs dedikat ip cime, ami mell felhuzna keepalived a virtualis cimet, es pont ez a problema, hogy nem szeretnenk minden subneten 2 cimet a 2 node-nak, es 1 et keepalived nek, es meg a kliensnek, es meg a networknek is...

Soval meg lehet ezt oldani ugy is, hogy csak a keepalived cime figyel aktivan ens224-en mind a ket node-on ?

 

Node1:

etc/network/interfaces

allow-hotplug ens224
iface ens224 inet manual

/etc/keepalived/keepalived.conf

vrrp_instance VI_1 {
    state MASTER
    interface ens224
    virtual_router_id 101
    priority 101
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.10.121
    }
}

 

Node2:

etc/network/interfaces

allow-hotplug ens224
iface ens224 inet manual

/etc/keepalived/keepalived.conf

vrrp_instance VI_1 {
    state MASTER
    interface ens224
    virtual_router_id 101
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.10.121
    }

 

service keepalived status

Dec 01 15:06:00 Node1 Keepalived[542]: Running on Linux 4.19.0-12-amd64 #1 SMP Debian 4.19.152-1 (2020-10-18) (built for Linux 4.18.20)
Dec 01 15:06:00 Node1 Keepalived[542]: Command line: '/usr/sbin/keepalived' '--dont-fork'
Dec 01 15:06:00 Node1 Keepalived[542]: Opening file '/etc/keepalived/keepalived.conf'.
Dec 01 15:06:00 Node1 Keepalived[542]: Starting VRRP child process, pid=569
Dec 01 15:06:00 Node1 Keepalived_vrrp[569]: Registering Kernel netlink reflector
Dec 01 15:06:00 Node1 Keepalived_vrrp[569]: Registering Kernel netlink command channel
Dec 01 15:06:00 Node1 Keepalived_vrrp[569]: Opening file '/etc/keepalived/keepalived.conf'.
Dec 01 15:06:00 Node1 Keepalived_vrrp[569]: (VI_1) Cannot find an IP address to use for interface ens224
Dec 01 15:06:00 Node1 Keepalived_vrrp[569]: (VI_1) entering FAULT state
Dec 01 15:06:00 Node1 Keepalived_vrrp[569]: Registering gratuitous ARP shared channel

VLAN nem okoz problémát, ott alinterfészeket használsz és kész (eth0.100 stb..). Egyébként még multicast támogatás sem szükséges, mert Keepalived támogatja az unicast kommunikációt is, csak be kell konfigurálni. A VRRP által használt adminisztratív IP címek között pedig titkosíthatod a forgalmat például IPSec-el (transport mode) és mást nem fogadsz el.

KOSZONOM!
Ezzel a sorral sikerult megoldani! Nem kell a Keepalived-vel sem az UCARP-el taknyolnom.

Siman full egyszeruen csak felhuzom Heartbeat-nek a haresources-ben az ip-t amit hasznalni szeretnek, es fizikainak meg megadom a CGNAT-ot.

Full egyszeru az IPTABLES szabalyokat csinalni rajuk, es tokkeletesen mukodik!

KOSZI MEG 1x! :D