Du VPN klientai, viena maršrutų lentelė: kas gauna numatytąjį maršrutą

Atrodo, kad du VPN klientai kovoja dėl to paties lizdo, ir akivaizdus sprendimas turi būti pašalinti vieną. Praktiškai jie retai paliečia tą patį lizdą. Kiekvienas prisijungimas perrašo operacinės sistemos maršrutų lentelę, o viso tunelio profilis pasisavina numatytąjį maršrutą. Paprastai laimi tas, kuris prisijungė paskutinis, todėl atrodo, kad simptomas keliauja tarp klientų.

Konfliktas gyvena maršrutų lentelėje

Virtualus adapteris ir numatytasis maršrutas – taip visas tunelis užvaldo srautą. Kai antrasis klientas įdiegia savo numatytąjį maršrutą, senesnis įrašas pakeičiamas arba sumažinamas metrikos, ir kiekviena paskirties vieta dabar keliauja per naujesnį tunelį. Pirmasis klientas lieka prisijungęs ir vis dar rodo žalią piktogramą, taigi sąsaja veikia, o kelio nebėra. Būtent šis ryšio būsenos ir maršrutizavimo būsenos atskyrimas daro elgseną klaidinančią.

Klientai yra vienos bendros lentelės redaktoriai. Žinojimas, kuris pakeitimas buvo paskutinis, paaiškina beveik kiekvieną simptomą.

Perskaitykite, kuris tunelis valdo dabartinį kelią

Patikrinkite tikrąjį sprendimą, o ne pasitikėkite klientu, kuris praneša esąs prisijungęs. Paklauskite sistemos, kuri sąsaja perduotų konkrečią paskirties vietą.

ip route get 10.20.0.5
route print -4

Pirmoji komanda nurodo sąsają ir šaltinio adresą vienai paskirties vietai, ir tai yra tiksliai tas klausimas, kuris jums rūpi. Maršrutų išrašas rodo Windows konkuruojančius numatytuosius įrašus ir jų metrikas, todėl matote, kuris šiuo metu laimi. Paleiskite paiešką kiekvieno nuotolinio tinklo vienam mazgui, nes viena paskirties vieta gali būti teisinga, kol kitas tinklas nepasiekiamas. Jei atsakymas nurodo netinkamą tunelį, prisijungimas iš naujo nepadės; maršrutų politika turi pasikeisti.

Sustabdykite antrąjį klientą pasisavinti viską

Vienas klientas turėtų valdyti numatytąjį maršrutą, o kitas – nešti tik savo prefiksus. OpenVPN klientai gali atsisakyti to, ką serveris primeta.

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

route-nopull nepaiso kiekvieno primesto maršruto, o pull-filter ignore "redirect-gateway" atmeta tik numatytojo maršruto direktyvą ir išlaiko primestą DNS bei kitas parinktis. Rinkitės tarp jų pagal tai, kiek serverio konfigūracijos dar norite, tada pridėkite konkrečius prefiksus, kurių reikia antrajam tinklui. Atminkite DNS, nes sprendiklis, kurį primeta tunelis, nenešantis užklausų, nieko negrąžina. Išbandykite vieną žinomą mazgą kiekviename tinkle ir patvirtinkite šaltinio adresą, kurį mato nuotolinė pusė.

Persidengiančių potinklių apeiti nepavyks

Kai abu tinklai skelbia tą patį prefiksą, branduolys laiko vieną įrašą dviem skirtingoms vietoms ir turi rinktis. Mazgo maršrutas negali išrasti trūkstamo skirtumo, o metrikos pataisa – taip pat. Pernumeruokite vieną pusę arba leiskite jos administratoriui išversti nuotolinį diapazoną, kad prefiksai skirtųsi. Patikrinkite tikruosius potinklius, prieš kaltindami klientus, nes namų maršrutizatoriaus numatytasis 192.168.1.0/24 dažniau susiduria su biuro diapazonu, nei kas nors tikisi. Užrašykite abu diapazonus biliete, kad kitas pakeitimas nesukurtų persidengimo iš naujo.

Atskirkite ir du tikslus: pasiekti abu tinklus yra maršrutizavimo problema, o tunelių grandinė dėl privatumo yra kitoks sprendimas su papildomu operatoriumi kelyje. Nenaudokite vieno kitam išspręsti.