Vagrant VM malaperas kiam la VPN konektiĝas: kies vojo rompiĝis

La maŝino respondis antaŭ unu minuto, la VPN konektiĝis, kaj nun la sama adreso ne respondas. Tri difektoj produktas tiun simptomon, kaj ili loĝas en malsamaj maŝinoj. La gastiganto povas perdi la vojon al la privata reto, la NAT-gamoj de la gasto povas kolizii kun gamo, kiun la tunelo nun anoncas, aŭ plena tunelo povas ekposedi ĉiun vojon sur la gastiganto. Trovu, kiu okazis, antaŭ ol ŝanĝi iun ajn agordon, ĉar ĉiu riparo loĝas aliloke.

Rigardu la vojon, ne la maŝinon

Rigardu la vojigan decidon de la gastiganto por la adreso de la gasto, dum la tunelo funkcias. Vojo, kiu ankoraŭ montras al la adaptilo nur-gastiganta, ne estas la problemo. Vojo, kiu nun montras al la VPN-adaptilo, estas la problemo, kaj la kliento ŝanĝis ĝin, ne vi. Tio, ke la adaptilo konservas sian adreson, diras, ke la interfaco postvivis, kio estas alia fakto ol la postvivo de la vojo.

SSH-sesio, kiu falas ĝuste en la konekta momento, estas atendata konduto. La kliento reuzas adaptilojn kaj instalas vojojn, do la konekto mortas por kelkaj sekundoj. La difekto estas la konekto, kiu neniam revenas, ne tiu, kiu nur ekbrilis.

Kaptu la tabelon antaŭ la tunelo kaj denove post ĝi, poste komparu tiujn du eligojn. La diferenco estas la diagnozo, kaj ĝi ankaŭ hazarde estas la pruvo, kiun retposedanto petos.

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

Legu la tabelon de la gastiganto antaŭ kaj post

En Linux la prefero inter interkovraj vojoj venas de la prefiksa longo kaj la metriko, do pli specifa VPN-vojo venkas eĉ kiam ĝi estas malĝusta. En Windows la interfaca metriko decidas la egalon, kaj la tunela adaptilo kutime alvenas kun pli malalta metriko ol la virtuala. En ambaŭ kazoj la videbla simptomo estas identa: pakaĵoj forlasas per la tunela adaptilo kaj malaperas.

Presu la adaptilojn kaj iliajn metrikojn apud la vojo por la gasto-prefikso. Tiu paro de eligoj respondas la poseddemandon per unu rigardo.

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

Se la vojo ŝanĝiĝis sed la adaptila metriko ne, la kliento instalas konkurencan vojon. Se la metriko ŝanĝiĝis, la kliento reordigis la adaptilojn. Ambaŭ estas ripareblaj, kaj ili ripariĝas en malsamaj lokoj.

Kiam la NAT-gamo de la gasto estas la kolizio

VirtualBox NAT uzas 10.0.2.0/24 defaŭlte, kaj tunelo, kiu puŝas la saman gamon, igas la gaston sendi tiun trafikon al sia NAT-pordego anstataŭ al la reala celo. La pakaĵo neniam forlasas la gastiganton, do neniu fajroŝirma registro ĉe la alia flanko montros ĝin. Docker Machine havas la saman klason de konflikto en sia nur-gastiganta plano, kaj ŝanĝi tiun planon povas postuli rekrei la maŝinon kune kun ĝiaj atestiloj.

Elektu la anstataŭaĵon listigante, kion la tunelo jam anoncas, poste kion uzas la oficeja reto, poste kion postulis ĉiu virtuala adaptilo sur ĉi tiu gastiganto. Interkovro rompas la vojigon, kaj simileco estas nekoncerna. Unu gamo povas sidi tute ene de alia, dum ĝi unuavide tute ne similas.

Agordu la novan gamon kiam la maŝino kreiĝas, aŭ ŝanĝu ĝin kaj reŝargu, poste retestu la malsukcesan konekton de la gasto. La propra tabelo de la gasto estas la vido, kiu gravas.

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

Restarigu la vojon sen batali kontraŭ la kliento

Ĉiu platformo proponas manieron remeti la nur-gastigantan prefikson antaŭen. En macOS statika vojo al la nur-gastiganta interfaco funkcias ĝis la sekva konekto. En Windows pli malalta interfaca metriko sur la virtuala adaptilo tenas ĝin preferata. En Linux anstataŭiga operacio kovras unu prefikson. Ĉiuj tri estas provizoraj solvoj, ĉar kliento, kiu reasertas siajn vojojn, malfaros ilin.

Skribu la kontrolon kiel skripto anstataŭ blinda rekonekto ĉe lanĉo. Malgranda skripto, kiu presas la vojon por la gasto-prefikso post ĉiu konekto, igas misteron linio en registro.

Se la profilo estas plena tunelo, petu la retposedanton pri dividita tunelado aŭ dokumentita escepto. Silente aldoni vojojn, kiuj evitas sekurecan politikon, ne estas riparo, ĝi estas dua problemo, kiu alvenos poste kun revizoro.

Kontrolu la riparon ambaŭflanke

Kontrolu tri vojojn post la ŝanĝo: gastiganto al gasto, gasto al la firmaa gastiganto, kaj gasto al la interreto. Riparo, kiu restarigas unu el ili kaj rompas alian, estas agorda ŝanĝo maskita kiel riparo. Kaptu la samajn eligojn, kiujn vi kolektis antaŭ la ŝanĝo, por ke la komparo estu simila kun simila.

Notu la interfacon, la metrikon kaj la vojon, kiuj ŝanĝiĝis, kune kun la tempo, por ke la sekva okazo estu serĉo anstataŭ rekonstruo. Tiu noto valoras pli ol longa bileta fadeno.

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

Kiam la gastiganto denove atingas la gaston kaj la gasto atingas la lokan reton, vi restarigis la vojon, kun kiu vi komencis. Kiam nur unu el tiuj funkcias, la restanta difekto estas en la teritorio de la alia posedanto, kaj la diferenco diras al vi, kiu teritorio ĝi estas.