Dva odjemalca VPN, ena usmerjevalna tabela: kdo dobi privzeto pot

Videti je, kot da se dva odjemalca VPN borita za isto vtičnico, in očitna rešitev mora biti odstranitev enega. V praksi se redko dotakneta iste vtičnice. Vsaka povezava prepiše usmerjevalno tabelo operacijskega sistema, profil polnega tunela pa zahteva privzeto pot. Običajno zmaga tisti, ki se je povezal zadnji, zato se zdi, da se simptom seli med odjemalcema.

Spor živi v usmerjevalni tabeli

Navidezni vmesnik in privzeta pot – tako polni tunel zajame promet. Ko drugi odjemalec namesti svojo privzeto pot, se starejši vnos nadomesti ali zniža z metriko, in vsak cilj zdaj potuje skozi novejši tunel. Prvi odjemalec ostane povezan in še vedno prikazuje zeleno ikono, torej vmesnik deluje, medtem ko je pot izginila. Prav ta ločitev med stanjem povezave in stanjem usmerjanja naredi vedenje zmedeno.

Odjemalci so urejevalci ene skupne tabele. Vedeti, katera sprememba je bila zadnja, pojasni skoraj vsak simptom.

Preberite, kateri tunel ima trenutno pot

Preverite dejansko odločitev, namesto da bi zaupali odjemalcu, ki poroča o povezavi. Vprašajte sistem, kateri vmesnik bi nosil določen cilj.

ip route get 10.20.0.5
route print -4

Prvi ukaz poimenuje vmesnik in izvorni naslov za en cilj, in to je natanko vprašanje, ki vas zanima. Izpis poti v Windows prikaže konkurenčne privzete vnose in njihove metrike, tako da vidite, kateri zdaj zmaguje. Zaženite iskanje za gostitelja v vsakem oddaljenem omrežju, ker je en cilj lahko pravilen, medtem ko je drugo omrežje nedosegljivo. Če odgovor navaja napačen tunel, ponovna povezava ne bo pomagala; politika usmerjanja se mora spremeniti.

Ustavite drugega odjemalca pri zahtevanju vsega

En odjemalec naj ima privzeto pot, drugi pa naj nosi le svoje predpone. OpenVPN odjemalci lahko zavrnejo, kar strežnik potiska.

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

route-nopull prezre vsako potisnjeno pot, medtem ko pull-filter ignore "redirect-gateway" zavrže le direktivo privzete poti in obdrži potisnjeni DNS ter druge možnosti. Izberite med njima glede na to, koliko strežnikove konfiguracije še želite, nato dodajte konkretne predpone, ki jih potrebuje drugo omrežje. Upoštevajte DNS, saj resolver, ki ga potisne tunel, ki ne prenaša poizvedb, ne vrne ničesar. Preizkusite enega znanega gostitelja v vsakem omrežju in potrdite izvorni naslov, ki ga vidi oddaljena stran.

Prekrivajočim se podomrežjem se ni mogoče izogniti

Ko obe omrežji objavita isti predpono, jedro hrani en vnos za dve različni mesti in mora izbrati. Pot gostitelja si ne more izmisliti manjkajoče razlike, prilagoditev metrike pa tudi ne. Prenumerirajte eno stran ali pustite njenemu skrbniku, da prevede oddaljeno območje, da se predpone razlikujejo. Preverite prava podomrežja, preden obtožite odjemalce, saj privzeta vrednost 192.168.1.0/24 domačega usmerjevalnika trči v pisarniško območje pogosteje, kot kdo pričakuje. Zabeležite obe območji v zahtevku, da naslednja sprememba ne bo znova ustvarila prekrivanja.

Ločite tudi dva cilja: doseči obe omrežji je problem usmerjanja, medtem ko je veriženje tunelov zaradi zasebnosti drugačna zasnova z dodatnim operaterjem na poti. Ne uporabljajte enega za rešitev drugega.