VPN-telep helykiterjesztése: kövesse a visszautat a gateway mögött

Egy fióktelep forgalma olyan gatewayen végződik, amelynek LAN-ja nem tartalmazza azt az alkalmazást, amelyet el kellett volna érnie. A kiszolgáló egy második adatközpontban van, egy olyan belső kapcsolat túloldalán, amelyet a VPN soha nem konfigurált. Egy újabb prefix hozzáadása a közeli gatewayhez semmit sem tesz abban az esetben, mert a távoli gateway titkosítási végpont, nem az utolsó útválasztó. Az útvonalnak továbbvezető irányra, beengedésre a távoli biztonsági határon és visszatérési döntésre van szüksége a cél saját hálózatában.

A távoli gateway titkosítási végpont

A gateway-gateway IPsec két biztonsági eszköz közötti forgalmat véd, és a belső címek titkosítva haladnak át ezen a szakaszon. A távoli gatewayen túl a szokásos útválasztás veszi át az irányítást, beleértve az adatközpontok között fennálló bármilyen szabályzatot. A védett szakasz tehát az utazás egy részét fedi le, nem a többit. Az ellenkezőjét feltételezni az az út, amelyen egy tervezés egészséges alagúttal és elérhetetlen alkalmazással végződik.

Rajzolja fel az útvonalat három részben: fióktelep a közeli gatewayhez, közeli a távoli gatewayhez, távoli gateway az alkalmazáshoz. Minden résznek saját tulajdonosa és saját hibamódja van.

Olvassa el az alagút-szabályzat mindkét irányát

Az alagút-szabályzatot általában a helyi oldal nézőpontjából írják, és ebből a szokásból erednek a részleges konfigurációk. Mindkét félnek fel kell sorolnia a fióktelep forrását és a célt úgy, ahogy az alagúton belül megjelennek, beleértve a tervezés által szándékolt bármilyen fordítást. Csak a közeli vég frissítése második fázisú eltérést okoz, amely útválasztási hibának tűnik. Hasonlítsa össze a két szabályzatkészletet, mielőtt bármelyik útvonalhoz hozzányúlna.

A forrást és a célt címként írja le, ne telephelynévként. Az itteni kétértelműség később zavarba ejtő aszimmetriaként tér vissza.

Adja hozzá a továbbvezető útvonalat, és erősítse meg a beengedést

A távoli gatewaynek útvonalra van szüksége az alkalmazás alhálózata felé, és a köztük lévő minden útválasztónak beengednie kell a fióktelep forrását. Ellenőrizze, mi van valójában a távoli gatewayen, ahelyett amit az ábra állít.

ip route get 10.30.5.10 from 10.10.1.50
traceroute -n -s 10.10.1.50 10.30.5.10

Az első parancs jelenti a kimenő interfészt és a következő ugrást, amelyet a távoli gateway ehhez a forráshoz választana, olyan kérdés, amelyre egy közönséges útválasztási tábla nem tud válaszolni. A nyomkövetés megmutatja, hol állnak meg a csomagok, és a távoli gateway utáni megszakítás belső tranzitra utal, nem az alagútra. Ha az útvonal létezik, és a forgalom mégis eltűnik, rögzítsen a távoli gatewayen, és olvassa le az érkező forráscímet, mert a váratlan cím azt jelenti, hogy a fordítás valahol nem tervezett helyen történik. Az itteni címek mind helyőrzők, ezért helyettesítse a fióktelep, a tranzit és az alkalmazás valódi alhálózataival.

Teszteljen a fióktelepről, majd tesztelje újra a régi útvonalat

Az elfogadáshoz valódi forrás kell a távoli gatewayről indított szonda helyett. Futtassa az ellenőrzést egy fióktelepi hosztról, és tartsa meg a korábban működő célokat ugyanabban a tesztben.

curl -sS -m 5 http://10.30.5.10:8080/health
ping -c 3 10.20.1.1

Az alkalmazás válasza együtt bizonyítja az oda vezető utat és a visszautat, míg a régi célra küldött ping bizonyítja, hogy a változtatás nem törte el azt, ami már működött. Rögzítse a forráscímet, amelyet az alkalmazás naplóz, mert hozzáférési szabályainak és bármely visszaútnak meg kell felelnie ennek az értéknek. Ahol a fióktelep az alagút előtt fordít, a szabályzat címe és az alkalmazás által látott cím tervezés szerint eltér, ezért jegyezze fel mindkettőt. Ismételje meg a tesztet kulcsújítás vagy útválasztási változás után, mert ezeket az útvonalakat általában egyszer ellenőrzik, aztán elfelejtik.

Rendeljen tulajdonost mindhárom szakaszhoz és a célhálózaton belüli visszaúthoz. A négy tulajdonossal rendelkező útvonal a köztük lévő hézagokban hibázik.