Divi VPN klienti, viena maršrutēšanas tabula: kurš iegūst noklusējuma maršrutu

Divi VPN klienti reti saduras tieši; tie pārraksta to pašu noklusējuma maršrutu. Pārbaudiet izvēlēto ceļu, tad neļaujiet vienam klientam pretendēt uz visiem galamērķiem.

Izskatās, ka divi VPN klienti cīnās par vienu un to pašu ligzdu, un acīmredzamajam labojumam jābūt viena atinstalēšanai. Praksē tie reti aizskar vienu un to pašu ligzdu. Katrs savienojums pārraksta operētājsistēmas maršrutēšanas tabulu, un pilna tuneļa profils piesavinās noklusējuma maršrutu. Parasti uzvar tas, kurš pievienojās pēdējais, tāpēc šķiet, ka simptoms pārvietojas starp klientiem.

Konflikts dzīvo maršrutēšanas tabulā

Virtuālais adapteris kopā ar noklusējuma maršrutu ir veids, kā pilns tunelis pārtver datplūsmu. Kad otrais klients instalē savu noklusējuma maršrutu, vecākais ieraksts tiek aizstāts vai pazemināts pēc metrikas, un katrs galamērķis tagad iet caur jaunāko tuneli. Pirmais klients paliek savienots un joprojām rāda zaļu ikonu, tātad saskarne ir aktīva, kamēr ceļš ir pazudis. Tieši šī savienojuma stāvokļa un maršrutēšanas stāvokļa atdalīšana padara uzvedību mulsinošu.

Klienti ir vienas koplietotas tabulas redaktori. Zināšana, kura izmaiņa bija pēdējā, izskaidro gandrīz katru simptomu.

Izlasi, kurš tunelis pārvalda pašreizējo ceļu

Pārbaudiet faktisko lēmumu, nevis uzticieties klientam, kas ziņo par savienojumu. Pajautājiet sistēmai, kura saskarne pārvadātu konkrētu galamērķi.

ip route get 10.20.0.5
route print -4

Pirmā komanda nosauc saskarni un avota adresi vienam galamērķim, un tas ir tieši tas jautājums, kas jūs interesē. Maršrutu izdruka Windows rāda konkurējošos noklusējuma ierakstus un to metrikas, tāpēc redzat, kurš pašlaik uzvar. Palaidiet meklēšanu katram attālinātā tīkla resursdatoram, jo viens galamērķis var būt pareizs, kamēr otrs tīkls nav sasniedzams. Ja atbilde nosauc nepareizo tuneli, atkārtota savienošana nepalīdzēs; maršrutēšanas politika ir jāmaina.

Apturiet otro klientu piesavināties visu

Vienam klientam jāpārvalda noklusējuma maršruts, bet otram jānes tikai savus prefiksus. OpenVPN klienti var atteikties no tā, ko serveris uzspiež.

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

route-nopull ignorē katru uzspiesto maršrutu, bet pull-filter ignore "redirect-gateway" atmet tikai noklusējuma maršruta direktīvu un saglabā uzspiesto DNS un citas opcijas. Izvēlieties starp tiem pēc tā, cik daudz servera konfigurācijas vēl vēlaties, pēc tam pievienojiet konkrētos prefiksus, kas nepieciešami otrajam tīklam. Paturiet prātā DNS, jo atrisinātājs, ko uzspiež tunelis, kas nepārvadā vaicājumus, neko neatgriež. Pārbaudiet vienu zināmu resursdatoru katrā tīklā un apstipriniet avota adresi, ko redz attālinātā puse.

Pārklājošos apakštīklus nevar apiet

Kad abi tīkli publicē vienu un to pašu prefiksu, kodols tur vienu ierakstu divām dažādām vietām un ir spiests izvēlēties. Resursdatora maršruts nevar izdomāt trūkstošo atšķirību, un arī metrikas pielāgošana to nevar. Pārnumurējiet vienu pusi vai ļaujiet tās administratoram iztulkot attālināto diapazonu, lai prefiksi atšķirtos. Pārbaudiet īstos apakštīklus, pirms vainojat klientus, jo mājas maršrutētāja noklusējums 192.168.1.0/24 biežāk saduras ar biroja diapazonu, nekā kāds gaida. Ierakstiet abus diapazonus biļetē, lai nākamā izmaiņa neatjaunotu pārklāšanos.

Atdaliet arī divus mērķus: sasniegt abus tīklus ir maršrutēšanas problēma, bet tuneļu ķēde privātuma dēļ ir cits dizains ar papildu operatoru ceļā. Neizmantojiet vienu, lai atrisinātu otru.

Saistītie raksti