VPN klient na serveri LAN: prečo odpovede odchádzajú nesprávnou cestou

Príznaky sledujú jeden vzorec: host funguje, potom sa ako klient pripojí k VPN a teraz sa k nemu klienti LAN dostanú, zatiaľ čo jeho odpovede miznú. Zachytenie na hoste ukazuje, že odpovede odchádzajú tunelovým zariadením namiesto rozhrania LAN. Na tuneli nie je nič pokazené a opravou je trasa, nie opätovné pripojenie. Prejdite štyri kontroly nižšie v poradí a zastavte sa pri prvej, ktorá zlyhá.

Odpoveď je nový paket, nie obrátenie cesty

Pomáha opustiť predstavu, že odpoveď putuje späť po ceste, ktorou išla požiadavka. Smerovanie sa rozhoduje pre každý paket a každý smer na odosielajúcom hoste. Požiadavka, ktorá dorazila z 10.64.0.23 vnútri tunela, nevytvára žiadnu spiatočnú cestu; keď host odpovie, táto odpoveď sa porovná s tabuľkou ako nový paket a odíde trasou, ktorá vyhrá.

Preto klient plného tunela na stroji, ktorý obsluhuje aj LAN, vytvára takú mätúcu poruchu. Klient nainštaluje predvolenú trasu alebo dve polovice predvolenej trasy, ktoré niektorí klienti preferujú, a odpoveď klientovi LAN teraz zodpovedá tunelu. Odíde poskytovateľovi, ktorý nemá dôvod ju preposielať, a klient LAN vidí vypršanie času, hoci host beží a odpovedá lokálne. Zachytenie to ukáže jasne a smerovacia tabuľka to vysvetlí.

Majte v hlave dve podsiete, kým čítate zvyšok. Jedna je fond adries VPN, odkiaľ prichádzajú vzdialení klienti, v tomto príklade 10.64.0.0/24. Druhá je LAN, ktorá musí ďalej fungovať, 172.16.24.0/24 s routerom na 172.16.24.1. Chyba je v tom, že prevádzku medzi nimi rozhoduje predvolená trasa.

Dokážte to zachytením a vyhľadaním

Predtým než čokoľvek zmeníte, overte, ktoré zariadenie odpoveď použije. Vyhľadanie je rýchlejšie ako zachytenie a odpovedá presne na otázku, na ktorú odpovie jadro pri zostavovaní paketu.

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

Čítajte odpoveď v dvoch častiach. Ak uvádza dev tun0, host odpoveď zapuzdri a odovzdá poskytovateľovi a klient LAN ju nikdy neuvidí. Ak uvádza dev eth0, ale klient predsa dostane vypršanie času, trasa je už správna a paket sa zahadzuje neskôr, čo je iný problém s inou opravou.

Zachytenie v tom istom kroku rieši pochybnosť, ktorú ping nemôže. Odpoveď echa, ktorá dorazí klientovi LAN, dokazuje, že nejaká cesta funguje, nie ktoré rozhranie ju nieslo, preto robte zachytenie na samotnom hoste a sledujte, odkiaľ rámce odchádzajú. Tlačiareň v tej istej podsieti ďalej odpovedá, pretože jej priama trasa je konkrétnejšia než predvolená trasa tunela. Presmerovaný port zlyháva rovnako ako každý iný tok, pretože rozhranie vyberá tabuľka, nie spojenie.

Nainštalujte najužšiu trasu, ktorá predčí tunel

Rozhoduje dĺžka prefixu, nie metrika, takže trasa pre fond klientov cez LAN router vyhrá nad každou predvolenou trasou, ktorú klient VPN nainštaluje. Chirurgia metriky nie je potrebná a predvolená trasa môže zostať presne tam, kde ju klient umiestnil.

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

Použite replace namiesto add, pretože klient, ktorý sa znova pripojí, už nainštaloval svoj vlastný záznam a druhý add zlyhá s chybou o existujúcej trase, ktorá sa číta ako problém s právami. Na hoste Windows je ekvivalentom route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, kde -p zachová záznam medzi reštartmi, keďže klient môže tabuľku znova zostaviť, keď tunel znovu nabehne. Na súčasnom hoste Windows je podporovaným ekvivalentom New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, pričom starší príkaz route zostáva ako staršia forma.

Jeden detail rozhoduje, či je to správne alebo len uveriteľné: ďalší skok musí byť router, ktorý skutočne vlastní cestu späť ku klientom. Nasmerovanie trasy na adresu, ktorá je sama dosiahnuteľná tunelom, vytvára slučku, ktorá sa prejavuje ako občasná strata, nie ako čisté zlyhanie. Pred zadaním riadku overte, že ďalší skok je v podsieti LAN.

Zachovajte odpoveď po opätovnom pripojení

Trasa pridaná ručne prežije v najlepšom prípade do ďalšieho pripojenia. Ak je fond klientov dynamický, pripnite ho v konfigurácii servera, aby prefix, ktorý ste smerovali, zostal prefixom, ktorý klienti dostávajú; inak záznam ukazuje na prázdny rozsah a príznak sa vráti po týždňoch bez zjavnej príčiny. Zapísanie trasy do vlastného up-skriptu klienta je druhá spoľahlivá možnosť, pretože sa spustí po tom, ako klient tabuľku prepísal.

Stavový firewall môže správnu trasu napriek tomu poraziť. Ak zachytenie teraz ukazuje, že odpoveď odchádza cez eth0, a klient predsa dostane vypršanie času, skontrolujte, či host paket nezahadzuje pred odoslaním. Prísne filtrovanie reverznej cesty a net.ipv4.conf.all.rp_filter nastavený na 1 zahadzujú pakety, ktorých zdroj by sa nesmeroval späť rozhraním, ktorým dorazili, a to je presne ten asymetrický prípad, ktorý ste práve vytvorili a potom opravili, a stav conntrack rozpráva ten istý príbeh pre presmerované porty.

Posledná kontrola je tá, ktorú ľudia preskakujú: zopakujte vyhľadanie po tom, ako tunel spadol a znova nabehol. Štyri hodnoty majú zodpovedať tomu, čo ste si zapísali: cieľ, ďalší skok, zariadenie a zvolený zdroj. Ak sa niektorá posunula, klient tabuľku prepísal a oprava patrí do jeho hookov, nie do histórie shellu.