Odpoveď VPN medzi lokalitami nejde tunelom
Odpoveď, ktorá obchádza tunel, je rozhodnutie o smerovaní na druhej strane. Skontrolujte tabuľku hostiteľov, selektory a rp_filter, potom zvoľte trasu alebo NAT.
Ráno som strávil pri tuneli, ktorý sa čisto zdvihol a prenášal prevádzku presne jedným smerom: pobočka dosiahla na súborový server v centrále a každé spojenie otvorené z centrály do pobočky zomrelo na prvom SYN. SA boli aktívne, počítadlá tunela rástli a handshake nikdy nebol problém. Odpoveď sa smerovala niekam, čo tunel nepokrýva, a toto rozhodnutie patrí vzdialenej strane. VPN medzi lokalitami prenáša len pakety, ktoré hostiteľ odovzdá bráne, a každý hostiteľ toto rozhodnutie robí zvlášť, v každom smere, z vlastnej smerovacej tabuľky.
Oba smery sa smerujú oddelene
IP si nepamätá smer konverzácie. Každý hostiteľ, ktorý odošle paket, vykoná vlastné hľadanie najdlhšieho prefixu, vyberie jeden ďalší skok a rozhodnutie zabudne. Požiadavka a odpoveď sú dva nesúvisiace pakety, ktoré náhodou patria k tomu istému spojeniu, a tunel je jeden skok, ktorý môže a nemusí použiť ktorýkoľvek z nich. Nič vo výmene IKE neučí vzdialený server, ako dosiahnuť vašu podsieť; rokovanie sa len zhodne na tom, ktoré prefixy sa smú šifrovať.
Tá dohoda je druhá brána. V strongSwane sú selektory prevádzky leftsubnet a rightsubnet a paket, ktorého zdroj alebo cieľ leží mimo dohodnutej dvojice, sa nešifruje, nech smerovacia tabuľka hovorí čokoľvek. Prefix, ktorý sa smeruje do tunela, ale v selektoroch chýba, je tiché jednosmerné zlyhanie: trasa vyzerá správne, paket predsa odchádza v čitateľnej podobe alebo sa zahodí, a sťažuje sa len protokol charonu.
Vzdialený hostiteľ o vašom tuneli nič nevie
Vnútri vzdialenej LAN je odpoveď obyčajný paket adresovaný vášmu klientovi. Cieľový hostiteľ nevidí žiadnu hlavičku IPsec a nemá dôvod uprednostniť bránu VPN; vyhľadá váš prefix, nenájde nič konkrétnejšie ako svoju predvolenú trasu a bude ju nasledovať. Ak predvolená trasa ukazuje na hlavný firewall, firewall má buď trasu späť do tunela, alebo nie. Keď ju nemá, dostanete tiché zahodenie, ICMP nedostupnosť alebo odpoveď, ktorá vyjde rozhraním k internetu a zahynie.
Druhé rozhranie stačí na to, aby sa to pokazilo aj vtedy, keď trasa existuje. NAS s management rozhraním v inom VLAN, server so záložným uplinkom, pravidlo politiky, ktoré posiela jeden rozsah zdrojov do druhej tabuľky: čokoľvek z toho môže odpoveď zachytiť. V Linuxe ip rule show a ip route show table all ukážu pravidlá a tabuľky, ktoré predvolený výpis skrýva.
Prečítajte rozhodnutie na stroji, ktorý odpoveď odosiela
Pýtajte sa jadra, skôr než niečo zmeníte, a dajte mu zdrojovú adresu, pretože pravidlá závislé od zdroja menia odpoveď.
ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"Výstup uvádza odchádzajúce rozhranie a ďalší skok. Ak rozhranie nie je to, ktoré mieri k bráne VPN, našli ste závadu a zostáva vybrať, kam trasa patrí. Ping z brány tu dokazuje málo: odpovedá adresou, ktorú vzdialený hostiteľ vie umiestniť, nie adresou vášho notebooku.
Vo Windows sú ekvivalenty Find-NetRoute -RemoteIPAddress 10.10.5.10 pre rozhodnutie a Get-NetRoute pre tabuľku. Trasa pridaná pomocou New-NetRoute s vyššou metrikou ako predvolená prehráva ticho, takže čítajte stĺpec metriky, nie záznam. Potom to potvrďte paketmi: tcpdump -ni any "host 10.10.5.10 and tcp port 445" na vzdialenom LAN rozhraní ukáže požiadavku a ten istý filter na strane tunela ukáže, či sa odpoveď vrátila. Viditeľná požiadavka bez odpovede znamená, že odpoveď bola smerovaná inam alebo zahodená; odpoveď na nesprávnom rozhraní vám dá vinníka skôr, než sa dotknete trasy.
Keď brána servera nie je koncovým bodom VPN
Mnoho lokalít stavia firewall medzi servery a koncentrátor. Ten firewall odpoveď preposiela, takže potrebuje trasu pre prefix vášho klienta smerom k bráne VPN a politiku preposielania v oboch smeroch. Stavové zariadenia to zhoršujú: požiadavka prešla firewallom od hostiteľa LAN, ktorému to povolil, odpoveď teraz prichádza z iného smeru a záznam sledovania spojení už nesedí, takže paket sa zahodí ako neplatný, nie ako zakázaný. Preto log politiky vyzerá prázdny, kým prevádzka mizne.
Brána má vlastný druhý filter. Spätné filtrovanie cesty v Linuxe zahadzuje pakety, ktorých zdroj nie je dostupný cez rozhranie, ktorým prišli, a to je presne podoba legitímnej asymetrickej spiatočnej cesty. príručka strongSwanu k preposielaniu preto žiada net.ipv4.ip_forward a uvoľnený net.ipv4.conf.all.rp_filter. Prísna hodnota 1 na ktorejkoľvek bráne ticho pokazí správnu trasu a nstat -az ukáže zahodenia, ak viete, kam sa pozerať.
| Symptom | Where the reply is most likely lost |
|---|---|
| Gateway ping works, LAN host silent | Source address the far host cannot place in its table |
| SYN arrives, no SYN-ACK, tunnel counters flat | No route to the client prefix on the far host or its gateway |
| Reply counted on the internet-facing interface | Default route or policy rule on the far host |
| Firewall reports invalid state | Asymmetric path through a stateful device |
| Worked until a link failed over | New path is asymmetric, or rp_filter now rejects it |
Smerujte alebo prekladajte, potom overte v oboch smeroch
Dve opravy nie sú rovnocenné. Pridanie trasy zachová adresu klienta nedotknutú, takže pravidlá založené na zdroji, audítorské záznamy a aplikácie zaznamenávajúce volajúceho ďalej fungujú; cenou je, že každý skok, ktorý rozhodnutie prijíma, potrebuje trasu, teda viac miest na chybu. Maskovanie na vzdialenej bráne zhusťuje spiatočnú cestu na jeden skok, pretože odpoveď je teraz adresovaná samotnej bráne, a skrýva, ktorý klient čo urobil.
iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADEVyberte ho vedome: len čo sa klienti začnú javiť ako adresa brány, ACL založené na zdroji ich prestanú rozlišovať a conntrack musí držať mapovanie, aby sa odpoveď prepísala späť do tunela. Ak selektory stále vylučujú prefix klienta, NAT nič nemení, pretože požiadavka do tunela nikdy nevstúpila.
Skôr než to vyhlásite za opravené, potvrďte štyri veci v poradí: trasu na hostiteľovi, ktorý odpoveď odosiela, trasu na každom skoku, ktorý ju preposiela, selektory pokrývajúce oba prefixy a záznam, ktorý ukazuje odpoveď vstupujúcu do tunela s očakávaným zdrojom. Potom test zopakujte z druhej lokality. Jeden prechádzajúci smer je polootvorený návrh a druhý smer zvyčajne zlyhá z iného dôvodu, než aký ste práve opravili.