Zašto ruta punog tunela odsijeca server koji je nosi

Uključite puni tunel i svaka destinacija sada pripada VPN interfejsu, uključujući i mašinu koja ga terminira. Vanjski paketi koji nose tunel adresirani su na tu mašinu, pa ruta na kraju troši transport o kojem ovisi. Jedna dodatna specifična ruta to rješava, a razlog vrijedi razumjeti. Bez tog razloga sljedeća ponovna izgradnja vraća kvar.

Ruta koja jede vlastiti transport

Enkapsulacija umotava svaki paket u drugo zaglavlje. Vanjsko zaglavlje adresirano je od lokalne fizičke adrese do javne adrese servera i mora prijeći fizičku vezu prije nego što ikakav tunel može postojati.

Neka sada pretraga te javne adrese odabere tunel. Da bi poslala paket, mašina ga mora enkapsulirati, što zahtijeva rutu do iste adrese, koja vraća tunel. Klijenti to rješavaju na jedan od dva načina. Pažljivi odbija instalirati podrazumijevanu rutu i prijavljuje grešku, dok manje pažljivi prijavljuje uspjeh i zatim ništa ne pomjeri. Tihi neuspjeh je onaj koji košta jedno poslijepodne.

Podudaranje najdužeg prefiksa odlučuje pretragu prije nego što se pogleda ikakva metrika, pa ruta za jednu adresu nadjačava svaku podrazumijevanu rutu na mašini. To je cijeli mehanizam iza popravke.

Instalirajte izuzetak prije podrazumijevane rute

Napravite rutu za jednu adresu za server, s fizičkim gatewayem kao sljedećim skokom, prije nego što se podrazumijevana ruta pomjeri. Redoslijed je važan: instaliranje poslije znači živjeti sa pokvarenim tunelom dok kucate.

Većina klijenata to radi bez podsticaja. OpenVPN traži udaljenu adresu i prikvači je prije nego što prepiše podrazumijevani gateway, a njegova opcija route-delay postoji za platforme gdje se taj slijed utrkuje. wg-quick ide sasvim drugim putem, označavajući pakete i konsultujući pravilo politike umjesto da dodaje izuzetak. Različiti mehanizmi, isti zahtjev: vanjski paket mora pobjeći iz tunela koji stvara.

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

Izlaz pretrage je prijemni test. Mora navesti fizički uređaj i fizički sljedeći skok. Tunelski uređaj u tom odgovoru znači da izuzetak nedostaje ili je postavljen nakon nečega što ga nadjačava.

Zrcalna slika na serveru

Ista zamka čeka na drugoj strani, obrnuta. Dajte serveru podrazumijevanu rutu kroz drugi tunel ili mu gurnite rutu koja pokriva javne adrese klijenata, i njegovi odgovori stječu naviku pogrešnog smjera.

Zamislite klijenta koji se poveže i pošalje zahtjev. Odgovor je adresiran na javnu adresu tog klijenta, koja sada odgovara tunelskoj ruti, pa izlazi s drugog interfejsa noseći izvor koji klijent nikad nije birao. Klijent može primiti taj paket i ipak ga odbaciti, jer ga ništa ne veže za zahtjev koji je poslao. Radite od serverove odluke o rutiranju, a ne od klijentovog tajm-auta, jer samo jedna od njih pokazuje stvarni izbor.

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

Postoje tri popravke i nisu jednake. Prikvačivanje usluge za fizičku adresu ili prevođenje izvora oboje skriva odluku o rutiranju umjesto da je ispravi. Slanje odgovornog saobraćaja za tunelski pul kroz namjensku tablicu ispravlja uzrok, a druge dvije su prihvatljive samo dok je dizajn rutiranja zamrznut.

Izuzeci koje tunel stalno krade

Nekolicina poslova treba otvoreni internet čak i dok tunel posjeduje podrazumijevanu rutu, i svaki treba svoj izuzetak. Ažurator dinamičkog DNS-a obično se prvi pokvari.

On razrješava provajdera, otvara vezu i otkrije da njegovi paketi putuju kroz tunel čija se adresa promijenila prije nekoliko sekundi, pa ažuriranje ne uspije ili objavi pogrešnu adresu. Tri izlaza: prikvačite provajdera rutom do hosta kroz fizički gateway, pokrenite ažuriranje prije nego što se tunel podigne, ili dajte ažuratoru tablicu politike koju tunel nikad ne dira. Sinhronizacija vremena ima istu izloženost na uređaju koji se podiže bez resolvera, a krajnje točke za provjeru certifikata pripadaju na listu iz istog razloga.

Izuzetak koji niko nije zapisao je izuzetak koji će sljedeća ponovna izgradnja tiho ispustiti.

Dokažite to nakon ponovnog povezivanja, ne prije

Testirajte tri destinacije, ne jednu: krajnju točku, privatnu adresu iza tunela i javnu adresu s one strane. Jedna uspješna pretraga ne govori gotovo ništa o druge dvije.

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

Zatim ponovo pokrenite vezu, jer klijent koji obnovi svoju tablicu pri ponovnom povezivanju odbacit će rutu koju ste upisali ručno. Ako je uključen kill switch, provjerite da je krajnja točka dopuštena, inače se tunel ne može vratiti nakon promjene mreže i simptom izgleda kao prekid. Pohranite izuzetak u profilu ili unit datoteci, a ne u historiji shella, da ga ponovno povezivanje ponovo stvori umjesto da ga izbriše.