WAN-IP er endra og tunnelen fall: kontrollane i rekkjefølgje

Tunnelen fell, rutaren loggar ei gjenoppkobling, og ingenting på LAN-et har flytta seg. Ei ny WAN-adresse gjer den ytre sambandet ugyldig utan å endre noko inni: kjeldeadressa til klienten er endra, den gamle NAT-tilstanden peikar på ei kjelde som ikkje finst lenger, og den eksterne peeren sender kanskje framleis til den førre adressa. Gjenoppretting er normal åtferd, og det nyttige spørsmålet er kva tilstand som ikkje vart oppdatert.

Namngi hendinga før du les loggen

Undersøk kva som faktisk skjedde på aksesslaget. Ei fornying av ISP-leasinga er éi hending. Ei PPPoE-økt som vart gjenoppkobla er ei anna. Eit fibermodem som vart starta på nytt, eller ein WAN-failover frå éin uplink til ein annan, endrar den ytre adressa eller vegen hennar på ein tredje måte. Dei er ikkje same hendinga, og dei etterlèt ikkje same resten.

Ei gjenoppkoblingslinje i VPN-loggen er heller ikkje prov på ei WAN-endring. Ein inaktivitetstimeout, eit intervall for reautentisering og påvising av død peer gjev alle gjenoppkoblingar utan noka adresseendring. Samanlikn tidsstempla frå aksessloggen med VPN-loggen før du konkluderer noko, og hald samanlikningsvindauget breitt nok til å fange ei endring som skjedde om natta.

Roaming og gjenoppkobling er ulike protokollar

WireGuard har autentisert roaming innebygd i protokollen: når ein peer mottek ein korrekt autentisert pakke frå ei ny kjeldeadresse, oppdaterer han endepunktet til den peeren. WireGuards hurtigstart skildrar peer-konfigurasjonen som gjer dette mogleg, og difor kjem ein klient på ei skiftande adresse ofte tilbake utan ein synleg omstart.

OpenVPN oppfører seg annleis som standard. Ei UDP-økt kan avsluttast og koblast til på nytt, og den valfrie float-åtferda lèt ein autentisert peer halde fram frå ei ny adresse der konfigurasjonen tillèt det. TCP-baserte tunnelar er strengare, fordi sjølve sambandet er bunde til adresseparet. Den skilnaden avgjer om gjenopprettinga ser usynleg ut, eller om ho melder seg i loggen kvar gong.

Ingen av åtferdene seier noko om applikasjonane inni. Ein gjenoppretta tunnel gjenopprettar ikkje ei TCP-økt som peeren allereie ansåg som død.

Tilstand som tunnelen ikkje eig

Omsetjings- og rutertilstand overlever gjenoppkoblinga på måtar som overraskar folk. Ei conntrack-oppføring oppretta for den gamle kjelda held svarvegen forankra til ei adresse som ikkje finst lenger, og ho går ut etter sin eigen tidsplan, ikkje når tunnelen kom tilbake. Omstart av tunneltenesta forkortar ikkje den ventetida, så ei reparert lenkje kan framleis sjå broten ut ei stund.

Ruter og policyreglar kan vise til den gamle gatewayen eller grensesnittet. Eit regelsett som var rett før eit WAN-byte, kan peike på ein eining som no er nede, noko som gjev ein tunnel som rapporterer som tilkopla, og trafikk som ikkje kjem nokon veg. Dynamisk DNS for ein tenar du hostar, er eit separat problem frå ein klient som får ei ny kjelde. Oppføringa må oppdaterast for at eksterne klientar skal finne deg, og ingen konfigurasjon på klientsida kompenserer for ei adresse som omsetjinga lenger opp ikkje vil vidaresende.

Set kontrollane i rekkjefølgje utanfrå og inn

Rekkjefølgja nedanfor går frå den ytre sambandet og innover, og det er stoppen ved første feilande trinn som gjer ho nyttig: kvar gjennomgang utelukkar laget over. Hald den rekkjefølgja sjølv når feilen ser openber ut.

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

Den første kommandoen viser gjeldande endepunkt og alderen på handtrykket for kvar peer. Den andre og tredje viser om det ytre grensesnittet og ruta til endepunktet framleis gjev meining. conntrack-talet er ein grov kontroll for tilstand tilbake frå den førre adressa, og journalen er staden der årsaka til gjenoppkoblinga vert registrert.

Test deretter frå ein LAN-klient i staden for frå rutaren. Ein ping send av rutaren sjølv brukar ein annan veg enn vidaresend trafikk, så ein vellukka ruter-ping provar at tunnelen finst, og ingenting om rekkevidda til klienten.

Avgjer den forventa åtferda og skriv ho ned

Gjenoppkobling er rett åtferd for dei fleste utrullingar, så målet er ikkje å hindre det. Avgjer i staden kva som skal skje med trafikken i holet: stoppe han, halde han, eller bytte til ein annan veg. Den avgjerda høyrer til brannmuren og ruterpolitikken, ikkje i VPN-profilen.

Registrer aksesshendingane og gjenoppkoblingstidene saman i ei veke. Gjentekne endringar utan ei samsvarande aksesshending peikar på aksesstenesta, og å bytte VPN-profilen rettar ikkje ein uplink som stadig forhandlar på nytt. Eitt enkelt par oppføringar i same minutt avgjer spørsmålet for den hendinga og gjev den neste ei grunnlinje.