Zašto ruta punog tunela odsijeca poslužitelj koji je nosi

Uključite puni tunel i svaka destinacija sada pripada VPN sučelju, uključujući i stroj koji ga terminira. Vanjski paketi koji nose tunel adresirani su na taj stroj, pa ruta na kraju troši promet 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 promet

Enkapsulacija umotava svaki paket u drugo zaglavlje. Vanjsko zaglavlje adresirano je od lokalne fizičke adrese do javne adrese poslužitelja 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 poslao paket, stroj 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 pomiče. 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 stroju. To je cijeli mehanizam iza popravka.

Instalirajte izuzetak prije podrazumijevane rute

Napravite rutu za jednu adresu za poslužitelj, s fizičkim pristupnikom kao sljedećim skokom, prije nego što se podrazumijevana ruta pomakne. Redoslijed je važan: instaliranje poslije znači živjeti s pokvarenim tunelom dok tipkate.

Većina klijenata to radi bez poticaja. OpenVPN traži udaljenu adresu i prikvači je prije nego što prepiše podrazumijevani pristupnik, a njegova opcija route-delay postoji za platforme gdje se taj slijed utrkuje. wg-quick ide sasvim drugim putem, označavajući pakete i konzultirajuć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 prijamni 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 poslužitelju

Ista zamka čeka na drugoj strani, obrnuta. Dajte poslužitelju 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 sučelja 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 odluke poslužitelja o usmjeravanju, a ne od klijentova vremenskog ograničenja, 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 popravka i nisu jednaka. Prikvačivanje usluge za fizičku adresu ili prevođenje izvora oboje skriva odluku o usmjeravanju umjesto da je ispravi. Slanje odgovornog prometa za tunelski bazen kroz namjensku tablicu ispravlja uzrok, a druge dvije su prihvatljive samo dok je dizajn usmjeravanja zamrznut.

Izuzetci koje tunel stalno krade

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

On razrješava pružatelja usluga, 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 pružatelja rutom do hosta kroz fizički pristupnik, pokrenite ažuriranje prije nego što se tunel podigne, ili dajte programu tablicu politike koju tunel nikad ne dira. Sinkronizacija vremena ima istu izloženost na uređaju koji se podiže bez razrješivača, a krajnje točke za provjeru certifikata pripadaju na popis iz istog razloga.

Izuzetak koji nitko 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 ponovno 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 povijesti shella, da ga ponovno povezivanje ponovno stvori umjesto da ga izbriše.