Rozšírenie lokality VPN: sledujte spätnú trasu za bránou

Prevádzka z pobočky končí na bráne, ktorej LAN neobsahuje aplikáciu, ku ktorej ste sa mali dostať. Server sídli v druhom dátovom centre, za interným spojením, ktoré VPN nikdy nenakonfigurovala. Pridanie ďalšieho prefixu na blízku bránu pre tento prípad nič neurobí, pretože vzdialená brána je koncový bod šifrovania, nie posledný router. Cesta potrebuje trasu dopredu, vpustenie na vzdialenej bezpečnostnej hranici a rozhodnutie o návrate v samotnej sieti cieľa.

Vzdialená brána je koncový bod šifrovania

IPsec medzi bránami chráni prevádzku medzi dvoma bezpečnostnými zariadeniami a vnútorné adresy putujú týmto segmentom šifrované. Za vzdialenou bránou preberá riadenie bežné smerovanie, vrátane akejkoľvek politiky, ktorá medzi dátovými centrami existuje. Chránený segment teda pokrýva časť cesty a nie zvyšok. Predpokladať opak je spôsob, akým návrh skončí so zdravým tunelom a nedostupnou aplikáciou.

Nakreslite cestu v troch častiach: pobočka k blízkej bráne, blízka k vzdialenej, vzdialená brána k aplikácii. Každá časť má svojho vlastníka a svoj spôsob zlyhania.

Prečítajte si oba smery politiky tunela

Politika tunela sa zvyčajne píše z pohľadu miestnej strany a práve z tohto zvyku vznikajú čiastočné konfigurácie. Obaja partneri musia uviesť zdroj pobočky aj cieľ tak, ako sa objavia vnútri tunela, vrátane akéhokoľvek prekladu, ktorý návrh zamýšľa. Aktualizácia iba blízkeho konca vytvára nezhodu druhej fázy, ktorá vyzerá ako zlyhanie smerovania. Porovnajte obe sady politík, skôr než sa dotknete akejkoľvek trasy.

Píšte zdroj a cieľ ako adresy, nie ako názvy lokalít. Nejednoznačnosť sa tu neskôr vráti ako mätúca asymetria.

Pridajte trasu dopredu a potvrďte vpustenie

Vzdialená brána potrebuje trasu k podsieti aplikácie a každý router medzi nimi musí vpustiť zdroj pobočky. Overte, čo vzdialená brána skutočne má, namiesto toho, čo 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

Prvý príkaz hlási výstupné rozhranie a ďalší skok, ktoré by vzdialená brána zvolila pre tento zdroj, čo je otázka, na ktorú bežná smerovacia tabuľka nevie odpovedať. Trasovanie ukazuje, kde sa pakety zastavia, a prerušenie za vzdialenou bránou ukazuje na vnútorný tranzit, nie na tunel. Keď trasa existuje a prevádzka napriek tomu mizne, zachyťte prevádzku na vzdialenej bráne a prečítajte prichádzajúcu zdrojovú adresu, pretože neočakávaná adresa znamená, že preklad prebieha niekde neplánovane. Všetky adresy sú tu zástupné, preto dosaďte skutočné podsiete pobočky, tranzitu a aplikácie.

Testujte z pobočky, potom znova otestujte starú cestu

Prijatie vyžaduje skutočný zdroj, nie sondu zo vzdialenej brány. Spustite kontrolu z hostiteľa v pobočke a ponechajte predtým fungujúce ciele v tom istom teste.

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

Odpoveď z aplikácie preukazuje cestu tam aj späť spoločne, zatiaľ čo ping na starý cieľ preukazuje, že zmena nepoškodila to, čo už fungovalo. Zachyťte zdrojovú adresu, ktorú aplikácia loguje, pretože jej pravidlá prístupu a akákoľvek spätná trasa musia zodpovedať tejto hodnote. Kde pobočka prekladá pred tunelom, adresa v politike a adresa, ktorú aplikácia vidí, sa zámerne líšia, preto zaznamenajte obe. Test zopakujte po obnovení kľúča alebo zmene smerovania, pretože tieto cesty sa zvyčajne overia raz a potom zabudnú.

Priraďte vlastníka každému z troch segmentov a spätnej trase vnútri cieľovej siete. Cesta so štyrmi vlastníkmi zlyháva v medzerách medzi nimi.