ISP-k vagy technológiák közötti váltás, aktív kapcsolatok szakadása nélkül

Hálózatok általános

Sziasztok!

Adott egy cég, ahol Vodafone/UPC adja kábelneten a netet. Ez évekig rendben volt, most viszont naponta többször szakad, kezdeni még nem tudtak vele semmit, viszont beszerzésre került emiatt multiwan-os router és mobilstick is, hogy ne álljon meg addig sem az élet.

A gond az, hogy az alkalmazottak mindenféle VPN-hez vannak csattanva, rengeteg aktív kapcsolatuk van, s egy ilyen szakadásnál minden behal, s kezdhetik elölről a kapcsolatok felépítését stb (jó esetben ez automatikusan megtörténik). Ez igen zavaró, s erre keresnék megoldást.

Pont a Vodafone/UPC egyébként kínál úgynevezett "Mobiladat backup kiegészítő szolgáltatás"-t, ahol ilyeneket állítanak:
- Zavartalan munkavégzést tesz lehetővé, segítségével biztosított a folyamatos és stabil adatkapcsolat.
- Automatikus, néhány másodpercen belüli átállást biztosít a másodlagos hálózatra, IP cím változás nélkül.
Viszont az a gond, hogy 10Mbit/sec a letöltési és 3Mbit/sec a feltöltési maximum, ami enyhén szólva használhatatlan ennek a cégnek, s egyelőre még nem találtam megoldást arra, hogy esetleg lehetne ezen a sávszélességen növelni.

Node a lényeg az az, hogy milyen egyéb lehetőségeim vannak a probléma megoldására? Legjobb lenne dobozos megoldás (vagy ha van, aki ilyet kialakít), mert ilyen témakörökben azért túlzott tapasztalat/tudás nincsen. Olvastam, hogy van BGP meg minden, de azt se tudom, hogy mi fán terem :-)
A legjobb az lenne, ha maradna a Vodafone/UPC fövonalként, s lenne mellette egy másik szolgáltató (mobilinternet lesz egyelőre valószínűleg, mert nem nagyon van egyéb lehetőség, ami megfizethető), de meg kellene oldani ezt az aktív-kapcsolatok kérdéskört, s akkor arról még nem is beszéltem, hogy persze a legtutibb az lenne, ha az IP is maradna, de ha van alternatív megoldás erre, az is jó.

Tudni kell, hogy van colocationben is szervere a cégnek, ha ez segít valami gondolatokban :-)

Előre is köszi!
Dan

  • 528 megtekintés

( thxer v | 2024. 01. 18., cs – 18:54 )

Dobozos megoldást nem ismerek, de pl. 2-4 darab MikroTikkel költséghatékonyan megoldható a probléma.
Telephely és egy vagy több DC között a két internetkapcsolaton 1-1 tunneleket (pl. GRE) kell kiépíteni, tunnelen belül lehet használni valamilyen routing protokollt (OSPF, BGP) + BFD-t és szépen át fog állni a forgalom a másik irányba, ha valamelyik netkapcsolat elmegy. 

Mobilnetnél extra feladatot jelenthet, hogy a szolgáltatók előszeretettel CG-NAT-olt IP-t adnak csak. Valamilyen mikrós szolgáltató nem elérhető?

Köszi, ez remekül hangzik!
Bár nem vagyok MikroTik-es, azért valószínűleg ezt ki lehetne alakítani.

A kérdésem az lenne, hogy a nagylzs által felsorolt másik megoldásnál felmerült hátrányok itt nem jelentkeznének?
Illetve most tulképp akkor úgy nézne ki a dolog, hogy a telephelyen 1 darab MikroTik kezelné mindkét WAN-t (gondolom akár mobilsticket is tud USB-n át), s lenne további 1 darab MikroTik a DC-nél, s a tunnel segítségével a DC internet-kapcsolatát használná a telephely tulajdonképpen, s konkrétan, amikor netezik, akkor olyan lenne, mintha a DC IP-jéről jönne?
A DC-nél ez minden szervertől függetlenül tudna működni, nem kell neki semmi, csak a MikroTik eszköz, igaz?
Ha pedig a DC-nél van valami gond (ez igen ritka), akkor pedig megáll gyakorlatilag az élet, vagy ez is automatizálható, hogy azért legyen netje a telephelynek ilyen esetben?

