Falt VPN nei in DHCP-fernijing? Ferlykje de adressen

Leasefernijing en VPN-falen ferskine faak genôch tegearre yn logboeken dat minsken konkludearje dat it iene it oare feroarsaket. De tiidsoerienkomst is echt; de kausaliteit meastentiids net. In fernijing is in unicast-fersyk oan 'e tsjinner dy't de lease útjûn hat, om troch te gean mei deselde bining, en de tsjinner kin dy ferlingje sûnder dat de klant ien adres feroaret. It neigean fan 'e eigen wearden fan 'e klant om 'e barren hinne skiedt in stil fernijde lease fan in netwurk dat echt feroare ûnder in rinnende tunnel.

Begjin by de klant dy't útfviel

Iepenje earst it ferbininglog fan 'e klant en skriuw de tiid fan 'e útfal op 'e sekonde. Iepenje dan it netwurklok fan it bestjoeringssysteem foar deselde minút en lês yn folchoarder wat de ynterface die. Dy folchoarder is it hiele ûndersyk: in DHCP-barren foar de ûntferbining, in ûntferbining foar it DHCP-barren en twa barrens sûnder eat dertusken binne trije ferskillende fynsten. In logrigel dy't allinnich de lease neamt wylst de tunnel al wer ferbûn, is fersiering, gjin bewiis.

Skriuw de tiidline ûnderweis op ynstee fan dy yn it ûnthâld te hâlden. Tiidstimpels fan ferskillende ark komme selden perfekt oerien, en it ferskil sels is soms de ferklearring.

Ferlykje de fjouwer wearden om it barren hinne

Fjouwer wearden beskriuwe de lokale kant fan in ferbining goed genôch om in echte feroaring te fangen: it adres fan 'e ynterface, de standertgateway, de resolverlist en de operasjonele steat fan 'e ynterface. Nim se binnen in minút nei de útfal en ferlykje se mei in opname dy't makke is doe't de tunnel sûn wie.

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

In ûnferoare adres mei in ûnferoare gateway en in feroare resolverlist wiist op namme-oplossing ynstee fan routing, en de tunnel kin oerlibbe hawwe wylst tapassingen ophâlden hosts te finen. In feroare gateway betsjut dat it paad út it lokale netwurk ferpleatst is, wat genôch is om in rûte ûnjildich te meitsjen dy't nei de foarige wiisde. As alle fjouwer wearden oerienkomme mei de sûne opname, is de lease net jo oarsaak en wurdt de eigen werferbininglogika fan 'e klant it ûnderwerp. Nim de ferliking wylst de flater sichtber is, want in sûne opname nei in werstart hat in oare adresskiednis en sil net oerienkomme.

Wat in fernijing wol en net feroarje kin

RFC 2131 beskriuwt fernijing as in fersyk oan 'e oarspronklike tsjinner op 'e helte fan 'e leasstiid, mei werbining oan elke tsjinner op sân achtsten as de earste poging sûnder antwurd bliuwt. Gjin fan beide stappen freget de klant in oar adres te krijen, en in gearwurkjende tsjinner ferlingt meastentiids de besteande bining. In echte adresferoaring komt meastentiids oer in oar paad: in tsjinner dy't de fernijing wegeret, in klant dy't syn steat ferlear en op 'e nij begûn, of in netwurk dat it apparaat nei in oar segmint ferpleatste.

De publike kant fan 'e ferbining kin feroarje sûnder hokker lokale feroaring dan ek. Efter carrier-grade-oersetting kin it adres dat de VPN-pear sjocht opnij tawiisd wurde ûnôfhinklik fan wat de lokale lease die, en dy opnij-tawizing liket fan binnen de klant itselde as in lokale netwurkflater. It ferlykjen fan in lokaal rapportearre adres mei in waarnimming fan 'e pearkant is de iennichste manier om se te skieden.

As de klant him net oanpast

In klant dy't syn transport oan it âlde adres bûn hat, in ferâldere rûte nei de pear yn 'e cache set hat of in ynterface-identiteit bewarre hat, kin trochgean mei in paad te besykjen dat net mear bestiet. Dat is in oanpassingsflater, en it is te sjen as werhelle werstjoeringen nei in adres dat de host net mear berikke kin. Guon klanten regelje dat by ûntwerp: WireGuard bygelyks fernijt it einpunt fan in pear as in korrekt autentisearre pakket fan in nije boarne oankomt.

In hânmjittige werstart dy't tsjinst werombringt is in oanwizing wêr't de oanpassing mislearre, gjin bewiis dat leases en tunnels net gearfoegje kinne. Hâld it blokkearbelied yn stân by it testen, oars wurdt de test sels in útfal mei in oare oarsaak. Skriuw op oft de klant himsels werstelde, hoe lang it duorre en hokker adres er op 'e nij besocht; dy folchoarder fertelt jo mear as de ûntferbiningsoarsaak dy't yn 'e ynterface toand wurdt.

Werhelje it barren foardat jo it de skuld jouwe

Reprodusearje de betingst ynstee fan op 'e skema te wachtsjen: lit de lease los en fernij him, of twing it lykweardige kontrolearre barren ôf, en sjoch oft de tunnel oerlibbet. Op in beheard netwurk, koördinearje elke adresferoaring mei de netwurkeigner, want in willekeurige statyske tawizing kin botsing meitsje mei in apparaat dat dat adres al hat.

Werhelje nei in stipe repaasje itselde barren en test dan in tapassing en in nammesyking, want in tunnel dy't wer ferbynt mar DNS brekt, slagget foar in swakkere test as dy't fan belang is. Rapportearje de konkrete feroaring dy't jo waarnommen hawwe, mei syn tiidstimpel, ynstee fan de plande lease as oarsaak te neamen. It ferskil tusken dy twa rapporten is oft de folgjende persoan de flater reprodusearje kin of allinnich it geroft.