Pse një rrugë VPN e fshirë kthehet pas rilidhjes

Një rrugë që e fshite me dorë kthehet pas rilidhjes tjetër, dhe tabela duket saktësisht si më parë. Ky nuk është një defekt rrugëtimi: diçka e rikrijon hyrjen nga konfigurimi ose nga një veprim i ciklit të jetës së lidhjes. Shumica e runbook-ve ndalen te tabela aktive, prandaj fshirja duket se funksionon për një minutë dhe më pas dështon. Identifikoni pronarin, ndryshojeni atë dhe provojeni në një rilidhje.

Kush e instaloi rrugën

Filloni me një listë kandidatësh, jo me një rregullim. Një profil VPN mund të mbajë rrugët e veta, një server mund t'i pushojë ato në kohën e lidhjes, një profil i menaxherit të rrjetit mund t'i deklarojë ato, një njësi nisjeje ose skript mund t'i shtojë ato, dhe zbatimet e IPsec instalojnë rrugë për përzgjedhësit e trafikut që negociojnë. Rregullat e rrugëtimit sipas politikës gjithashtu mund ta ridrejtojnë trafikun plotësisht në një tabelë tjetër.

Koha i ndan ata më shpejt sesa arkeologjia e konfigurimit. Një hyrje që shfaqet në momentin kur ndërfaqja ngrihet i përket klientit; një që arrin një sekondë më vonë zakonisht erdhi nga një push i serverit; një që ekziston në nisje i përket konfigurimit të ruajtur. Regjistroni tabelën para dhe pas një lidhjeje, një shkëputjeje dhe një rinisjeje, dhe modeli do të emërojë pronarin. Një rrugë që kthehet vetëm kur shërbimi riniset tregon një njësi, jo VPN-në.

Lexoni tabelën para se ta redaktoni

Shikoni pamjen e vetë kernelit, jo një skedar të ruajtur. Kolona e protokollit tregon se çfarë instaloi çdo hyrje:

ip route show
ip route show table all
ip rule show

Fusha e protokollit, metrika dhe numri i tabelës ju tregojnë nëse po shikoni një hyrje statike, një të krijuar nga kernel ose diçka të shtuar nga një demon. Lista e rregullave ka rëndësi sepse një kërkim mund të largohet plotësisht nga tabela kryesore, gjë që e bën një redaktim atje të padukshëm për aplikacionin që po korrigjoni. Lexoni rreshtin nga e majta në të djathtë: destinacioni, porta, pajisja, protokolli dhe metrika.

Pastaj pyesni kernelin se cilën rrugë do të përdorte në të vërtetë. Një adresë e mbrojtur është një sondë më e mirë sesa një publike:

ip route get 10.20.5.7

Ndryshoni pronarin, jo simptomën

Pasi pronari të njihet, ndryshimi i përket atij pronari. Hiqni rrugën nga profili i klientit, korrigjoni rrugën e pushuar në server ose redaktoni lidhjen e menaxherit të rrjetit në vend që të shtoni një rrugë të përhershme konkurruese që fiton sipas metrikës. Dy rregulla që luftojnë njëri me tjetrin prodhojnë një tabelë që askush nuk mund ta shpjegojë më vonë.

Mbajeni përjashtimin e pikës fundore. Një rrugë pritësi që dërgon adresën publike të vetë serverit VPN përmes portës fizike është ajo që i mban paketat e jashtme të tunelit në rrjedhë; fshijeni atë dhe tuneli përpiqet të mbajë veten. Në një profil split-tunnel, e njëjta kujdes vlen për nënrrjetet lokale që duhet t'i shmangen tunelit.

Rilidhuni dhe verifikoni të dyja rrugët

Rilidhuni, pastaj kontrolloni të dyja destinacionet në një kalim. Adresa e mbrojtur dhe pika fundore e përjashtuar përgjigjen pyetjeve të ndryshme:

ip route get 10.20.5.7
ip route get 198.51.100.20

E para duhet të zgjidhet përmes ndërfaqes së tunelit dhe e dyta përmes portës fizike. Nëse të dyja zgjidhen përmes tunelit, mungon përjashtimi; nëse asnjëra, ndryshimi i profilit nuk ka hyrë në fuqi dhe po shikoni një pronar tjetër nga ai që menduat.

Shkruani qëllimin e rrugës, pronarin e saj dhe sa kohë duhet të jetojë. Ai shënim është ai që e ndalon personin tjetër të përsëritë të njëjtin cikël fshirjeje dhe rilidhjeje.