Na igen, a CG-NAT-olt IP az világos. Ephone van most backupnak, ők adnak normálisat is. Tudsz amúgy olyat, ahol még tudnak adni normálisat, mert a Yettelnek elég rossz a térereje a telephelynél.
Egyébként van mikrós szolgáltató is, csak igen drága, ha értelmes sávszélességet akarnánk, s így nem annyira preferrált ez a megoldás.

A BFD nagyon gyorsan észreveszi ha szakadás/packet loss van és lekapcsolja azt a routing irányt.

A latency az kétélű dolog, itthon minden nagyon Budapest központú, tehát ha egy budapesti DC-ben van a tunnelek vége, akkor minimális latency növekedéssel lehet számolni, a másik oldalról szinte biztos, hogy a DC-ben lévő szolgáltatónak jobb minőségű IP tranzit és peering kapcsolatai vannak, mint ami bármely lakossági internetszolgáltatónak, emiatt javulhat a felhasználói élmény.

Az MTU csökkenés tapasztalataim szerint nem okoz problémát, ha jól be van állítva (TCP MSS rendben van, ICMP nincs teljesen blokkolva)

Ha netezik, a DC-ben lévő MikroTik külső IP címére van NATolva a forgalom, tehát igen, úgy látszana hogy onnan jön. Ez jelenthet plusz költséget, mert a helyi net előfizetésen kívül  a DC oldalon is ki kell fizetni a netet + adatforgalmat.

Nem kell neki plusz szerver a DC-ben, elég egy fizikai MikroTik, ami virtuális is lehet (CHR), itt az elvárt sávszélesség /redundancia alapján több választási lehetőség is van.

Beállítás kérdése, hogy mi történik DC lehalás esetén, ha mindkét tunnel lehal, akkor automatán mehet az alacsonyabb prioritású lokális net felé, helyben NAT-olva, de ekkor az összes kapcsolat szakadni fog az forrás IP változás miatt. Lehet USB-s modemet használni, de vannak olyan eszközök amikben van beépített 4G vagy 5G modem, ebben az esetben nem kell megküzdeni a MikroTik <-> random USB modem közti kompatibilitási problémákkal.

mi is igy csinaltuk meg: a router vpnje "bindelve" volt az adott uplinkhez. ha leszakadt az isp akkor a vpn is leszakadt, ha visszajott akkor az vpn is ujra ment. a vpnek felett meg bgp szepen megoldotta hogy merre menjen a packet. (igazabol 4 vpn kapcsolat volt: 2 isp - 2 tavoli fw)

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

a firewall az vyos volt, a router meg mikrotik. sima openvpn mert akkor meg csak azt ismerte a mt. most mar wireguard lenne. a fw-ken ket ovpn server futott mas-mas portokkal. mt-n policy routinggal volt megadva hogy melyik vpn melyik merre menjen (1194-hez isp1, 1195-hez isp2).

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( nagylzs v | 2024. 01. 18., cs – 19:00 )

Wireguard tud olyat, hogy route váltás közben nem szakad meg a kapcsolatod. Ha van megbízható dedikált szervered egy adatközpontban, akkor azon keresztül átirányíthatod a forgalmat.

* a távoli, megbízható szerverre telepítesz wireguard -ot például https://github.com/linuxserver/docker-wireguard
* a problémás telephelyre két független internet kapcsolat kell, és meg kell oldanod a WAN auto failover-t, pl. routeros /tools/netwatch segítségével (nem nehéz beállítani)
* plusz kell egy wireguard kliens, ami az egész LAN forgalmat átküldi rajta, praktikus ha ez és a WAN failover ugyan azon a router-en van
* ezek után a teljes belső LAN forgalmadat át tudod küldeni wireguard-on, aminek lesz előnye és hátránya

