Csillag vagy teljes háló: melyik VPN-topológia illik a telephelyeihez

Két fióktelephely egész nap beszél egymással, és a köztük lévő alagút egy másik régió adatközpontján keresztül kerül. Minden kérés kétszer fizet ezért a kerülőért, és senki nem veszi észre, amíg a fájlszinkronizálás elkezd rosszul kinézni. Itt kezdődik igazán a topológia kérdése: nem azzal, melyik ábra tűnik ellenállóbbnak, hanem azzal, milyen forgalmi mintáért fizet. Mindkét felépítés működik, és különböző módon, különböző költséggel hibázik.

Először számolja meg a peerek közötti kapcsolatokat

N telephely esetén a teljes hálóhoz N-szer N mínusz egy, osztva kettővel, alagút kell; egy csillaghoz N. Öt telephelynél ez tíz öt ellen, ami még kezelhetőnek hangzik. Tizenötnél 105 tizenöt ellen, és a különbség már nem aritmetika, hanem létszám.

E kapcsolatok mindegyike olyan állapotot hordoz, amelynek Önnek kell a birtokosa lennie. Az IPsecben ez biztonsági társítást, identitást, kulcsot vagy tanúsítványt, halott peer észlelését és legalább egy útvonalat jelent minden távoli előtaghoz. A WireGuardban ez egy nyilvános kulcsot és egy AllowedIPs blokkot jelent peerenként, ami peerenként olcsóbb, de teljesen felfedezés nélkül jön: egy új telephely így is konfigurációváltozás minden meglévőn.

A forgalom összetétele döntsön, ne a rajz

Ha a fiókforgalom főleg egy központi ERP vagy fájlklaszter felé irányuló kérés, a csillag nem kompromisszum, hanem a helyes forma: a forgalom már oda akart menni, és egyetlen házirendpont könnyebben auditálható, mint a páronkénti szabályok hálója. A háló akkor érdemli ki a bonyolultságát, amikor a telephelyek adatot cserélnek egymással — replikáció két iroda között, hang a telephelyek között, egy megosztott CAD, amelyet tucatnyi mérnök nyit egész nap.

A kellemetlen esetek középen vannak, és ők a többség. Mérjen, mielőtt vitatkozik, ahelyett hogy szervezeti ábrából találgatna.

A táblázatot döntetlenfeltörőnek olvassa, nem szabálynak. Négy sorból három egy irányba általában eldönti a tervet; a megosztottság hibridet jelent, amire a legtöbb érett hálózat úgyis eljut.

A csillagnak meg kell mondani, hogy továbbítson

Két működő spoke-csillag alagút nem hoz létre spoke-spoke hozzáférést. A csillagnak engedélyezett IP-továbbításra, minden spoke-hálózathoz útvonalra, a tranzitot engedélyező tűzfalszabályra és kiszámított visszaútra van szüksége; minden spoke-nak útvonalra a másik telephely előtagjaihoz. Linux csillagon ez net.ipv4.ip_forward=1 plusz FORWARD egy lánc, amely nem dobja el csendben a párt, és a házirendalapú IPsecben forgalomválasztók sorolják fel a távoli spoke alhálózatát mindkét végén. A strongSwan továbbítási jegyzetei lefedik a kernel és a tűzfal oldalát, amikor éppen az a réteg hiányzik. Olcsó teszt, hogy forgalmat küld egyik spoke-ból a másik szolgáltatására, és figyeli a csillag számlálóit; a soha nem növekvő szabály azt jelenti, hogy a sorrend rossz, nem az útvonal.

A központi házirend is a hasznos rész. A telephelyek elérhetik a megosztott szolgáltatásokat anélkül, hogy elérnék egymást, és ezt a hozzáférési mátrixot érdemes kifejezetten leírni. A hiányzó útvonalak rossz pótlék egy olyan szabály helyett, amelyet valaki el tud olvasni.

Figyeljen a félkész változatra: az A spoke a csillagon keresztül irányít a B spoke felé, a csillag mindkét irányba irányít, és a csillag tűzfala engedi az új kapcsolatokat A-ból, de B-ből nem. Az első irány jól tesztelhető, a második megakad, ami útvonalhibának látszik, és nem az.

Először a hibát tervezze meg, aztán a normál utat

Egyetlen csillag megosztott függőség és átviteli szűk keresztmetszet, és a redundancia az, ahol a csillagfelépítések általában elromlanak. Két csillag azt jelenti, hogy minden spoke két alagutat tart, és a visszaútnak egyeznie kell a kimenővel; amikor nem egyezik, egy állapottartó tűzfal eldobja a válaszokat, és a tünet egy kapcsolat, amely megnyílik, majd meghal. A nagyobb telepítések ezt útválasztási protokollal oldják meg az alagutak felett statikus előtagok helyett, ami több gépezet, de kiveszi a találgatást. Bármit is választ, írja a visszaútat a kimenő mellé, mert a visszafelét senki nem teszteli.

A háló szétszórja ezt a kockázatot: az egyik telephely kapcsolatának kiesése nem izolálja a többit. Azonban megsokszorozza azokat a helyeket, ahol az útvonalválasztás meglepheti, és az alkalmazás-munkamenetek továbbra sem élik túl a pályaváltást segítség nélkül.

Egyik felépítés sem tartja életben a TCP-munkamenetet egy átkapcsolás alatt magától. Ha az alkalmazás nem tud újracsatlakozni, a topológia nem az Ön problémája.

A változtatás költsége szerint válasszon, majd ellenőrizze az útvonalakat

Kezdje a csillaggal, mert abban a legolcsóbb tévedni, és adjon hozzá közvetlen alagutakat azoknak a pároknak, amelyek forgalma ezt indokolja. Ez a hibrid nem a döntés elmaradása; ez az a felépítés, amely felé a legtöbb szervezet egy éven belül eljut. A fontos az, hogy minden közvetlen kapcsolatnak legyen kimondott oka és felelőse.

Aztán két rajzot ellenőrizzen egy helyett. A normál útvonalhoz, traceroute minden telephelyről minden szolgáltatási előtaghoz, és erősítse meg, hogy az ugrások megfelelnek az ábrának. A hibaútvonalhoz kapcsoljon ki egy alagutat, és ismételje meg, mert az az útvonal, amely csak addig működik, amíg minden fut, nincs megtervezve, csak beállítva.

Tartsa mindkét rajzot a hozzáférési mátrixszal, és nézze át őket, amikor telephely kerül be; a kezelt költség a következő változtatás költsége, nem a jelenlegi kép eleganciája.