Prečo trasa plného tunela odsekne server, ktorý ju nesie

Zapnite plný tunel a každé cieľové miesto teraz patrí rozhraniu VPN, vrátane stroja, ktorý ho ukončuje. Vonkajšie pakety nesúce tunel sú adresované tomuto stroju, takže trasa napokon spotrebúva transport, od ktorého závisí. Jedna ďalšia konkrétna trasa to rieši, a ten dôvod stojí za pochopenie. Bez neho ďalšia prestavba znovu zavedie poruchu.

Trasa, ktorá požiera vlastný transport

Zapuzdrenie obalí každý paket druhou hlavičkou. Vonkajšia je adresovaná z miestnej fyzickej adresy na verejnú adresu servera a musí prejsť cez fyzické spojenie, než môže existovať akýkoľvek tunel.

Teraz nechajte vyhľadanie tej verejnej adresy vybrať tunel. Aby stroj paket odoslal, musí ho zapuzdriť, čo si vyžaduje trasu na tú istú adresu, a tá vracia tunel. Klienti to riešia jedným z dvoch spôsobov. Opatrný odmietne nainštalovať predvolenú trasu a ohlási chybu, zatiaľ čo menej opatrný ohlási úspech a potom nič nepresunie. Tiché zlyhanie je to, ktoré stojí popoludnie.

Zhoda najdlhšieho prefixu rozhoduje o vyhľadaní skôr, než sa zohľadní akákoľvek metrika, takže trasa na jednu adresu prevyšuje každú predvolenú trasu na stroji. To je celý mechanizmus opravy.

Nainštalujte výnimku pred predvolenou trasou

Vytvorte trasu na jednu adresu pre server, s fyzickou bránou ako ďalším skokom, skôr než sa predvolená trasa pohne. Na poradí záleží: inštalácia potom znamená žiť s pokazeným tunelom, kým píšete.

Väčšina klientov to robí bez vyzvania. OpenVPN vyhľadá vzdialenú adresu a pripne ju pred prepísaním predvolenej brány, a jeho voľba route-delay existuje pre platformy, kde sa tento sled preteká. wg-quick ide úplne inou cestou, označuje pakety a obracia sa na pravidlo politiky namiesto pridania výnimky. Rôzne mechanizmy, rovnaká požiadavka: vonkajší paket musí uniknúť tunelu, ktorý vytvára.

ip route add 203.0.113.10/32 via 192.168.1.1 dev eth0
ip route get 203.0.113.10

Výstup vyhľadania je prijímací test. Musí pomenovať fyzické zariadenie a fyzického ďalšieho skoku. Tunelové zariadenie v tejto odpovedi znamená, že výnimka chýba alebo bola umiestnená za niečím, čo ju prebíja.

Zrkadlový obraz na serveri

Rovnaká pasca čaká na druhej strane, obrátene. Dajte serveru predvolenú trasu cez iný tunel, alebo mu pošlite trasu pokrývajúcu verejné adresy klientov, a jeho odpovede získajú návyk ísť nesprávnym smerom.

Predstavte si klienta, ktorý sa pripojí a pošle požiadavku. Odpoveď je adresovaná na verejnú adresu toho klienta, ktorá teraz zodpovedá tunelovej trase, takže vychádza z iného rozhrania a nesie zdroj, ktorý klient nikdy nezvolil. Klient môže tento paket prijať a napriek tomu ho zahodiť, pretože nič ho nespája s požiadavkou, ktorú poslal. Vychádzajte z rozhodnutia servera o smerovaní, nie z časového limitu klienta, keďže iba jedno z nich ukazuje skutočnú voľbu.

ip route get 198.51.100.44 from 10.90.0.1
ip rule show
sudo tcpdump -ni any host 198.51.100.44

Existujú tri opravy a nie sú rovnaké. Pripnutie služby k fyzickej adrese alebo preklad zdroja obe skrývajú rozhodnutie o smerovaní namiesto toho, aby ho opravili. Odosielanie odpovedného prenosu pre tunelový fond cez vyhradenú tabuľku opravuje príčinu a zostávajúce dve sú prijateľné len dovtedy, kým je návrh smerovania zmrazený.

Výnimky, ktoré tunel stále kradne

Hŕstka úloh potrebuje otvorený internet, aj keď tunel vlastní predvolenú trasu, a každá potrebuje vlastnú výnimku. Aktualizátor dynamického DNS sa zvyčajne pokazí ako prvý.

Preloží poskytovateľa, otvorí spojenie a zistí, že jeho vlastné pakety putujú tunelom, ktorého adresa sa zmenila pred niekoľkými sekundami, takže aktualizácia zlyhá alebo zverejní nesprávnu adresu. Tri východiská: pripnite poskytovateľa trasou k hostiteľovi cez fyzickú bránu, spustite aktualizáciu predtým, než tunel vstane, alebo dajte aktualizátoru tabuľku politiky, na ktorú tunel nikdy nesiaha. Synchronizácia času má rovnakú expozíciu na zariadení, ktoré štartuje bez resolvera, a koncové body overovania certifikátov patria na zoznam z rovnakého dôvodu.

Výnimka, ktorú nikto nezapísal, je výnimka, ktorú ďalšia prestavba ticho zahodí.

Dokážte to po opätovnom pripojení, nie pred ním

Otestujte tri ciele, nie jeden: koncový bod, súkromnú adresu za tunelom a verejnú adresu za ním. Jediné úspešné vyhľadanie nehovorí o zvyšných dvoch takmer nič.

ip route get 203.0.113.10
traceroute -n 203.0.113.10
ip route get 10.90.0.5
ip route get 1.1.1.1

Potom reštartujte pripojenie, pretože klient, ktorý pri opätovnom pripojení prestavia svoju tabuľku, zahodí trasu, ktorú ste napísali ručne. Ak je v hre kill switch, skontrolujte, či je koncový bod povolený, inak sa tunel po zmene siete nemôže vrátiť a príznak vyzerá ako výpadok. Uložte výnimku do profilu alebo do unit súboru namiesto histórie shellu, aby ju opätovné pripojenie znova vytvorilo, a nie vymazalo.