Kodėl viso tunelio maršrutas atkerta serverį, kuris jį neša

Įjunkite visą tunelį ir kiekviena paskirties vieta dabar priklauso VPN sąsajai, įskaitant mašiną, kuri jį užbaigia. Išoriniai paketai, nešantys tunelį, adresuoti tai mašinai, todėl maršrutas galiausiai suvartoja transportą, nuo kurio pats priklauso. Vienas papildomas konkretus maršrutas tai išsprendžia, o priežastį verta suprasti. Be tos priežasties kitas perrinkimas vėl įneš tą pačią klaidą.

Maršrutas, kuris suėda savo paties transportą

Inkapsuliavimas apvynioja kiekvieną paketą antra antrašte. Išorinė adresuota nuo vietinio fizinio adreso iki serverio viešojo adreso, ir ji turi kirsti fizinę jungtį, kol dar negali egzistuoti joks tunelis.

Dabar leiskite to viešojo adreso paieškai pasirinkti tunelį. Kad išsiųstų paketą, mašina turi jį inkapsuliuoti, o tam reikia maršruto į tą patį adresą, kuris grąžina tunelį. Klientai tai sprendžia vienu iš dviejų būdų. Atsargusis atsisako įdiegti numatytąjį maršrutą ir praneša apie klaidą, o mažiau atsargusis praneša apie sėkmę ir tada nieko nepajudina. Tylioji klaida yra ta, kuri kainuoja popietę.

Ilgiausio prefikso atitikimas nulemia paiešką prieš tikrinant bet kokią metriką, todėl vieno adreso maršrutas pranoksta kiekvieną numatytąjį maršrutą mašinoje. Tai yra visas mechanizmas už šio taisymo.

Įdiekite išimtį prieš numatytąjį

Sukurkite vieno adreso maršrutą serveriui, su fizine tarpine kaip kitu šuoliu, prieš pasislenkant numatytajam maršrutui. Tvarka svarbi: įdiegti vėliau reiškia gyventi su sulaužytu tuneliu, kol rašote.

Dauguma klientų tai daro neprašomi. OpenVPN ieško nuotolinio adreso ir jį prisega prieš perrašydamas numatytąją tarpinę, o jo parinktis route-delay skirta platformoms, kuriose ši seka lenktyniauja. wg-quick pasuka visai kitu keliu, žymėdamas paketus ir konsultuodamasis su politikos taisykle užuot pridėjęs išimtį. Skirtingi mechanizmai, tas pats reikalavimas: išorinis paketas turi pabėgti iš tunelio, kurį pats sukuria.

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

Paieškos išvestis yra priėmimo testas. Ji turi įvardyti fizinį įrenginį ir fizinį kitą šuolį. Tunelio įrenginys tame atsakyme reiškia, kad išimties trūksta arba ji įdėta po kažko, kas ją nustelbia.

Veidrodinis atspindys serveryje

Ta pati spąstai laukia kitoje pusėje, atvirkščiai. Duokite serveriui numatytąjį maršrutą per kitą tunelį arba įstumkite jam maršrutą, apimantį klientų viešuosius adresus, ir jo atsakymai įgis polinkį eiti ne ta kryptimi.

Įsivaizduokite klientą, kuris prisijungia ir siunčia užklausą. Atsakymas adresuotas to kliento viešajam adresui, kuris dabar atitinka tunelio maršrutą, todėl jis išvyksta iš kitos sąsajos, nešdamas šaltinį, kurio klientas niekada nesirinko. Klientas gali gauti tą paketą ir vis tiek jį atmesti, nes niekas jo nesaisto su išsiųsta užklausa. Pradėkite nuo serverio maršrutizavimo sprendimo, o ne nuo kliento laukimo laiko, nes tik vienas iš jų parodo tikrąjį pasirinkimą.

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

Yra trys taisymai ir jie nelygūs. Paslaugos priskyrimas fiziniam adresui arba šaltinio vertimas abu slepia maršrutizavimo sprendimą, o ne jį ištaiso. Atsakymo srauto tunelio telkiniui siuntimas per atskirą lentelę ištaiso priežastį, o kiti du priimtini tik tol, kol maršrutizavimo dizainas yra įšaldytas.

Išimtys, kurias tunelis nuolat vagia

Saujelė užduočių reikia atviro interneto net tada, kai tunelis valdo numatytąjį maršrutą, ir kiekvienai reikia savo išimties. Dinaminio DNS atnaujintuvas dažniausiai sulūžta pirmas.

Jis išsprendžia tiekėją, atidaro ryšį ir randa, kad jo paties paketai keliauja per tunelį, kurio adresas pasikeitė prieš kelias sekundes, todėl atnaujinimas nepavyksta arba paskelbia neteisingą adresą. Trys išeitys: prisekite tiekėją maršrutu į hostą per fizinę tarpinę, paleiskite atnaujinimą prieš pakylant tuneliui arba duokite atnaujintuvui politikos lentelę, kurios tunelis niekada neliečia. Laiko sinchronizavimas turi tą pačią ekspoziciją įrenginyje, kuris paleidžiamas be resolverio, o sertifikatų tikrinimo galiniai taškai dėl tos pačios priežasties priklauso sąrašui.

Išimtis, kurios niekas neužrašė, yra išimtis, kurią kitas perrinkimas tyliai numes.

Įrodykite tai po prisijungimo iš naujo, o ne prieš

Išbandykite tris paskirties vietas, o ne vieną: galinį tašką, privatų adresą už tunelio ir viešą adresą už jo. Viena sėkminga paieška beveik nieko nesako apie kitas dvi.

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

Tada iš naujo paleiskite ryšį, nes klientas, kuris prisijungdamas iš naujo atstato savo lentelę, atmes ranka įrašytą maršrutą. Jei veikia kill switch, patikrinkite, ar galinis taškas leidžiamas, kitaip tunelis negalės grįžti po tinklo pakeitimo ir simptomas atrodys kaip sutrikimas. Laikykite išimtį profilyje arba unit faile, o ne shell istorijoje, kad prisijungimas iš naujo ją atkurtų, o ne ištrintų.