Ĉu VPN falas post DHCP-renovigo? Komparu la adresojn

Lu-renovigo kaj VPN-malsukceso aperas kune en protokoloj sufiĉe ofte, ke homoj konkludas, ke unu kaŭzas la alian. La tempa koincido estas reala; la kaŭzeco kutime ne. Renovigo estas unuĉela peto al la servilo, kiu eldonis la luon, peti daŭrigi la saman ligon, kaj la servilo povas etendi ĝin sen ke la kliento ŝanĝu eĉ unu adreson. Trairi la proprajn valorojn de la kliento ĉirkaŭ la okazaĵo apartigas luon renovigitan silente de reto, kiu vere ŝanĝiĝis sub funkcianta tunelo.

Komencu ĉe la kliento, kiu falis

Unue malfermu la konektan protokolon de la kliento kaj notu la tempon de la falo ĝis la sekundo. Poste malfermu la retan protokolon de la operaciumo por la sama minuto kaj legu laŭvice, kion faris la interfaco. Tiu ordo estas la tuta esploro: DHCP-okazaĵo antaŭ la malkonekto, malkonekto antaŭ la DHCP-okazaĵo, kaj du okazaĵoj sen io inter ili estas tri malsamaj trovaĵoj. Protokola linio, kiu nur mencias la luon dum la tunelo jam rekonektiĝis, estas ornamo, ne pruvo.

Skribu la templinion dum vi iras anstataŭ teni ĝin en la memoro. Tempomarkoj de malsamaj iloj malofte kongruas perfekte, kaj la diferenco mem estas foje la klarigo.

Komparu la kvar valorojn ĉirkaŭ la okazaĵo

Kvar valoroj priskribas la lokan flankon de konekto sufiĉe bone por kapti veran ŝanĝon: la adreso de la interfaco, la implicita enkursigilo, la listo de solviloj kaj la funkcia stato de la interfaco. Registru ilin ene de unu minuto post la falo kaj komparu kun registro farita dum la tunelo estis sana.

ip -4 -brief addr show dev wlan0
ip -4 route show default
resolvectl status | grep -A3 'DNS Servers'
journalctl -u NetworkManager --since -10m --no-pager | grep -i dhcp

Neŝanĝita adreso kun neŝanĝita enkursigilo kaj ŝanĝita solvila listo montras al nomsoado anstataŭ al enkursigo, kaj la tunelo eble pluvivis dum aplikoj ĉesis trovi gastigantojn. Ŝanĝita enkursigilo signifas, ke la vojo el la loka reto moviĝis, kio sufiĉas por malvalidigi vojon, kiu montris al la antaŭa. Se ĉiuj kvar valoroj kongruas kun la sana registro, la luo ne estas via kaŭzo kaj la propra rekonekta logiko de la kliento fariĝas la temo. Registru la komparon dum la difekto estas videbla, ĉar sana registro farita post restarto havas alian adres-historion kaj ne kongruos.

Kion renovigo povas kaj ne povas ŝanĝi

RFC 2131 priskribas renovigon kiel peton al la origina servilo je duono de la luotempo, kun religo al iu ajn servilo je sep okonoj, se la unua provo restas senresponda. Neniu el la paŝoj postulas, ke la kliento akiru alian adreson, kaj kunlabora servilo kutime etendas la ekzistantan ligon. Vera adresŝanĝo kutime venas per alia vojo: servilo rifuzas la renovigon, kliento perdis sian staton kaj rekomencis, aŭ reto movis la aparaton al alia segmento.

La publika flanko de la konekto povas ŝanĝiĝi sen iu ajn loka ŝanĝo. Malantaŭ traduko de operatora grado, la adreso, kiun vidas la VPN-partnero, povas esti realokita sendepende de io ajn, kion faris la loka luo, kaj tiu realokado aspektas de interne de la kliento idente al loka reta fiasko. Kompari loke raportitan adreson kun observado de la partnera flanko estas la sola maniero apartigi ilin.

Kiam la kliento malsukcesas adaptiĝi

Kliento, kiu ligis sian transporton al la malnova adreso, kaŝmemorigis kadukan vojon al la partnero aŭ konservis interfacan identecon, eble daŭre provas vojon, kiu ne plu ekzistas. Tio estas adapta difekto, kaj ĝi videblas kiel ripetaj retransmetoj al adreso, kiun la gastiganto ne plu povas atingi. Iuj klientoj traktas tion laŭdezajne: WireGuard, ekzemple, ĝisdatigas la finpunkton de partnero, kiam ĝuste aŭtentikigita paketo alvenas de nova fonto.

Manuala restarto, kiu restarigas servon, estas indico pri tio, kie la adaptado malsukcesis, ne pruvo, ke luoj kaj tuneloj estas neakordigeblaj. Tenu la blokan politikon dum testado, alie la testado mem fariĝas paneo kun alia kaŭzo. Notu, ĉu la kliento mem resaniĝis, kiom da tempo ĝi daŭris kaj kiun adreson ĝi reprovis; tiu sinsekvo diras al vi pli ol la malkonekta kialo montrata en la interfaco.

Ripetu la okazaĵon antaŭ ol kulpigi ĝin

Reproduktu la kondiĉon anstataŭ atendi la horaron: liberigu kaj renovigu la luon, aŭ devigu la ekvivalentan kontrolitan okazaĵon, kaj observu, ĉu la tunelo pluvivas. En administrata reto, kunordigu ajnan adresŝanĝon kun la retposedanto, ĉar arbitra statika atribuo povas kolizii kun aparato, kiu jam tenas tiun adreson.

Post subtenata riparo, ripetu la saman okazaĵon kaj poste testu aplikaĵon kaj nomserĉon, ĉar tunelo, kiu rekonektiĝas sed rompas DNS, trapasas pli malfortan teston ol tiu, kiu gravas. Raportu la specifan ŝanĝon, kiun vi observis, kun ĝia tempomarko, anstataŭ nomi la planitan luon kaŭzo. La diferenco inter tiuj du raportoj estas, ĉu la sekva persono povas reprodukti la difekton aŭ nur la famon.