Makina përgjigjej një minutë më parë, VPN-ja u lidh dhe tani e njëjta adresë skadon. Tre defekte e prodhojnë atë simptomë, dhe ato jetojnë në makina të ndryshme. Pritësi mund të humbasë rrugën drejt rrjetit privat, diapazoni NAT i mysafirit mund të përplaset me një diapazon që tuneli tani shpall, ose një tunel i plotë mund të marrë pronësinë e çdo rruge në pritës. Zbuloni cila ndodhi para se të ndryshoni çdo konfigurim, sepse çdo rregullim jeton diku tjetër.

Shikoni rrugën, jo makinën

Shikoni vendimin e rrugëtimit të pritësit për adresën e mysafirit ndërsa tuneli është aktiv. Një rrugë që tregon ende për përshtatësin vetëm-pritës nuk është problemi. Një rrugë që tani tregon për përshtatësin VPN është problemi, dhe klienti e ndryshoi atë, jo ju. Fakti që përshtatësi mban adresën e tij thotë se ndërfaqja mbijetoi, që është fakt tjetër nga mbijetesa e rrugës.

Një sesion SSH që bie pikërisht në çastin e lidhjes është sjellje e pritur. Klienti riciklon përshtatës dhe instalon rrugë, prandaj lidhja vdes për disa sekonda. Defekti është lidhja që nuk kthehet kurrë, jo ajo që vetëm nxori dritë.

Regjistroni tabelën para tunelit dhe përsëri pas tij, pastaj krahasoni ato dy dalje. Diferenca është diagnoza, dhe gjithashtu është prova që pronari i rrjetit do të kërkojë.

ip -4 route get 192.168.56.10
ip -brief addr show
ip route show table main | head -20

Lexoni tabelën e pritësit para dhe pas

Në Linux preferenca mes rrugëve që mbivendosen vjen nga gjatësia e prefiksit dhe metrika, prandaj një rrugë VPN më specifike fiton edhe kur është e gabuar. Në Windows metrika e ndërfaqes vendos barazimin, dhe përshtatësi i tunelit zakonisht vjen me metrikë më të ulët se ai virtual. Në të dyja rastet simptoma e dukshme është e njëjtë: paketat dalin përmes përshtatësit të tunelit dhe zhduken.

Printo përshtatësit dhe metrikat e tyre pranë rrugës për prefiksin e mysafirit. Ai çift daljesh i përgjigjet pyetjes së pronësisë me një shikim.

Get-NetAdapter | Select-Object Name, InterfaceIndex, InterfaceMetric
Get-NetRoute -DestinationPrefix 192.168.56.0/24
route print -4 | Select-String '192.168.56'

Nëse rruga ndryshoi por metrika e përshtatësit jo, klienti instaloi një rrugë konkurruese. Nëse metrika ndryshoi, klienti rirenditi përshtatësit. Të dyja janë të rregullueshme, dhe rregullohen në vende të ndryshme.

Kur diapazoni NAT i mysafirit është përplasja

VirtualBox NAT përdor si parazgjedhje 10.0.2.0/24, dhe një tunel që shtyn të njëjtin diapazon e detyron mysafirin ta dërgojë atë trafik te porta e vet NAT në vend të destinacionit të vërtetë. Paketa nuk largohet kurrë nga pritësi, prandaj asnjë regjistër muri zjarri në anën tjetër nuk do ta tregojë. Docker Machine ka të njëjtën klasë konflikti në planin e tij vetëm-pritës, dhe ndryshimi i atij plani mund të kërkojë rikrijimin e makinës bashkë me certifikatat e saj.

Zgjidhni zëvendësimin duke listuar atë që tuneli shpall tashmë, pastaj atë që përdor rrjeti i zyrës, pastaj atë që ka kërkuar çdo përshtatës virtual në këtë pritës. Mbivendosja është ajo që thyen rrugëtimin, dhe ngjashmëria është e parëndësishme. Një diapazon mund të qëndrojë plotësisht brenda një tjetri ndërsa në shikim të parë nuk duket aspak i ngjashëm.

Vendosni diapazonin e ri kur krijohet makina, ose ndryshojeni dhe ringarkoni, pastaj provoni përsëri lidhjen që dështon nga mysafiri. Tabela e vetë mysafirit është pamja që ka rëndësi.

VBoxManage modifyvm devbox --natnet1 10.77.0.0/24
vagrant reload devbox --provision
vagrant ssh devbox -c 'ip route get 10.20.0.15'

Riktheni rrugën pa u përleshur me klientin

Çdo platformë ofron një mënyrë për të rikthyer prefiksin vetëm-pritës përpara. Në macOS një rrugë statike drejt ndërfaqes vetëm-pritës funksionon deri në lidhjen tjetër. Në Windows një metrikë më e ulët ndërfaqeje në përshtatësin virtual e mban të preferuar. Në Linux një operacion zëvendësimi mbulon një prefiks të vetëm. Të treja janë zgjidhje anësore, sepse një klient që ripozon rrugët e tij do t'i anulojë ato.

Skriptoni kontrollin në vend të një rilidhjeje të verbër në nisje. Një skript i vogël që printon rrugën për prefiksin e mysafirit pas çdo lidhjeje e kthen një mister në një rresht regjistri.

Nëse profili është tunel i plotë, kërkoni nga pronari i rrjetit tunel të ndarë ose një përjashtim të dokumentuar. Shtimi në heshtje i rrugëve që anashkalojnë një politikë sigurie nuk është rregullim, është problem i dytë që vjen më vonë me një auditor pas.

Kontrolloni rregullimin në të dyja anët

Verifikoni tre rrugë pas ndryshimit: pritësi te mysafiri, mysafiri te pritësi korporativ dhe mysafiri te interneti. Një rregullim që rikthen njërën dhe thyen tjetrën është ndryshim konfigurimi i maskuar si riparim. Regjistroni të njëjtat dalje që keni mbledhur para ndryshimit, që krahasimi të jetë i barabartë me të barabartë.

Shënoni ndërfaqen, metrikën dhe rrugën që ndryshuan, bashkë me kohën, që ndodhja tjetër të jetë kërkim dhe jo rindërtim. Ai shënim vlen më shumë se një fill i gjatë biletash.

ip -4 route get 192.168.56.10
traceroute -n -m 4 10.20.0.15
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

Kur pritësi arrin përsëri mysafirin dhe mysafiri arrin LAN-in, keni rikthyer rrugën me të cilën filluat. Kur funksionon vetëm njëra prej tyre, defekti i mbetur është në territorin e pronarit tjetër, dhe diferenca ju tregon cili territor është.

Artikuj të ngjashëm