Du VPN-klientoj, unu enkursiga tabelo: kiu gajnas la defaŭltan itineron

Ŝajnas, ke du VPN-klientoj luktas pri la sama ingo, kaj la evidenta riparo devas esti malinstali unu. Praktike ili malofte tuŝas la saman ingon. Ĉiu konekto reskribas la enkursigan tabelon de la operaciumo, kaj plentunela profilo postulas la defaŭltan itineron. Kutime gajnas la lasta konektinto, kaj tial la simptomo ŝajnas migri inter la klientoj.

La konflikto loĝas en la enkursiga tabelo

Virtuala adaptilo plus defaŭlta itinero estas kiel plena tunelo kaptas trafikon. Kiam la dua kliento instalas sian propran defaŭlton, la pli malnova rikordo anstataŭiĝas aŭ malaltiĝas laŭ metriko, kaj ĉiu celo nun vojaĝas tra la pli nova tunelo. La unua kliento restas konektita kaj ankoraŭ montras verdan ikonon, do la interfaco estas aktiva dum la vojo malaperis. Ĝuste tiu apartigo inter konekta stato kaj enkursiga stato igas la konduton konfuza.

La klientoj estas redaktantoj de unu komuna tabelo. Scii, kiu ŝanĝo okazis laste, klarigas preskaŭ ĉiun simptomon.

Legu, kiu tunelo posedas la nunan vojon

Kontrolu la efektivan decidon anstataŭ fidi la klienton, kiu raportas sin konektita. Demandu al la sistemo, kiu interfaco portus specifan celon.

ip route get 10.20.0.5
route print -4

La unua komando nomas la interfacon kaj la fontan adreson por unu celo, kaj tio estas ĝuste la demando, kiu gravas al vi. La itinera eligo montras la konkurantajn defaŭltajn rikordojn kaj iliajn metrikojn en Windows, do vi vidas, kiu nun gajnas. Rulu la serĉon por gastiganto en ĉiu fora reto, ĉar unu celo povas esti ĝusta dum la alia reto estas neatingebla. Se la respondo nomas la malĝustan tunelon, rekonekto ne helpos; la itinera politiko devas ŝanĝiĝi.

Haltigu la duan klienton postuli ĉion

Unu kliento devus posedi la defaŭltan itineron, kaj la alia portu nur siajn proprajn prefiksojn. OpenVPN klientoj povas rifuzi tion, kion la servilo puŝas.

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

route-nopull ignoras ĉiun puŝitan itineron, dum pull-filter ignore "redirect-gateway" forĵetas nur la direktivon de la defaŭlta itinero kaj konservas la puŝitan DNS kaj aliajn opciojn. Elektu inter ili laŭ tio, kiom da servila agordo vi ankoraŭ volas, poste aldonu la specifajn prefiksojn, kiujn la dua reto bezonas. Memoru pri DNS, ĉar solvilo puŝita de tunelo, kiu ne portas la serĉojn, resendas nenion. Testu unu konatan gastiganton en ĉiu reto kaj konfirmu la fontan adreson, kiun vidas la fora flanko.

Interkovrantaj subretoj ne estas preterireblaj

Kiam ambaŭ retoj publikigas la saman prefikson, la kerno tenas unu rikordon por du malsamaj lokoj kaj devas elekti. Gasta itinero ne povas elpensi la mankantan distingon, nek metrika ĝustigo povas. Renumeru unu flankon, aŭ lasu ĝian administranton traduki la foran aron tiel, ke la prefiksoj malsimilu. Kontrolu la verajn subretojn antaŭ ol kulpigi la klientojn, ĉar hejma enkursigilo kun defaŭlto 192.168.1.0/24 kolizias kun oficeja aro pli ofte, ol iu atendas. Notu ambaŭ arojn en la bileto, por ke la sekva ŝanĝo ne rekrei la interkovron.

Apartigu ankaŭ du celojn: atingi ambaŭ retojn estas enkursiga problemo, dum ĉenigi tunelojn por privateco estas alia dezajno kun plia operatoro sur la vojo. Ne uzu unu por solvi la alian.