redundans internet - megint - hackery a kobon :/

Naszoval koltoztunk, mivel mindenki otthonrol dolgozik igy bekotottunk 2 szolgaltatotol internetet, hogy majd primary/backup modon fut mindegyik.
Elso problema akkor jott amikor megprobaltam atrakni a CPE-t brdige modeba. Szolgaltato 1 rogton kozolte, hogy mivel van rajta egyeb szolgaltatas ezert nem lehet bridge modeba rakni, az o routeruknek kell route/natolni es az o routeruk kell, hogy a /24-ben (nem megvaltoztathato) o legyen a .1-es ipcim. Egyik router se tud semmilyen routing protocolt (statik routeot beleertve) ezert sok opcio nem volt. Futottam egy par kort a ket szolgaltatonal hatha lehetne valamit megiscsak megoldani de mindenki kozolte, hogy ez nem standard config es nem supported. Ami teljesen jogos, mert ha minden hozzam hasonlo idiotat supportalni kellene akor minden DSL es 56k dialup melle jonne egy bgp session full bgp tablaval, mert miert is ne:D

Mivel az egyik CPE mar igy van gondoltam, legalabb tartsuk szimmetrikusan a dolgot ezert a masodik szolgaltato CPE-jet is hasonlo felallasban hagytam.

A megoldasom a problemara mikrotikkel a netmap nevezetu dolog volt ami annyit tesz, hogy 1:1-ben natolja a dolgokat. Szoval volt a szolgaltato 1, 192.168.1.0/24-es subnettel, szolgaltato 2, 192.168.2.0/24-es subnettel es volt az en lanom ami meg 192.168.88.0/24 subnettel tarsult. Szoval egyszeruen beallitottam a dolgokat, hogy ha a kimeno interface a szolgaltato1 fele mutat akor az 192.168.1.0/24-re src netmapeljen, ha szolgaltato2 fele akkor meg 192.168.2.0/24-re src netmappeljen es vica versa, amikor szolgaltato1 vagy szolgaltato2 feloli interfacen jon a csomag akkor a 192.168.88.1 subnetre dst netmappoljon.

beallitottam szepen, a kimeno nat (src nat) szabalynal a counter ment szepen felfele, de a bejovo nat (dst nat) nem akart az istennek se felszokkeni. Nemi troubleshooting utan kiderult, hogy a problema nem a NAT szabalyokban van hanem (drumroll please) az ARP-ban keresendo. Mivel a csomag utja igy nez ki amikor probalunk az internet fele menni (src lan ip 192.168.88.254, dst 8.8.8.8):
192.168.88.254-es gepnek megvan adva default gw-nek, hogy 192.168.88.1, szoval szepen kuldi is a csomagot a routernek miutan arp-al megkerdezi, hogy mi a mac-cime az 192.168.88.1-nek ha nem lenne benne az arp tablajaban.
router megnezi, hogy merre mutata a default route, szolgaltato1 fele, vegrehajtja a src nat-tot es az src ip: 192.168.88.254 dst ip 8.8.8.8 csomagot netmappolja src ip: 192.168.1.254 dst ip 8.8.8-ra, es kuldi is a csomagot a szolgaltato1 CPE (192.168.1.1) fele, ha kell megkerdezi arppal, hogy megis mi az 192.168.1.1 gw mac-cime.
szolgaltato 1 cpe-je natolja a wan ipre es jon vissza a csomag, szolgaltato1 CPE-je natolja visszafele es megerkezik a csomag:
src ip 8.8.8.8 dst ip: 192.168.1.254, es itt jon a problema, mivel a szolgaltato1 CPE-je nem tudja, hogy megis milyen maccimet kellene rakni, hogy elerje az 192.168.1.254-ipt. Mivel ez papiron a lanon van, ezert kikuldi az ARP kerest, de mivel a mikrotik ami src/dst natolna nem gondolja, hogy neki kellene erre valaszolni nem is teszi azt ami teljesen logikus.

