Vagrant VM dingsta prisijungus VPN: kieno maršrutas lūžo

Mašina atsakė prieš minutę, VPN prisijungė, o dabar tas pats adresas baigiasi laiku. Tris gedimai sukuria šį simptomą, ir jie gyvena skirtingose mašinose. Šeimininkas gali prarasti maršrutą į privatų tinklą, svečio NAT diapazonas gali susidurti su diapazonu, kurį tunelis dabar skelbia, arba pilnas tunelis gali perimti visų šeimininko maršrutų nuosavybę. Išsiaiškinkite, kuris įvyko, prieš keisdami bet kokią konfigūraciją, nes kiekvienas taisymas gyvena kitur.

Stebėkite maršrutą, o ne mašiną

Pažiūrėkite į šeimininko maršrutizavimo sprendimą svečio adresui, kol tunelis veikia. Maršrutas, kuris vis dar rodo į tik šeimininko adapterį, nėra problema. Maršrutas, kuris dabar rodo į VPN adapterį, yra problema, ir jį pakeitė klientas, o ne jūs. Tai, kad adapteris išlaiko savo adresą, sako, kad sąsaja išgyveno, o tai kitas faktas nei kelio išgyvenimas.

SSH sesija, kuri nutrūksta tiksliai prisijungimo momentu, yra laukiamas elgesys. Klientas perdirba adapterius ir instaliuoja maršrutus, todėl ryšys miršta kelioms sekundėms. Gedimas yra ryšys, kuris niekada negrįžta, o ne tas, kuris tik sumirksėjo.

Užfiksuokite lentelę prieš tunelį ir dar kartą po jo, tada palyginkite tuos du išvestis. Skirtumas yra diagnozė, ir jis taip pat yra įrodymas, kurio paprašys tinklo savininkas.

ip -4 route get 192.168.56.10
ip -brief addr show
ip route show table main | head -20

Perskaitykite šeimininko lentelę prieš ir po

Linux sistemoje pirmenybė tarp persidengiančių maršrutų kyla iš prefikso ilgio ir metrikos, todėl konkretesnis VPN maršrutas laimi net kai jis neteisingas. Windows sistemoje sąsajos metrika nulemia lygiąsias, o tunelio adapteris paprastai ateina su žemesne metrika nei virtualus. Abiem atvejais matomas simptomas identiškas: paketai išeina per tunelio adapterį ir dingsta.

Atspausdinkite adapterius ir jų metrikas šalia svečio prefikso maršruto. Ta išvesčių pora atsako į nuosavybės klausimą vienu žvilgsniu.

Get-NetAdapter | Select-Object Name, InterfaceIndex, InterfaceMetric
Get-NetRoute -DestinationPrefix 192.168.56.0/24
route print -4 | Select-String '192.168.56'

Jei maršrutas pasikeitė, o adapterio metrika ne, klientas įdiegė konkuruojantį maršrutą. Jei metrika pasikeitė, klientas perskirstė adapterius. Abi galima sutaisyti, ir taisoma skirtingose vietose.

Kai svečio NAT diapazonas yra susidūrimas

VirtualBox NAT pagal nutylėjimą naudoja 10.0.2.0/24, o tunelis, stumiantis tą patį diapazoną, verčia svečią siųsti tą srautą į savo NAT tinklų sietuvą, o ne į tikrąją paskirtį. Paketas niekada nepalieka šeimininko, todėl joks ugniasienės žurnalas kitoje pusėje neparodys jo. Docker Machine turi tą pačią konfliktų klasę savo tik šeimininko plane, o to plano keitimas gali pareikalauti iš naujo sukurti mašiną kartu su jos sertifikatais.

Pasirinkite pakaitalą išvardydami, ką tunelis jau skelbia, tada ką naudoja biuro tinklas, tada ką pareiškė kiekvienas virtualus adapteris šiame šeimininke. Maršrutizavimą laužo persidengimas, o panašumas nesvarbus. Vienas diapazonas gali visiškai sėdėti kito viduje, nors iš pirmo žvilgsnio visai nepanašūs.

Nustatykite naują diapazoną kuriant mašiną arba pakeiskite jį ir įkelkite iš naujo, tada dar kartą išbandykite nepavykusį ryšį iš svečio. Svečio paties lentelė yra tas vaizdas, kuris svarbus.

VBoxManage modifyvm devbox --natnet1 10.77.0.0/24
vagrant reload devbox --provision
vagrant ssh devbox -c 'ip route get 10.20.0.15'

Atkurkite kelią nekovodami su klientu

Kiekviena platforma siūlo būdą vėl iškelti tik šeimininko prefiksą į priekį. macOS sistemoje statinis maršrutas į tik šeimininko sąsają veikia iki kito prisijungimo. Windows sistemoje žemesnė sąsajos metrika virtualiame adapteryje išlaiko jį pirmenybėje. Linux sistemoje pakeitimo operacija apima vieną prefiksą. Visi trys yra apėjimo būdai, nes klientas, kuris vėl reikalauja savo maršrutų, juos atšauks.

Skriptinkite patikrinimą, o ne aklą prisijungimą iš naujo paleidžiant. Mažas skriptas, kuris po kiekvieno prisijungimo atspausdina svečio prefikso maršrutą, paslaptį paverčia žurnalo eilute.

Jei profilis yra pilnas tunelis, paprašykite tinklo savininko suskaidyto tunelio arba dokumentuotos išimties. Tyliai pridėti maršrutus, kurie apeina saugumo politiką, nėra taisymas, tai antra problema, kuri ateina vėliau su auditoriumi.

Patikrinkite taisymą iš abiejų pusių

Po pakeitimo patikrinkite tris kelius: šeimininką į svečią, svečią į įmonės šeimininką ir svečią į internetą. Taisymas, kuris atkuria vieną ir sugadina kitą, yra konfigūracijos pakeitimas, apsimetantis remontu. Užfiksuokite tas pačias išvestis, kurias surinkote prieš pakeitimą, kad palyginimas būtų lygus su lygiu.

Užrašykite sąsają, metriką ir pasikeitusį maršrutą kartu su laiku, kad kitas atvejis būtų paieška, o ne perstatymas. Ta pastaba verta daugiau nei ilgas bilietų srautas.

ip -4 route get 192.168.56.10
traceroute -n -m 4 10.20.0.15
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

Kai šeimininkas vėl pasiekia svečią, o svečias pasiekia LAN, jūs atkūrėte kelią, kuriuo pradėjote. Kai veikia tik vienas iš jų, likęs gedimas yra kito savininko teritorijoje, ir skirtumas pasako, kuri tai teritorija.