Miks täistunneli marsruut lõikab ära serveri, mis seda kannab

Lülita sisse täistunnel ja iga sihtkoht kuulub nüüd VPN-liidesele, sealhulgas masin, mis selle lõpetab. Tunneli kandvad välised paketid on adresseeritud sellele masinale, nii et marsruut kulutab lõpuks transporti, millest ta sõltub. Üks täiendav kindel marsruut lahendab selle, ja põhjus tasub mõistmist. Ilma selle põhjuseta toob järgmine ümberehitus vea tagasi.

Marsruut, mis sööb omaenda transporti

Kapseldamine mähitakse iga pakett teise päisesse. Välimine on adresseeritud kohalikult füüsiliselt aadressilt serveri avalikule aadressile ja peab ületama füüsilise lüli enne, kui ükskõik milline tunnel saab eksisteerida.

Nüüd lase selle avaliku aadressi otsingul tunnel valida. Paketi saatmiseks peab masin selle kapseldama, mis nõuab marsruuti samale aadressile, mis tagastab tunneli. Kliendid käsitlevad seda ühel kahest viisil. Hoolikas keeldub vaikemarsruuti paigaldamast ja teatab veast, samal ajal kui vähem hoolikas teatab õnnestumisest ja ei liiguta siis midagi. Vaikne ebaõnnestumine on see, mis maksab ühe pärastlõuna.

Pikima eesliite vaste otsustab otsingu enne, kui ühtegi mõõdikut vaadatakse, nii et ühe aadressi marsruut ületab masina iga vaikemarsruudi. See on kogu paranduse mehhanism.

Paigalda erand enne vaikimisi marsruuti

Loo serveri jaoks ühe aadressi marsruut, füüsilise lüüsiga järgmise hüppena, enne kui vaikemarsruut liigub. Järjekord on oluline: hiljem paigaldamine tähendab katkise tunneliga elamist sinu tippimise ajal.

Enamik kliente teeb seda küsimata. OpenVPN otsib kaugema aadressi üles ja kinnitab selle enne vaikelüüsi ümberkirjutamist, ja selle route-delay valik on mõeldud platvormidele, kus see järjestus võistleb. wg-quick läheb hoopis teist teed, märgistades pakette ja konsulteerides poliitikareegliga selle asemel, et erand lisada. Erinevad mehhanismid, sama nõue: väline pakett peab pääsema välja tunnelist, mille ta loob.

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

Otsingu väljund on vastuvõtutest. See peab nimetama füüsilise seadme ja füüsilise järgmise hüppe. Tunneliseade selles vastuses tähendab, et erand puudub või paigutati millegi järele, mis selle tühistab.

Peegelpilt serveris

Sama lõks ootab teisel pool, tagurpidi. Anna serverile vaikemarsruut läbi teise tunneli või lükka talle marsruut, mis katab klientide avalikud aadressid, ja selle vastused omandavad vale suuna harjumuse.

Kujuta ette klienti, kes ühendub ja saadab päringu. Vastus on adresseeritud selle kliendi avalikule aadressile, mis nüüd vastab tunnelimarsruudile, nii et see väljub teisest liidesest, kandes allikat, mida klient kunagi ei valinud. Klient võib selle paketi vastu võtta ja siiski kõrvale heita, sest miski ei seo seda saadetud päringuga. Lähtu serveri marsruutimisotsusest, mitte kliendi ajapiirangust, kuna ainult üks neist näitab tegelikku valikut.

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

Parandusi on kolm ja need ei ole võrdsed. Teenuse kinnitamine füüsilise aadressi külge või allika tõlkimine mõlemad varjavad marsruutimisotsust selle parandamise asemel. Tunnelibasseini vastusliikluse saatmine eraldi tabeli kaudu parandab põhjuse, ja ülejäänud kaks on vastuvõetavad ainult seni, kuni marsruutimise disain on külmutatud.

Erandid, mida tunnel pidevalt varastab

Peotäis töid vajab avatud internetti isegi siis, kui tunnel omab vaikemarsruuti, ja igaüks vajab oma erandit. Dünaamilise DNS-i uuendaja on tavaliselt esimene, mis katkeb.

See lahendab teenusepakkuja, avab ühenduse ja avastab, et tema enda paketid liiguvad läbi tunneli, mille aadress muutus sekundeid tagasi, nii et uuendus ebaõnnestub või avaldab vale aadressi. Kolm väljapääsu: kinnita teenusepakkuja hostimarsruudiga läbi füüsilise lüüsi, käivita uuendus enne tunneli tõusmist või anna uuendajale poliitikatabel, mida tunnel kunagi ei puuduta. Aja sünkroonimisel on sama eksponeeritus seadmel, mis käivitub ilma resolverita, ja sertifikaadi valideerimise lõpp-punktid kuuluvad nimekirja samal põhjusel.

Erand, mida keegi kirja ei pannud, on erand, mille järgmine ümberehitus vaikselt maha jätab.

Tõesta seda pärast taasühendamist, mitte enne

Testi kolme sihtkohta, mitte ühte: lõpp-punkt, tunnelitagune privaatne aadress ja sellest kaugemal olev avalik aadress. Üks õnnestunud otsing ei ütle kahe teise kohta peaaegu midagi.

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

Seejärel taaskäivita ühendus, sest klient, kes taasühendamisel oma tabeli uuesti ehitab, heidab kõrvale marsruudi, mille sa käsitsi kirjutasid. Kui kill switch on mängus, kontrolli, et lõpp-punkt on lubatud, muidu ei saa tunnel pärast võrgu muutust tagasi tulla ja sümptom näeb välja nagu katkestus. Salvesta erand profiili või unit-faili, mitte shelli ajalukku, et taasühendamine looks selle uuesti, selle asemel et see kustutada.