Erre a problemara nyujt megoldast a proxy-arp dolog amit altalaban senki nem szeret, teljes joggal, mert tud csunyasagokat csinalni, de nekem pont ez kell. Be is kapcsoltam a proxy-arp-ot a ket szolgaltato fele meni interfacen de, ahhoz, hogy a proxy-arp csinaljon is valamit, a routernek azt kell gondolnia, hogy o jobban tudja, hogy merre kellene menni, szoval kell egy more-specific route a routing tablaba, ami nem a szolgaltato1-2 fele mutat. Sok opcio van, lehet masodlagos IP cimet felrakni az 192.168.88.1 melle (192.168.1.128/25, 192.168.2.128/25) es akkor a masodik /25 hasznalhato a /24-bol, static discard routeot berakni miutan a szolgaltato1-2 fele nezo labakat beraktuk staticba, stb.

Ezutan mar "csak" a failure detectiont kell megoldani, valami tavolabbi ip-cimen. Erre van a netwatch nevu valami bar nem ugy tunik, hogy azzal lehet kezelni a flappeket ami egy korabbi szolgaltatonal relative gyakori volt. ha ezt a reszet is kitalaltam irok kovetkezo bejegyzest.

( sj | 2016. 10. 15., szo – 15:24 )

(kocsog on) a statikus route-olas az nem routing protokoll (kocsog off). Amugy nice job!

--
Te!
Annyira gyulolod a BlackPanthert!
En meg ezert gyullolek! NIncs ra szo!
Le se szarlak! Erted budos goreny?! (abalole, a 20062. user)

( SPYFF v | 2016. 10. 15., szo – 21:05 )

Két más jellegű, bár széleskörben kevésbé kipróbált/elterjedt megolást is megnézhetsz esetleg (nyílván akkor főleg ha szeretsz kísérletezni). Az egyik fejlesztésébe én is kontributáltam szóval név szerint lehet majd szidni ami nem kis előny ha bedől a cucc :-)

1. MPTCP-t supportáló kernel. Alapból kezeli a multihomingot, tud backup patht fenntartani, ha az eredeti lehal, akkor elég seamless (kb. 1-2 RTT idő alatt) átvált backupra és nem szakad meg a session. Hátránya, hogy csak TCP-t tud, ami UDP-t használ az megy simán default gw-n. Ez már elég mature egyébként, használják több helyen éles szolgáltatói környezetben.

2. MPT (Multi-Path Tunnel). Egy egyszerű tool, ha van több gatewayed (ha jól értem itt adott kettő a két szolgáltatóval) akkor beállíthatsz egy olyan VPN tunnel interfészt, ami a kettő között beállított súlyok alapján felosztja a csomagokat. Pl. 1:10000 ahol minden tízezredik csomag megy a backup pathon. Ez dinamikusan vezérelhető a mellékelt toolal, path-ok le és felkapcsolhatók menet közben, így nem mennek el hosszabb flowok sem. Automatikus failover is van, kb. 1-2 másodperc alatt tudja detektálni ha lehal egy út (szimpla keepalive-death timer alapú, mint pl. az OSPF-nél)
Hátránya ennek, hogy a forrsákód még nem áll olyan állapotban hogy közzétegyem, (pedig ez a cél év végéig az Androidos verziójával együtt), így csak binárist meg konfig fájlokat/manualt tudok küldeni ha érdekel.
De lehet találni a neten hasonló bár jóval funckiószegényebb de legalább nyílt forrású megoldásokat.

( kalebris | 2016. 10. 18., k – 12:25 )

Annyival "egyszerusudott" a konfig, hogy a backup szolgaltatot atraktam 192.168.0.0/24-re, valamint atallitottam az mikrotik 2 labat, dhcp-rol staticra es nem /24-re hanem /27-ra valamint a masodlagos ipcim a LAN-on atkerult 192.168.1.254/23-ra, szoval az elso /27-on kivul barmi hasznalhato a lanon.

( kalebris | 2016. 10. 18., k – 11:24 )

