WAN-IP ŝanĝiĝis kaj la tunelo falis: la kontroloj laŭ ordo

La tunelo falas, la enkursigilo registras rekonon, kaj nenio en la loka reto moviĝis. Nova WAN-adreso malvalidigas la eksteran konekton sen ŝanĝi ion interne: la fonta adreso de la kliento ŝanĝiĝis, la malnova NAT-stato montras al fonto, kiu ne plu ekzistas, kaj la fora samtavolulo eble ankoraŭ sendas al la antaŭa adreso. Reakiro estas normala konduto, kaj la utila demando estas, kiu stato malsukcesis ĝisdatiĝi.

Nomu la okazaĵon antaŭ ol legi la protokolon

Kontrolu, kio fakte okazis ĉe la alira tavolo. Renovigo de la luo de la provizanto estas unu okazaĵo. PPPoE-sesio, kiu rekonektiĝis, estas alia. Fibra modemo, kiu restartis, aŭ WAN-transiro de unu suprenligo al alia, ŝanĝas la eksteran adreson aŭ ĝian vojon laŭ tria maniero. Ili ne estas la sama okazaĵo kaj ili ne lasas la saman restaĵon.

Rekona linio en la VPN-protokolo ankaŭ ne pruvas WAN-ŝanĝon. Senaktiva tempolimo, reaŭtentiga intervalo kaj detekto de mortinta samtavolulo ĉiuj produktas rekonojn sen ajna adresa ŝanĝo. Komparu tempomarkojn de la alira protokolo kun la VPN-protokolo antaŭ ol konkludi ion, kaj tenu la komparan fenestron sufiĉe larĝa por kapti ŝanĝon, kiu okazis dum la nokto.

Vojaĝado kaj rekonekto estas malsamaj protokoloj

WireGuard havas aŭtentigitan vojaĝadon enkonstruitan en la protokolon: kiam samtavolulo ricevas ĝuste aŭtentigitan paketon de nova fonta adreso, ĝi ĝisdatigas la finpunkton de tiu samtavolulo. La rapidkomenco de WireGuard priskribas la samtavolulan agordon, kiu ebligas tion, kaj tial kliento sur ŝanĝiĝanta adreso ofte reakiras sen videbla restarto.

OpenVPN kondutas alie defaŭlte. UDP-sesio povas finiĝi kaj rekonektiĝi, kaj la laŭvola float-konduto permesas al aŭtentigita samtavolulo daŭrigi de nova adreso, kie la agordo permesas tion. TCP-bazitaj tuneloj estas pli striktaj, ĉar la konekto mem estas ligita al la adresparo. Tiu diferenco decidas, ĉu la reakiro aspektas nevidebla aŭ anoncas sin en la protokolo ĉiufoje.

Neniu el la kondutoj diras ion pri la aplikaĵoj interne. Reakirita tunelo ne restarigas TCP-sesion, kiun la samtavolulo jam konsideris mortinta.

Stato, kiun la tunelo ne posedas

Traduka kaj enkursiga stato postvivas la rekonon laŭ manieroj, kiuj surprizas homojn. conntrack-enskribo kreita por la malnova fonto tenas la respondan vojon ankrita al adreso, kiu ne plu ekzistas, kaj ĝi eksvalidiĝas laŭ sia propra horaro, ne kiam la tunelo revenis. Restarto de la tunela servo ne mallongigas tiun atendo, do riparita ligilo ankoraŭ povas aspekti rompita dum iom da tempo.

Itineroj kaj politikaj reguloj povas referenci la malnovan enpasejon aŭ interfacon. Regula aro, kiu estis korekta antaŭ WAN-ŝanĝo, povas montri al aparato, kiu nun estas mallevita, kio produktas tunelon, kiu raportas sin konektita, kaj trafikon, kiu iras nenie. Dinamika DNS por servilo, kiun vi gastigas, estas aparta problemo de kliento akiranta novan fonton. La rikordo devas esti ĝisdatigita, por ke foraj klientoj trovu vin, kaj neniu klienta agordo kompensas adreson, kiun traduko pli supre ne plusendos.

Ordigi la kontrolojn de ekstere enen

La suba ordo iras de la ekstera konekto enen, kaj halti ĉe la unua malsukcesa paŝo estas tio, kio faras ĝin utila: ĉiu trairo ekskluzivas la tavolon super si. Tenu tiun ordon eĉ kiam la misfunkcio aspektas evidenta.

wg show
ip -br addr show
ip route get 198.51.100.7
conntrack -L 2>/dev/null | grep -c ESTABLISHED
journalctl -u openvpn-client@home --since '-2 hours' | tail -n 40

La unua komando montras la nunan finpunkton kaj la aĝon de la manpremo por ĉiu samtavolulo. La dua kaj tria montras, ĉu la ekstera interfaco kaj la itinero al la finpunkto ankoraŭ havas sencon. La conntrack-nombro estas malglata kontrolo pri stato restanta de la antaŭa adreso, kaj la ĵurnalo estas la loko, kie la kialo de la rekonekto estas registrita.

Poste testu de lokreta kliento anstataŭ de la enkursigilo. Ping sendita de la enkursigilo mem uzas alian vojon ol plusendita trafiko, do sukcesa enkursigila ping pruvas, ke la tunelo ekzistas, kaj nenion pri la atingeblo de la kliento.

Decidu la atendatan konduton kaj skribu ĝin

Rekonekto estas korekta konduto por la plej multaj deplojoj, do la celo ne estas malhelpi ĝin. Decidu anstataŭe, kio okazu al trafiko dum la paŭzo: haltigi ĝin, teni ĝin, aŭ transiri al alia vojo. Tiu decido apartenas al la fajroŝirmilo kaj la enkursiga politiko, ne al la VPN-profilo.

Registru la alirajn okazaĵojn kaj la rekontempojn kune dum unu semajno. Ripetaj ŝanĝoj sen responda alira okazaĵo indikas la aliran servon, kaj anstataŭigo de la VPN-profilo ne riparos suprenligon, kiu daŭre renegocas. Unu paro da enskriboj en la sama minuto solvas la demandon por tiu okazaĵo kaj donas al la sekva bazlinion.