Rozšíření lokality VPN: sledujte zpáteční trasu za bránou

Provoz z pobočky končí na bráně, jejíž LAN neobsahuje aplikaci, ke které jste se měli dostat. Server sídlí v druhém datovém centru, za interním spojem, který VPN nikdy nenakonfigurovala. Přidání dalšího prefixu na blízkou bránu pro tento případ nic neudělá, protože vzdálená brána je koncový bod šifrování, nikoli poslední router. Cesta potřebuje trasu dál, vpuštění na vzdálené bezpečnostní hranici a rozhodnutí o návratu v samotné síti cíle.

Vzdálená brána je koncový bod šifrování

IPsec mezi bránami chrání provoz mezi dvěma bezpečnostními zařízeními a vnitřní adresy putují tímto segmentem šifrovaně. Za vzdálenou bránou přebírá řízení běžné směrování, včetně jakékoli politiky, která mezi datovými centry existuje. Chráněný segment tedy pokrývá část cesty, a ne zbytek. Předpokládat opak je způsob, jak návrh skončí se zdravým tunelem a nedostupnou aplikací.

Nakreslete cestu ve třech částech: pobočka k blízké bráně, blízká ke vzdálené, vzdálená brána k aplikaci. Každá část má svého vlastníka a svůj způsob selhání.

Přečtěte si oba směry politiky tunelu

Politika tunelu se obvykle píše z pohledu místní strany a právě z tohoto zvyku vznikají částečné konfigurace. Oba partneři musí uvést zdroj pobočky i cíl tak, jak se objeví uvnitř tunelu, včetně případného překladu, který návrh zamýšlí. Aktualizace pouze blízkého konce vytváří neshodu druhé fáze, která vypadá jako selhání směrování. Porovnejte obě sady politik, než se dotknete jakékoli trasy.

Pište zdroj a cíl jako adresy, ne jako názvy lokalit. Nejednoznačnost se zde později vrátí jako matoucí asymetrie.

Přidejte trasu dál a potvrďte vpuštění

Vzdálená brána potřebuje trasu k podsíti aplikace a každý router mezi nimi musí vpustit zdroj pobočky. Ověřte, co vzdálená brána skutečně má, místo toho, co tvrdí diagram.

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

První příkaz hlásí výstupní rozhraní a další skok, které by vzdálená brána pro tento zdroj zvolila, což je otázka, na kterou běžná směrovací tabulka neumí odpovědět. Trasování ukazuje, kde se pakety zastaví, a přerušení za vzdálenou bránou ukazuje na vnitřní tranzit, nikoli na tunel. Když trasa existuje a provoz přesto mizí, zachyťte provoz na vzdálené bráně a přečtěte přicházející zdrojovou adresu, protože neočekávaná adresa znamená, že překlad probíhá někde neplánovaně. Všechny adresy jsou zde zástupné, takže dosaďte skutečné podsítě pobočky, tranzitu a aplikace.

Testujte z pobočky, pak znovu otestujte starou cestu

Přijetí vyžaduje skutečný zdroj, ne sondu ze vzdálené brány. Spusťte kontrolu z hostitele v pobočce a ponechejte dříve fungující cíle ve stejném testu.

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

Odpověď z aplikace prokazuje cestu tam i zpět společně, zatímco ping na starý cíl prokazuje, že změna nerozbila to, co už fungovalo. Zachyťte zdrojovou adresu, kterou aplikace loguje, protože její přístupová pravidla a případná zpáteční trasa musí odpovídat této hodnotě. Kde pobočka překládá před tunelem, adresa v politice a adresa, kterou aplikace vidí, se záměrně liší, takže zaznamenejte obě. Test zopakujte po obnovení klíče nebo změně směrování, protože tyto cesty se obvykle ověří jednou a pak se zapomenou.

Přiřaďte vlastníka každému ze tří segmentů a zpáteční trase uvnitř cílové sítě. Cesta se čtyřmi vlastníky selhává v mezerách mezi nimi.