VPN i bllokuar pas rinisjes së ruterit: tre gjëra që ndryshuan
Profili nuk ndryshoi, por rruga nën të ndryshoi. Kontrolloni adresën lokale, hartëzimin e përkthyer dhe rrugën përpara se të rivendosni kredencialet.
Ruteri mbaron nisjen, laptopi ribashkohet me të njëjtin SSID, dhe VPN-i qëndron në lidhur pa u lëvizur asgjë. Profili i ruajtur është i paprekur. Ajo që skadoi poshtë tij ishte rruga, dhe klienti ende mban gjendjen që ndërtoi për atë të vjetrën.
Tre kushte përcaktojnë rregullimin. Kontrolloni ato me radhë, sepse të mëvonshmet janë punë e humbur nëse i pari tashmë shpjegon bllokimin.
Kushti i parë: adresa lokale ka ndryshuar
Një rinisje mund t'i japë makinës një adresë tjetër. Atëherë një VPN i konfiguruar me një pikë fundore lokale fikse vazhdon të përdorë një lidhje që nuk ekziston më. E njëjta gjë vlen për një klient që e lidhi socket-in e tij me adresën e vjetër. Ndërfaqja e tunelit mund të mbetet lart ndërsa çdo paketë që prodhon shkon në një vend të pavlerë.
Krahasoni adresën që përdor klienti me adresën që ka ndërfaqja tani. Një rrugë e paracaktuar që tregon drejt një portë e cila gjithashtu ka ndryshuar është e njëjta klasë problemi me një emër tjetër.
ip -4 addr show
ip route show default
ip route get 203.0.113.10
Kushti i dytë: hartëzimi i përkthyer ka humbur
Ruterat shtëpiak përkthejnë flukset dalëse, dhe ato hartëzime jetojnë në memorie. Një rinisje fshin çdo një prej tyre. Kjo është e padëmshme për një lidhje të re dhe vdekjeprurëse për një tunel që beson se fluksi i tij ekzistues është ende i vlefshëm. Atëherë pala tjetër nuk sheh asgjë, kështu që klienti nuk merr kurrë një gabim mbi të cilin mund të veprojë.
Këtu një tunel pa keepalive ngec në heshtje në vend që të dështojë me zë. Kufizimet e dokumentuara të WireGuard përshkruajnë të njëjtën formë dështimi. Një gjendje e gabuar e pikës fundore prodhon paketa të hedhura në vend të një diagnoze.
Një keepalive i vazhdueshëm prej 25 sekondash është zbutja e zakonshme, sepse rifreskon hartëzimin përpara se të skadojë një afat i papunësisë. Nuk rregullon një hartëzim që tashmë ka humbur. Bashkoni keepalive me logjikën e rilidhjes në vend që ta trajtoni si rregullim.
Kushti i tretë: adresa publike ka ndryshuar
Nëse adresa e jashtme e vetë ruterit ka ndryshuar, çdo gjë në anën tjetër që filtron sipas adresës së burimit tani sheh një partner tjetër. Tuneli mund të ngrihet dhe serveri mund të vazhdojë ta hedhë trafikun, gjë që duket si klient i prishur dhe në të vërtetë është politikë në skajin tjetër.
Shënoni adresën e jashtme përpara dhe pas rinisjes. Kur të dyja ndryshojnë, pyetja kalon nga klienti tek ai që mban listën e lejuar, dhe rivendosja e kredencialeve në laptop nuk mund të ndihmojë.
Rikuperoni në rendin e duhur
Përfundoni fillimisht çdo hyrje të kërkuar në portalin kapës, pastaj lini klientin të rilidhet me procedurën e tij të mbështetur në vend që ta vrisni procesin. Vëzhgoni nëse rikuperohen si identiteti ashtu edhe trafiku i të dhënave, sepse janë dy faza të ndryshme të së njëjtës lidhje.
Një faqe në memorie nuk provon asgjë, dhe as një aplikacion bisede që u rilidh vetë. Testoni pikën fundore që ju intereson vërtet me një kërkesë të re. Mbajeni politikën e trafikut të drejtpërdrejtë në fuqi gjatë ndërprerjes, sepse një përpjekje rilidhjeje nuk është bllokim.
Kur kjo përsëritet pas çdo rinisjeje, regjistri ka më shumë vlerë se përpjekja e re. Shënoni adresën lokale, portën, adresën e jashtme dhe gjendjen e klientit përpara dhe pas, pastaj krahasoni dy kolonat. Kjo e kthen një ankesë të paqartë në një gabim të ciklit të jetës që dikush mund ta rregullojë, dhe ndalon zëvendësimin e tretë të certifikatave për shkak të një afati të hartëzimit.