Zakaj pot popolnega tunela odreže strežnik, ki jo nosi
Privzeta pot skozi tunel zajame tudi zunanje pakete, ki ga nosijo. Pripnite končno točko s potjo do gostitelja in odgovore strežnika držite zunaj nje.
Vklopite popoln tunel in vsaka destinacija zdaj pripada vmesniku VPN, vključno s strojem, ki ga zaključi. Zunanji paketi, ki nosijo tunel, so naslovljeni na ta stroj, zato pot na koncu porabi transport, od katerega je odvisna. Ena dodatna posebna pot to reši, in razlog velja razumeti. Brez tega razloga naslednja ponovna gradnja spet vnese napako.
Pot, ki požre lastni transport
Enkapsulacija ovije vsak paket v drugo glavo. Zunanja je naslovljena z lokalnega fizičnega naslova na javni naslov strežnika in mora prečkati fizično povezavo, preden lahko obstaja kakršen koli tunel.
Zdaj naj iskanje tega javnega naslova izbere tunel. Da bi stroj poslal paket, ga mora enkapsulirati, kar zahteva pot na isti naslov, ta pa vrne tunel. Odjemalci to rešujejo na enega od dveh načinov. Previdni zavrne namestitev privzete poti in sporoči napako, medtem ko manj previdni sporoči uspeh in nato ničesar ne premakne. Tiha napaka je tista, ki stane popoldne.
Ujemanje najdaljše predpone odloči iskanje, preden se upošteva kakršna koli metrika, zato pot na en naslov preseže vsako privzeto pot na stroju. To je celoten mehanizem za popravkom.
Namestite izjemo pred privzeto potjo
Ustvarite pot na en naslov za strežnik, s fizičnim prehodom kot naslednjim skokom, preden se privzeta pot premakne. Vrstni red je pomemben: namestitev pozneje pomeni živeti s pokvarjenim tunelom, medtem ko tipkate.
Večina odjemalcev to naredi brez poziva. OpenVPN poišče oddaljeni naslov in ga pripne, preden prepiše privzeti prehod, njegova možnost route-delay pa obstaja za platforme, kjer ta zaporedje tekmuje. wg-quick ubere povsem drugo pot, z označevanjem paketov in posvetovanjem s pravilom politike namesto da bi dodal izjemo. Različni mehanizmi, enaka zahteva: zunanji paket mora ubežati tunelu, ki ga ustvari.
ip route add 203.0.113.10/32 via 192.168.1.1 dev eth0
ip route get 203.0.113.10
Izhod iskanja je sprejemni test. Navesti mora fizično napravo in fizični naslednji skok. Tunelska naprava v tem odgovoru pomeni, da izjema manjka ali da je bila postavljena za nečim, kar jo preglasi.
Zrcalna slika na strežniku
Ista past čaka na drugi strani, obrnjena. Dajte strežniku privzeto pot skozi drug tunel ali mu potisnite pot, ki pokriva javne naslove odjemalcev, in njegovi odgovori dobijo navado napačne smeri.
Predstavljajte si odjemalca, ki se poveže in pošlje zahtevo. Odgovor je naslovljen na javni naslov tega odjemalca, ki se zdaj ujema s potjo tunela, zato odide z drugega vmesnika in nosi vir, ki ga odjemalec nikoli ni izbral. Odjemalec lahko ta paket prejme in ga vseeno zavrže, ker ničesar ne povezuje z zahtevo, ki jo je poslal. Začnite pri odločitvi usmerjanja strežnika in ne pri časovni omejitvi odjemalca, saj le ena od obeh pokaže dejansko izbiro.
ip route get 198.51.100.44 from 10.90.0.1
ip rule show
sudo tcpdump -ni any host 198.51.100.44
Obstajajo tri popravila in niso enaka. Pripnitev storitve na fizični naslov ali prevajanje vira oboje skriva odločitev usmerjanja, namesto da bi jo popravilo. Pošiljanje odgovornega prometa za bazen tunela skozi namensko tabelo popravi vzrok, drugi dve pa sta sprejemljivi le, dokler je zasnova usmerjanja zamrznjena.
Izjeme, ki jih tunel nenehno krade
Pest opravil potrebuje odprt internet, tudi ko ima tunel privzeto pot, in vsako potrebuje svojo izjemo. Posodabljalnik dinamičnega DNS se običajno prvi pokvari.
Razreši ponudnika, odpre povezavo in ugotovi, da njegovi paketi potujejo skozi tunel, katerega naslov se je spremenil pred nekaj sekundami, zato posodobitev spodleti ali objavi napačen naslov. Tri izhodi: pripnite ponudnika s potjo do gostitelja skozi fizični prehod, zaženite posodobitev, preden se tunel dvigne, ali dajte posodabljalniku tabelo politike, ki se je tunel nikoli ne dotakne. Sinhronizacija časa ima enako izpostavljenost na napravi, ki se zažene brez razreševalnika, in končne točke preverjanja potrdil sodijo na seznam iz istega razloga.
Izjema, ki je nihče ni zapisal, je izjema, ki jo bo naslednja ponovna gradnja tiho spustila.
Dokažite to po ponovni povezavi, ne prej
Preizkusite tri cilje, ne enega: končno točko, zasebni naslov za tunelom in javni naslov onstran njega. Eno uspešno iskanje ne pove skoraj nič o drugih dveh.
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
Nato znova zaženite povezavo, ker bo odjemalec, ki ob ponovni povezavi obnovi svojo tabelo, zavrgel pot, ki ste jo vtipkali ročno. Če je vklopljen kill switch, preverite, ali je končna točka dovoljena, sicer se tunel po spremembi omrežja ne more vrniti in simptom je videti kot izpad. Shranite izjemo v profilu ali datoteki unit, ne v zgodovini lupine, da jo ponovna povezava poustvari, namesto da bi jo izbrisala.