Es elkeszult a dynamikus failover script, ezuttal kicsit tobbet gondolkoztam mielott lekodoltam az elso sort, szoval kicsit normalisabb lett a dolog, meg azert sokat jelent az, hogy nem kell PBR-ezni allandoan.

Szoval mikrotik Script 1, ami bootolaskor fut, es beallitja a globalis dolgokat: 


:global PrimaryInterfaceName "primary-5"
:global BackupInterfaceName "backup-4"
:global PrimaryDNS "x.x.x.x"
:global BackupDNS "y.y.y.y,z.z.z.z"
:global target 8.8.8.8
:global FailOver 5
:global FailBack 30
:global PingCount 5
:global PrimaryHistory 0
:global BackupHistory 0
:global AdminDistanceTieBreaker 30

Az AdminDistanceTieBreaker arra hasznalatos, hogy eldontsem, hogy eppen most active vagy passziv a primary route, ha active akkor kisebb, ha nem aktiv akkor pedig nagyobb az admin distance mint 30.

Aztan kovetkezik a poller, ami 5 masodpercenkent pingel, annyival van kiegeszitve a config, hogy letrehoztam egy primary es egy backup routing tablat amiben csak a megfelelo default routeok vannak benne: 


:global target
:global PingCount
:global PrimaryInterfaceName
:global BackupInterfaceName
:global PrimaryHistory
:global BackupHistory
:global PrimaryPing [:tonum [/ping address=$target interface=$PrimaryInterfaceName count=$PingCount interval 1s routing-table=primary]];
:global BackupPing [:tonum [/ping address=$target interface=$BackupInterfaceName count=$PingCount interval 1s routing-table=backup]];

:put $PrimaryPing
:put $BackupPing

if ($PrimaryPing < $PingCount) do={
 if ($PrimaryHistory > 0) do={
   :set PrimaryHistory -1
 } else={
   :set PrimaryHistory ($PrimaryHistory-1)
 } 
} else={
 if ($PrimaryHistory < 0) do={
   :set PrimaryHistory 1
 } else={
   :set PrimaryHistory ($PrimaryHistory+1)
 } 
}
if ($BackupPing < $PingCount) do={
 if ($BackupHistory > 0) do={
   :set BackupHistory -1
 } else={
   :set BackupHistory ($BackupHistory-1)
 }
} else={
 if ($BackupHistory < 0) do={
   :set BackupHistory 1
 } else={
   :set BackupHistory ($BackupHistory+1)
 } 
}

Egyszeru mint egy faek, pingel mindket interfacerol es novel/csokkent egy countert. 


:global FailOver
:global FailBack
:global BackupDNS
:global BackupInterfaceName
:global BackupPing
:global BackupHistory
:global PrimaryPing
:global PrimaryDNS
:global PrimaryInterfaceName
:global PrimaryHistory
:global PingCount
:global AdminDistanceTieBreaker

if ($PrimaryHistory < $FailOver) do={
 :set $PrimaryRouteID [ ip route find dst-address=0.0.0.0/0 gateway~$PrimaryInterfaceName ];
 if ([ip route get $PrimaryRouteID distance] < $AdminDistanceTieBreaker ) do={
  ip route set $PrimaryRouteID distance=($AdminDistanceTieBreaker+10)
  :log info "Default route belonging to $PrimaryInterfaceName has it's admin distance increased"
  ip dns set servers=$BackupDNS
 }
}

if ($PrimaryHistory > $FailBack) do={
 :set $PrimaryRouteID [ ip route find dst-address=0.0.0.0/0 gateway~$PrimaryInterfaceName ];
 if ([ip route get $PrimaryRouteID distance] > $AdminDistanceTieBreaker) do={
  ip route set $PrimaryRouteID distance=($AdminDistanceTieBreaker-10);
  :log info "Default route belonging to $PrimaryInterfaceName has it's admin distance decreased";
  ip dns set servers=$PrimaryDNS;
 }
}

Itt pedig a valos failover dolog, ez se bonyolultabb a faeknel, annyira kell odafigyelni, hogy amikor a primary default admin distance megno akkor a dns-t at kell allitani a backupra es vissza.