Dy klientë VPN, një tabelë rrugëtimi: kush merr rrugën e parazgjedhur

Duket se dy klientë VPN po përleshen për të njëjtin socket, dhe zgjidhja e dukshme duhet të jetë çinstalimi i njërit. Në praktikë ata rrallë prekin të njëjtin socket. Çdo lidhje rishkruan tabelën e rrugëtimit të sistemit operativ, dhe një profil tuneli të plotë kërkon rrugën e parazgjedhur. Zakonisht fiton ai që u lidh i fundit, prandaj simptoma duket se lëviz midis klientëve.

Konflikti jeton në tabelën e rrugëtimit

Një përshtatës virtual plus një rrugë e parazgjedhur është mënyra se si një tunel i plotë kap trafikun. Kur klienti i dytë instalon rrugën e vet të parazgjedhur, hyrja më e vjetër zëvendësohet ose ulet nga metrika, dhe çdo destinacion tani kalon nëpër tunelin më të ri. Klienti i parë mbetet i lidhur dhe ende shfaq një ikonë të gjelbër, pra ndërfaqja është aktive ndërsa rruga ka humbur. Pikërisht kjo ndarje midis gjendjes së lidhjes dhe gjendjes së rrugëtimit e bën sjelljen konfuze.

Klientët janë redaktorë të një tabele të përbashkët. Të dish cili ndryshim ndodhi i fundit shpjegon pothuajse çdo simptomë.

Lexoni cili tunel zotëron rrugën aktuale

Kontrolloni vendimin e vërtetë në vend që t'i besoni klientit që raporton se është i lidhur. Pyetni sistemin cila ndërfaqe do të mbante një destinacion të caktuar.

ip route get 10.20.0.5
route print -4

Komanda e parë emërton ndërfaqen dhe adresën e burimit për një destinacion, dhe kjo është pikërisht pyetja që ju intereson. Shkarkimi i rrugëve tregon në Windows hyrjet e parazgjedhura konkurruese dhe metrikat e tyre, kështu që shihni cila fiton tani. Ekzekutoni kërkimin për një host në çdo rrjet të largët, sepse një destinacion mund të jetë i saktë ndërsa rrjeta tjetër është e paarritshme. Nëse përgjigjja emërton tunelin e gabuar, rilidhja nuk do të ndihmojë; politika e rrugëtimit duhet të ndryshojë.

Ndaloni klientin e dytë të kërkojë gjithçka

Një klient duhet të zotërojë rrugën e parazgjedhur, dhe tjetri duhet të mbajë vetëm parashtesat e veta. OpenVPN klientët mund të refuzojnë atë që shtyn serveri.

pull-filter ignore "redirect-gateway"
ip route get 10.30.4.10

route-nopull injoron çdo rrugë të shtyrë, ndërsa pull-filter ignore "redirect-gateway" hedh vetëm direktivën e rrugës së parazgjedhur dhe mban DNS-në dhe opsionet e tjera të shtyra. Zgjidhni midis tyre sipas asaj se sa e konfigurimit të serverit dëshironi ende, pastaj shtoni parashtesat specifike që i nevojiten rrjetit të dytë. Mbani parasysh DNS-në, sepse një zgjidhës i shtyrë nga një tunel që nuk i mbart kërkesat nuk kthen asgjë. Provoni një host të njohur në çdo rrjet dhe konfirmoni adresën e burimit që sheh ana e largët.

Nënrrjetet që mbivendosen nuk mund të anashkalohen

Kur të dy rrjetet publikojnë të njëjtin parashtesë, kerneli mban një hyrje për dy vende të ndryshme dhe duhet të zgjedhë. Një rrugë hosti nuk mund të sajojë dallimin që mungon, dhe as një rregullim metrike. Rinumeroni njërën anë, ose lëreni administratorin e saj të përkthejë diapazonin e largët që parashtesat të ndryshojnë. Kontrolloni nënrrjetet reale përpara se të fajësoni klientët, sepse vlera e parazgjedhur 192.168.1.0/24 e një routeri shtëpiak përplaset me një diapazon zyre më shpesh sesa pritet. Regjistroni të dy diapazonet në biletë që ndryshimi tjetër të mos rikrijojë mbivendosjen.

Ndani edhe dy qëllime: arritja e të dy rrjeteve është problem rrugëtimi, ndërsa zinxhirimi i tuneleve për privatësi është një dizajn tjetër me një operator shtesë në rrugë. Mos përdorni njërin për të zgjidhur tjetrin.