Rekursia enkursigado: kiam la tunelo kaptas siajn proprajn pakaĵojn

La tunelo ekfunkcias, la protokolo montras kompletigitan manpremon, kaj unu sekundon poste la sama seanco mortas kaj rekonektiĝas en ciklo. Tiu ŝablono havas precizan kaŭzon: la vojo al la servilo nun montras en la tunelon, do la pakaĵoj, kiuj portas la tunelon, estas sendataj tra la tunelo. Nenio ŝanĝiĝis en la aŭtentikigo, kaj tial reenigi la akreditaĵojn faras neniun diferencon. Komparu la eksteran vojon antaŭ kaj post la vojoŝanĝo, kaj la rekursio fariĝas videbla.

Unue kontrolu la eksteran vojon

Estas du pakaĵoj en ludo, ne unu. La interna pakaĵo apartenas al la aplikaĵo kaj devus esti ĉifrita, dum la ekstera pakaĵo estas adresita al la servilo kaj devas atingi ĝin laŭ vojo, kiu ne dependas de la tunelo.

ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints

Demandu la kernon pri la vojo al la adreso de la servilo post kiam la tunelo funkcias, kaj denove post kiam la defaŭlta vojo ŝanĝiĝis. Sekva salto, kiu surteriĝas sur la tunela aparato, estas la rekursio mem, kaj ĝi videblas sen ajna pakaĵkaptado. Interfaca bindado, markoj aŭ reta nomspaco povas igi ordinaran serĉon nekompleta, do uzu la kuntekston, kiun la kliento mem uzas. Kiam la respondo ŝajnas ĝusta sed la seanco daŭre ciklas, legu la regulojn de la enkursiga politiko, ne nur la ĉefan tabelon.

Kial la seanco postvivas momenton

La manpremo kompletiĝas antaŭ ol la nova vojo estas instalita, do la unuaj sekundoj aspektas sanaj. Tuj kiam la kliento aldonas la defaŭltan vojon, la sekva ekstera pakaĵo sekvas ĝin en la interfacon, tra kiu tiu ekstera pakaĵo devas vojaĝi. La servilo vidas nenion, la kliento resendas, kaj la provo aŭ finiĝas pro tempolimo aŭ mortigas la seancejon kaj rekomencas.

Tiu ordo klarigas, kial tunelo povas funkcii sur tekkomputilo kaj malsukcesi sur enkursigilo, kaj kial la malsukceso ofte komenciĝas kiam la trafiko ekas, ne ĉe la konekto. Ĝi ankaŭ klarigas la ciklon: ĉiu restarto restarigas la seancejon antaŭ ol la vojo malebligas ĝin.

Trovu, kiu posedas la escepton de la finpunkto

Subtenataj klientoj mem aranĝas sian escepton: gastiga vojo al la servilo tra la origina enirejo, aŭ marko, kiu tenas la eksteran ingon ekster la tunelo. La demando estas, ĉu io alia forigis aŭ anstataŭigis ĝin.

Por vojo-bazita IPsec, ekzamenu la politikajn selektilojn, kiuj decidas, kiuj pakaĵoj eniras la tunelon, kaj konfirmu, ke la adreso de la kunulo estas ekskludita el ili. Por WireGuard, la fajroŝirma marko de la interfaco kaj ĝiaj politikaj reguloj tenas la transportajn pakaĵojn ekster la tunelo, do permane aldonita defaŭlta vojo povas rompi tiun aranĝon. Dua VPN-profilo aŭ administra skripto, kiu reverkas la defaŭltan vojon, estas ofta kulpulo. Larĝaj pretervojo-reguloj aldonataj unu post la alia estas la kutima rezulto, kaj ili transformas enkursigan cimon en tabelon, kiun neniu povas prizorgi.

Rekontrolu post retŝanĝo

Gastiga vojo tra Wi-Fi-enirejo estas ĝusta ĝis la maŝino transiros al alia reto. Tiam la sama simptomo revenas sen ajna ŝanĝo en la agordo.

Notu la adreson de la finpunkto, la vojon antaŭ kaj post konektiĝo, kaj la interfacon, kiun ĉiu el ili uzis. Tiuj tri faktoj kutime apartigas klientan cimon de anstataŭigo, kaj ili postvivas la personon, kiu kolektis ilin.

Rekonektiĝu en la nova reto kaj ripetu la legadon. Se la escepto denove mankas, la korekto apartenas al la profilo, kiu posedas ĝin, ne al unufoja komando tajpita dum paneo.