Az előnye az, hogy WAN failover-kor a router-ed automatikusan elkezdi használni a második internet kapcsolatot, de közben a wireguard nem szakad meg. A wireguard simán kezeli a route változásokat.

Hátránya is van egy csomó:

* ha minden forgalom átmegy a VPN szervereden, akkor latency megnövekedik, és az átviteli sebesség is valószínűeg csökken
* ha a LAN-on levő gépek további VPN-t is használnak, akkor dupla VPN lesz, csökken az MTU, ez is problémás lehet (illetve ha nem IP alapút hanem mondjuk IKEv2 IPSEC és hasonlók, akkor további ügyeskedésre lesz szükség, ami még fokozza ezeket a hatásokat)

Ráadásul ez csak néhány fajta hiba ellen véd. Például, ha a netwatch elég gyakran ellenőriz, és elég gyorsan vált szolgáltatót, akkor a LAN-on levő gépről az internet irányába megnyitott TCP kapcsolatai **valószínűleg** nem szakadnak meg. De ha az internet szolgáltatód random és nagyon gyakran hol megszakad hol visszajön, vagy ha mindkét szolgáltatód ezt csinálja, akkor ez se fog segíteni.

( zrubi v | 2024. 01. 18., cs – 20:57 )

hogy persze a legtutibb az lenne, ha az IP is maradna

Ezt két különböző ISP-vel nem igazán fog összejönni.

 

Egy ISP-n belül lehet ilyen szolgáltatás, de nyilván csak akkor van értelme, ha két külön vonalon/medián tudja azt adni, hogy valóban redundáns legyen. pl üveg/Mikró/mobil. De ebből azonnal adódik, hogy erősen eltérnek a paramétereik...

 

Úgy általában:

Az igényed érthető, igaz technikailag nézve már kevésbé reális,

De még ha találsz is megoldási javaslatokat, a kivitelezését és az üzemeltetéset biztosan nem akarod majd kifizetni ;)

legalábbis amiket én láttam, azok biztosan több problémát hoztak be, mint amennyit elméletileg megoldottak

(A gyakorlatban szinte mindegyik hosszú távon rendelkezére állás csökkenést okoz)

 

szerintem.

zrubi.hu

( arpi_esp v | 2024. 01. 19., p – 09:44 )

kulonbozo isp-k: elmeletileg itt a BGP johetne szoba, de azt csak nagy fajsulyu ugyfeleknel fogjak nekiallni az isp-k egyuttmukodve bekonfolni, a gyakorlatban felejtos.  a vodas mobilnet backup mukodik egyik ugyfelunknel, de eleg szar, nagy a latency es lassu, nem ajanlom. atall par mp alatt az teny, de ha szakadozik az elsodleges (naluk mikros) link akkor ide-oda fog ugralni. es hiaba jelented be hogy szar, ok azt fogjak latni hogy mukodik :)

masik lehetoseg ha felhuzol a colocationos szerver fele egy olyan vpn-t vagy l2tp tunnelt ami eleg gyorsan atall szakadaskor a backup vonalra, es az egesz forgalmat (legalabbis ahol a szakad problema) ezen at routeolod.

( ggallo | 2024. 01. 19., p – 18:09 )

Ha szakadásmentes stateful kapcsolatokat szeretnél, akkor különböző ISP-kkel csak nagyon macerásan (kb. ahogy nagylzs írta, hogy átfűzöd a datacenteren a teljes forgalmad egy rendundás VPN-páron) oldható meg. Ez csak úgy megy, ha egy szolgáltató épít ki különböző csatornákon vonalat és az Ő végberendezése ezt a redunkdáns szolgáltatást feléd átadja mint normál internet elérés.

