Tveir VPN-viðskiptavinir, ein leiðatafla: hver fær sjálfgefnu leiðina

Það lítur út fyrir að tveir VPN-viðskiptavinir berjist um sama sokkinn, og augljós lækning hlýtur að vera að fjarlægja annan. Í reynd snerta þeir sjaldan sama sokkinn. Hver tenging endurskrifar leiðatöflu stýrikerfisins, og fulltunnils-snið gerir tilkall til sjálfgefnu leiðarinnar. Sá sem tengdist síðastur vinnur yfirleitt, og þess vegna virðist einkennið flytjast milli viðskiptavina.

Áreksturinn býr í leiðatöflunni

Sýndaradapter ásamt sjálfgefinni leið er hvernig fulltunnill grípur umferð. Þegar annar viðskiptavinurinn setur upp sína eigin sjálfgefnu leið er eldri færslunni skipt út eða henni lækkað með mælikvarða, og hver áfangastaður fer nú um nýrri tunnilinn. Fyrsti viðskiptavinurinn helst tengdur og sýnir enn grænt tákn, svo viðmótið er virkt á meðan leiðin er horfin. Einmitt þessi aðskilnaður tengistöðu og leiðastöðu gerir hegðunina ruglingslega.

Viðskiptavinirnir eru ritstjórar einnar sameiginlegrar töflu. Að vita hvaða breyting varð síðust skýrir nánast hvert einkenni.

Lestu hvaða tunnill á núverandi leið

Athugaðu raunverulegu ákvörðunina í stað þess að treysta viðskiptavininum sem segist tengdur. Spurðu kerfið hvaða viðmót myndi bera tiltekinn áfangastað.

ip route get 10.20.0.5
route print -4

Fyrsta skipunin nefnir viðmótið og upprunavistfangið fyrir einn áfangastað, og það er einmitt spurningin sem þig varðar. Leiðaskráin sýnir á Windows keppinautana sjálfgefnu færslurnar og mælikvarða þeirra, svo þú sérð hver vinnur núna. Keyrðu leitina fyrir hýsil í hverju fjarneti, því einn áfangastaður getur verið réttur á meðan hitt netið er óaðgengilegt. Ef svarið nefnir rangan tunnil hjálpar ekkert að tengjast aftur; leiðastefnan verður að breytast.

Stöðvaðu annan viðskiptavininn frá að gera tilkall til alls

Einn viðskiptavinur ætti að eiga sjálfgefnu leiðina, og hinn ætti aðeins að bera eigin forskeyti. OpenVPN viðskiptavinir geta hafnað því sem þjónninn ýtir að.

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

route-nopull hunsar hverja ýtta leið, á meðan pull-filter ignore "redirect-gateway" sleppir aðeins tilskipuninni um sjálfgefnu leiðina og heldur ýttu DNS og öðrum valkostum. Veldu á milli þeirra eftir því hversu mikið af uppsetningu þjónsins þú vilt enn, og bættu síðan við tilteknu forskeytunum sem hitt netið þarf. Hafðu DNS í huga, því leysir sem tunnill sem ber ekki fyrirspurnirnar ýtir að skilar engu. Prófaðu einn þekktan hýsil í hverju neti og staðfestu upprunavistfangið sem fjaraðilinn sér.

Ekki er hægt að komast hjá skarastæknum undirnetum

Þegar bæði netin birta sama forskeytið heldur kjarninn einni færslu fyrir tvo ólíka staði og verður að velja. Hýsilleið getur ekki fundið upp vantar greinina, og mælikvarðaleiðrétting ekki heldur. Endurnúmeraðu aðra hliðina, eða láttu stjórnandann þýða fjarsviðið svo forskeytin séu ólík. Athugaðu raunverulegu undirnetin áður en þú kennir viðskiptavinunum um, því sjálfgefið 192.168.1.0/24 heimilisdreifingar rekst oftar á skrifstofusvið en nokkur býst við. Skráðu bæði sviðin í miðann svo næsta breyting endurskapi ekki skörunina.

Aðskildu líka tvö markmið: að ná báðum netum er leiðavandamál, á meðan að keðja tunnla fyrir næði er önnur hönnun með aukaaðila á leiðinni. Notaðu ekki annað til að leysa hitt.