A bie VPN pas një rinovimi DHCP? Krahasoni adresat

Rinovimi i qirasë dhe dështimi i VPN shfaqen shpesh bashkë në regjistra saqë njerëzit përfundojnë se njëri shkakton tjetrin. Përputhja kohore është e vërtetë; shkakësia zakonisht jo. Një rinovim është një kërkesë unicast drejtuar serverit që lëshoi qiranë, për të vazhduar përdorimin e të njëjtit lidhje, dhe serveri mund ta zgjasë pa ndryshuar klienti as edhe një adresë. Shqyrtimi i vlerave të vetë klientit rreth ngjarjes ndan një qira të rinovuar në heshtje nga një rrjet që ndryshoi vërtet nën një tunel në punë.

Filloni nga klienti që ra

Së pari hapni regjistrin e lidhjeve të klientit dhe shënoni kohën e rënies deri në sekondë. Pastaj hapni regjistrin e rrjetit të sistemit operativ për të njëjtën minutë dhe lexoni me radhë çfarë bëri ndërfaqja. Ky rend është i gjithë hetimi: një ngjarje DHCP para shkëputjes, një shkëputje para ngjarjes DHCP dhe dy ngjarje pa asgjë mes tyre janë tre gjetje të ndryshme. Rreshti i regjistrit që përmend vetëm qiranë ndërsa tuneli po rilidhej tashmë është zbukurim, jo provë.

Shkruani vijën kohore ndërsa shkoni përpara në vend që ta mbani në mendje. Vulat kohore nga mjete të ndryshme rrallë përputhen plotësisht, dhe vetë diferenca ndonjëherë është shpjegimi.

Krahasoni katër vlerat rreth ngjarjes

Katër vlera e përshkruajnë mjaft mirë anën lokale të një lidhje për të kapur një ndryshim të vërtetë: adresa e ndërfaqes, porta e parazgjedhur, lista e zgjidhësve dhe gjendja operative e ndërfaqes. Kapini brenda një minute pas rënies dhe krahasoni me një regjistrim të bërë kur tuneli ishte i shëndetshëm.

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

Një adresë e pandryshuar me portë të pandryshuar dhe listë zgjidhësish të ndryshuar tregon zgjidhjen e emrave dhe jo rrugëzimin, dhe tuneli mund të ketë mbijetuar ndërsa aplikacionet pushuan së gjeturi hoste. Një portë e ndryshuar do të thotë që rruga jashtë rrjetit lokal lëvizi, dhe kjo mjafton për të zhvleftësuar një rrugë që tregonte te ajo e mëparshmja. Nëse të katër vlerat përputhen me regjistrimin e shëndetshëm, qiraja nuk është shkaku juaj dhe tema bëhet logjika e rilidhjes së vetë klientit. Kapeni krahasimin ndërsa defekti është i dukshëm, sepse një regjistrim i shëndetshëm i bërë pas një rindizjeje ka histori adresash të ndryshme dhe nuk do të përputhet.

Çfarë mund dhe çfarë nuk mund të ndryshojë një rinovim

RFC 2131 e përshkruan rinovimin si një kërkesë drejtuar serverit origjinal në gjysmën e kohës së qirasë, me rilidhje te çdo server në shtatë të tetat nëse përpjekja e parë mbetet pa përgjigje. Asnjë nga hapat nuk kërkon që klienti të marrë një adresë tjetër, dhe një server bashkëpunues zakonisht zgjat lidhjen ekzistuese. Një ndryshim i vërtetë adrese zakonisht vjen në një rrugë tjetër: një server refuzon rinovimin, një klient humbi gjendjen e tij dhe filloi nga e para, ose një rrjet e zhvendosi pajisjen në një segment tjetër.

Ana publike e lidhjes mund të ndryshojë pa asnjë ndryshim lokal. Pas përkthimit të nivelit të operatorit, adresa që shikon partneri i VPN mund të ricaktohet pavarësisht nga çdo gjë që bëri qiraja lokale, dhe ky ricaktim duket identik me një dështim të rrjetit lokal nga brenda klientit. Krahasimi i një adrese të raportuar lokalisht me një vëzhgim nga ana e partnerit është mënyra e vetme për t'i ndarë ato.

Kur klienti nuk arrin të përshtatet

Një klient që e lidhi transportin me adresën e vjetër, ruajti në cache një rrugë të vjetruar drejt partnerit ose ruajti një identitet ndërfaqeje mund të vazhdojë të provojë një rrugë që nuk ekziston më. Ky është një defekt përshtatjeje, dhe shihet si ritransmetime të përsëritura drejt një adrese që hosti nuk mund ta arrijë më. Disa klientë e trajtojnë atë sipas dizajnit: WireGuard, për shembull, përditëson pikën fundore të një partneri kur një paketë e vërtetuar saktë vjen nga një burim i ri.

Një rindizje manuale që rikthen shërbimin është një indicje se ku dështoi përshtatja, jo një provë se qiratë dhe tunelet janë të papajtueshme. Mbani politikën e bllokimit në vend gjatë testimit, përndryshe vetë testi bëhet një ndërprerje me një shkak tjetër. Shënoni nëse klienti u rikuperua vetë, sa kohë zgjati dhe cilën adresë provoi përsëri; ai sekuencë ju tregon më shumë se arsyeja e shkëputjes e shfaqur në ndërfaqe.

Përsëritni ngjarjen përpara se ta fajësoni

Riprodhoni kushtin në vend që të prisni orarin: lëshoni dhe rinovoni qiranë, ose detyroni ngjarjen ekuivalente të kontrolluar, dhe vëzhgoni nëse tuneli mbijeton. Në një rrjet të menaxhuar, koordinoni çdo ndryshim adrese me pronarin e rrjetit, sepse një caktim statik arbitrar mund të përplaset me një pajisje që e mban tashmë atë adresë.

Pas një rregullimi të mbështetur, përsëritni të njëjtën ngjarje dhe më pas testoni një aplikacion dhe një kërkim emri, sepse një tunel që rilidhet por thyen DNS kalon një test më të dobët se ai që ka rëndësi. Raportoni ndryshimin konkret që vëzhguat, me vulën e tij kohore, në vend që të emërtoni qiranë e planifikuar si shkak. Dallimi mes dy raporteve është nëse personi tjetër mund ta riprodhojë defektin apo vetëm thashethemin.