Který paket má zachytit politika VPN se dvěma WAN?

Požadavky typu směrovat VPN přes druhou přípojku popisují nejméně dva různé úkoly a politika, která opraví jeden, se toho druhého nedotkne. V prvním úkolu se šifrovaný transport mezi dvěma koncovými body přesouvá na jinou adresu WAN. Ve druhém vychází dešifrovaný tok aplikace připojeného uživatele k jinému dalšímu hopu. Obojí je legitimní, obojí používá směrování a každé potřebuje shodu na paketu, který v místě rozhodnutí existuje. Projděte kontroly níže popořadě, protože první určuje, který paket mají pozdější pravidla pojmenovat.

Pojmenujte oba rozhovory

Představte si vzdáleného pracovníka připojeného k firemní bráně, který otevírá HTTPS k internímu aplikačnímu serveru. Po lince jdou dva nezávislé rozhovory a na každém konci mají jiné adresy. Vnější rozhovor probíhá mezi dvěma koncovými body VPN: od adresy brány k adrese protějšku, s tím protokolem a portem, které nasazení vyjednalo. Vnitřní rozhovor jde od adresy přidělené klientovi k adrese aplikačního serveru na portu 443.

Cílový port aplikace není transportní port VPN a žádné množství politiky na TCP 443 tunelem nepohne. Stejně tak pravidlo, které přesměruje transportní adresu protějšku, neříká nic o tom, kam jde požadavek HTTP tohoto uživatele po dešifrování. Zapište oba rozhovory s jejich skutečnými adresami, než se dotknete pravidla, protože většina zmatení v této oblasti vzniká tím, že se jeden pojmenuje a druhý nakonfiguruje.

Zjistěte, kde vaše politika paket skutečně vidí

Shoda se musí vyhodnocovat v tom řetězci a jmenném prostoru, kde je paket ještě ve vámi popsané podobě. Pravidlo navěšené na vstup LAN vidí vnitřní paket nešifrovaný, než je směrován k tunelu. Pravidlo použité na lokálně vytvářený provoz vidí pakety, které brána sama generuje, a nepokrývá automaticky provoz, který brána jen předává. Zapouzdřený výstup je opět třetí případ, obvykle řešený na rozhraní, které nese tunel, nikoli na straně LAN.

Proto se stejný úryvek konfigurace chová na dvou platformách jinak: místa navěšení se liší a háček politiky výrobce může být před krokem šifrování nebo za ním. Čtěte cestu paketu pro konkrétní produkt, místo abyste pořadí odvozovali z diagramu jiného výrobce.

Potvrďte transport, který jste vyjednali

U IPsec zapouzdřeného v UDP RFC 3948 vkládá ESP do UDP a používá značku, která není ESP, aby IKE zůstal na sdíleném portu rozlišitelný. Prostý ESP je IP protokol, nikoli port TCP nebo UDP, takže pravidlo firewallu napsané na číslo portu jej vůbec nezachytí. Toto rozlišení rozhoduje o tom, zda vaše politika WAN potřebuje pravidlo UDP, pravidlo protokolu, nebo obojí.

Vyjednané hodnoty vítězí nad zapamatovanými. Čtěte aktuální porty a adresy asociace ze zařízení, místo abyste přidávali TCP 4500 nebo starý port výrobce pro jistotu, což zachytí nesouvisející provoz a skryje skutečný problém klasifikace.

Zkontrolujte zpáteční cestu, než se zavážete

Úspěch odchozího směru dokazuje polovinu návrhu. Paket vracející se k fondu vzdálených klientů už není pod adresou klienta viditelný, jakmile jej zapouzdření nahradí: vnějším cílem je transportní adresa protějšku. Pokud se druhá přípojka dostane k tomuto protějšku přes jiného operátora, její překlad a filtrování se mohou rozejít s první a asociaci bude možná nutné spíše přestavět než migrovat.

Stav překladu síťových adres je obvyklou obětí přepnutí WAN. Zaznamenejte zvolenou přípojku, očekávanou vnější zdrojovou adresu, používaný překlad a dosažitelnost protějšku zpět k ní, poté držte transport dostupný, aniž byste jej posílali do tunelu, který nese.

Ověřte obě vrstvy dvěma záznamy

Jeden záznam na rozhraní WAN a jeden uvnitř tunelu vyřeší otázku rychleji než jakékoli porovnání konfigurace. Spusťte je z brány, zatímco schválený klient provádí jediný požadavek, a oba soubory si ponechte.

sudo tcpdump -ni wan1 'udp port 4500' -c 20
sudo tcpdump -ni tun0 'tcp port 443 and host 203.0.113.10' -c 20
ip route get 203.0.113.10 from 10.8.0.6

První záznam má ukázat vnější rozhovor opouštějící rozhraní, které jste zamýšleli, s očekávanou zdrojovou adresou. Druhý má ukázat vnitřní rozhovor jednou, bez duplikace, s adresou klienta jako zdrojem a aplikačním serverem jako cílem. Vyhledání trasy potvrzuje, kterou tabulku by router pro tuto dvojici zdroj a cíl použil, a právě tam se chyba v politice obvykle objeví. Pokud se některý záznam neobjeví, rozhodovací bod je jinde než tam, kam bylo pravidlo navěšeno, a oprava patří tam, nikoli do širší shody.