Minden ettől különböző megoldás a stateful kapcsolatoknál (pl. VPN) szakadást fog okozni. A stateless az simán működik (általában) tovább - pl. webes forgalom.

Én azt javaslom, hogy csak valóban jó, valaki által papíron is vállalt megoldást ajánlj az ügyfélnek, és majd Ő mérlegeli, hogy a magasabb SLA ér-e neki annyit. Ugyanis ha összeállítasz (vagy mással csináltatsz) egy ilyen ebben jó-abban rossz megoldást, és nem hozza az _ügyfél által_ várt eredményt, akkor szorulni fogsz érte, és semmit sem tehetsz majd.

Az a baj, hogy a redundanciát nem elég egy ponton növelni, mert akkor csak az SPOF kerül át máshová. Pl. DC és telephely között egy-egy router és két internet kapcsolat használatával a komplexitás jelentősen nő, de az SLA messze nem annyira, mert ott lesz az 1-1 router, mint szűk keresztmetszet. Egy jobb megoldás végpontonként két router, természetesen redundáns táplálással (de legalább ne egy körről működjön a kettő router), persze két internet kapcsolattal (mindkettő internet mindkét router-be bekötve). Na persze a DC oldalára is kell egy második internet (hiába magas az SLA-ja a meglévőnek, attól még nem redundáns) - ami jó drága lesz valószínűleg. Ez már túlmutat azon, amennyit a letöbb ilyen "nekünk élet-halál kérdése a net kapcsolat" cégnek ér a dolog valójában... Meg árban ez már ott tart, mint egy magas SLA-s szolgáltatói megoldás, csak még komoly (így drága) szaki is kell hozzá aki összerakja meg üzemelteti.

Én ilyen feladatra bérelt vonali internet szolgáltatást ajánlanék az ügyfélnek, ami olyan mint a "sima" internet, csak jóval magasabb SLA-t vállal rá a szolgáltató - persze jóval drágábban. Így lehet biztosítani a valóban szakadásmentés folyamatos(abb) kommunikációt. Minden más megoldásnak lesz hátránya bizonyos tápusú forgalmak esetén. Az persze lehetséges, hogy a szolgáltató valamiféle redundáns megolást telepít, de az az Ő dolguk, a lényeg, hogy a szakadásmentes, magasabb SLA meglegyen a Te átadási pontodon.

Az is megoldás lehet egy másik megközelítéssel, hogy a felhasználási módjukat is át kell alakítani egy nem-stateful redundáns internet bevezetésével együtt, hogy alkalmazkodjanak az új rendszer lehetőségeihez/korlátaihoz. Na persze amennyiben erre van mód (nem akarás, hanem lehetőség).

( h0lysh1t | 2024. 01. 19., p – 18:32 )

OFF - szakadásos módszer kispénzből:

Tehetsz elé egy DNS-t ahol mondjuk két A rekordot fölveszel, egyik az egyik ISP WAN IP-dre mutat a másik rekord meg a másikra. A VPN klienst beállítod hogy IP helyett az előbbi DNS névre mutasson. A két modem mögé meg beteszel egy gateway vasat (open/pfsense stb) amibe bedugod a modemeket, fölveszed mind a két WAN IP-t a lábain és mindkettőn hirdeted a VPN-t. Pluszban innentől a gateway mögül aggregálhatod is a forgalmat.

DNS móka nélkül is működhet, ilyenkor viszont a kliens VPN-nél kell megoldani a két IP címes konfigot úgy, hogy ha az elsődleges lehal akkor menjen a másodikról, vagy hajtányban majd a kliens rábök a "másodlagos céges VPN" connect gombra.
Konkrétan még nem próbáltam a "dupla" A rekordos megoldást.

Egy fokkal ügyesebb ha CDN-nél veszel loadbalance-t a két IP-dre de felteszem itt is szakadni fog a kliens ha a háttérben váltani kell a címek között.