Doi clienți VPN, un singur tabel de rutare: cine câștigă ruta implicită

Pare că doi clienți VPN se luptă pentru același socket, iar soluția evidentă trebuie să fie dezinstalarea unuia. În practică, rareori ating același socket. Fiecare conectare rescrie tabelul de rutare al sistemului de operare, iar un profil de tunel complet revendică ruta implicită. De obicei câștigă cel care s-a conectat ultimul, motiv pentru care simptomul pare să se mute între clienți.

Conflictul trăiește în tabelul de rutare

Un adaptor virtual plus o rută implicită este modul în care un tunel complet captează traficul. Când al doilea client își instalează propria rută implicită, intrarea mai veche este înlocuită sau retrogradată de metrică, iar fiecare destinație circulă acum prin tunelul mai nou. Primul client rămâne conectat și afișează în continuare o pictogramă verde, deci interfața este activă în timp ce calea a dispărut. Tocmai această separare între starea conexiunii și starea rutării face comportamentul confuz.

Clienții sunt editori ai unui tabel comun. Să știi care modificare a avut loc ultima explică aproape fiecare simptom.

Citește care tunel deține calea curentă

Verificați decizia reală în loc să vă încredeți în clientul care raportează că este conectat. Întrebați sistemul ce interfață ar duce o anumită destinație.

ip route get 10.20.0.5
route print -4

Prima comandă numește interfața și adresa sursă pentru o destinație, iar aceasta este exact întrebarea care vă interesează. Listarea rutelor arată în Windows intrările implicite concurente și metricele lor, așa că vedeți care câștigă acum. Rulați căutarea pentru un gazdă din fiecare rețea la distanță, pentru că o destinație poate fi corectă în timp ce cealaltă rețea este inaccesibilă. Dacă răspunsul numește tunelul greșit, reconectarea nu va ajuta; politica de rutare trebuie schimbată.

Opriți al doilea client să revendice totul

Un client ar trebui să dețină ruta implicită, iar celălalt să poarte doar propriile prefixe. OpenVPN clienții pot refuza ce le împinge serverul.

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

route-nopull ignoră fiecare rută împinsă, în timp ce pull-filter ignore "redirect-gateway" aruncă doar directiva rutei implicite și păstrează DNS-ul și celelalte opțiuni împinse. Alegeți între ele după cât din configurația serverului mai doriți, apoi adăugați prefixele concrete de care are nevoie a doua rețea. Țineți cont de DNS, pentru că un resolver împins de un tunel care nu duce interogările nu returnează nimic. Testați un gazdă cunoscut în fiecare rețea și confirmați adresa sursă pe care o vede partea la distanță.

Subrețelele suprapuse nu pot fi ocolite

Când ambele rețele publică același prefix, nucleul păstrează o singură intrare pentru două locuri diferite și trebuie să aleagă. O rută de gazdă nu poate inventa distincția lipsă, iar o ajustare de metrică nici atât. Renumerați o parte, sau lăsați administratorul ei să traducă intervalul la distanță astfel încât prefixele să difere. Verificați subrețelele reale înainte de a da vina pe clienți, pentru că valoarea implicită 192.168.1.0/24 a unui router de acasă se ciocnește de un interval de birou mai des decât se așteaptă cineva. Notați ambele intervale în tichet, ca următoarea schimbare să nu recreeze suprapunerea.

Separați și două obiective: a ajunge la ambele rețele este o problemă de rutare, în timp ce înlănțuirea tunelurilor pentru confidențialitate este alt design, cu un operator suplimentar pe cale. Nu folosiți unul pentru a-l rezolva pe celălalt.