Kial dua VPN-tunelo rompas la unuan?

Instali duan VPN-klienton por atingi unu klientan reton estas la kutima maniero kiel tio komenciĝas, kaj la unua tunelo mallumiĝas dum ambaŭ klientoj raportas sukceson. Ĉiu kliento instalis defaŭltan itineron, la dua estis pli specifa, kaj la kerno nun sekvas ĝin por ĉio krom la propra ekstera konekto de la unua tunelo. Nenio kraŝis kaj neniu profilo malĝustas. Unu itinero anstataŭigis alian, kaj la solvo estas decidi, kiu tunelo posedu la defaŭltan.

La simptomo: la dua kliento gajnas kviete

OpenVPN: la opcio redirect-gateway def1 ne anstataŭigas 0.0.0.0/0. Ĝi aldonas 0.0.0.0/1 kaj 128.0.0.0/1: kune ili kovras ĉiun IPv4-adreson, kaj ĉiu prefikso venkas ordinaran defaŭltan itineron laŭ longo. La origina defaŭlta itinero restas en la tabelo kaj ĉesas esti uzata por ordinara trafiko, kaj gast-itinero al la VPN-servilo malhelpas la tunelon kapti siajn proprajn eksterajn pakaĵojn. Ambaŭ klientoj faras tion, kaj la dua simple instalas sian paron poste.

Tial la unua tunelo aspektas morta anstataŭ malkonektita. Ĝia interfaco estas supre, ĝia kontrola kanalo vivas, kaj neniu aplikaĵa trafiko plu atingas ĝin. La kontraŭa plendo devenas de la sama mankanta push: telefono, kiu konektiĝas sed sendas nenion, kutime parolas kun servilo, kiu neniam anoncis redirect-gateway, do la aparato konservas sian propran defaŭlton kaj atingas nur la naĝejon.

Faru itineran foton antaŭ kaj post la konekto de la dua kliento. La du duonaj itineroj, kiuj aperas en la tabelo, estas la tuta ŝanĝo, kaj ili klarigas ambaŭ plendojn. Nenio alia en la tabelo devas moviĝi por ke la simptomo aperu. Tial forigi la duan klienton tuj restarigas la unuan.

Legu, kiu tunelo fakte gajnas

Ne deduktu la venkanton el la ordo, en kiu la klientoj komenciĝis, nek el la ikono en la sistemopleto. Demandu la kernon, kiun itineron ĝi uzus por celloko ekster ambaŭ privataj retoj, kaj legu la interfacon, kiu revenas.

ip route show
ip route get 198.51.100.24
route print -4
Find-NetRoute -RemoteIPAddress 198.51.100.24

La unuaj du estas la Linux-respondo kaj la lastaj du la Windows-ekvivalento. Rulu ilin dum ambaŭ tuneloj estas supre, poste malkonektu unu kaj rulu ilin denove. La diferenco inter la du eliroj estas la fakto, kiun vi bezonas antaŭ ol elekti solvon, kaj ĝi daŭras malpli longe ol legi la protokolon de iu ajn kliento.

Notu la rezulton, inkluzive la interfacan nomon kaj la prefikson, kiu kongruis. Bileto, kiu diras, ke la dua VPN rompis la unuan, estas priskribo de la simptomo, ne itinerada aserto, pri kiu iu povus agi. La serĉo igas ĝin fakto, kiun la sekva inĝeniero povas reprodukti per unu komando.

Windows: malhelpu, ke unu profilo posedu la defaŭlton

Windows konservas konservitajn profilojn, kaj la enkonstruita kliento permesas, ke unu dependu de alia, por ke la unua supreniĝu aŭtomate kiam la dua telefonvokas. La profilo, kiu konektiĝis plej lastatempe, emas teni la defaŭlton, do la praktika posedanto estas la lasta voko anstataŭ la unua. Donu al ĉiu profilo siajn proprajn puŝitajn itinerojn kaj ŝaltu split tunneling por tiu, kiu ne devas posedi la defaŭlton.

Set-VpnConnection -Name "Contoso" -SplitTunneling $true
rasdial Contoso

Split tunneling ŝanĝas tion: nur prefiksoj puŝitaj de la servilo eniras la tabelon, kio lasas la defaŭlton ĉe la unua tunelo. La dezajno ankoraŭ malsukcesas, se ambaŭ serviloj puŝas defaŭltan itineron, ĉar tiam venkas la lasta konekto kaj neniu agordo ĉe la klienta flanko ŝanĝas tion. Riparu la puŝon ĉe la servila flanko aŭ akceptu unu posedanton.

Aplikaĵ-pelitaj profiloj estas alia trajto kaj indas koni ĝin: Windows-profilo povas starti, kiam startas nomita plenumeblo, kun trafikaj filtriloj, kiuj decidas, kion ĝi portas. Tio estas profila agordo, ne fajroŝirma regulo, kaj ĝi solvas alian problemon ol la konflikto de la defaŭlta itinero.

Linux: tenu la duan tunelon ekster la ĉefa tabelo

Ruli du openvpn --config-ekzemplerojn sur unu maŝino metas ambaŭ klientojn en la saman tabelon, kaj tri opcioj apartigas ilin per kreskanta izoliteco. La plej malpeza estas tute malhelpi la duan klienton redakti la tabelon, per route-nopull kun eksplicitaj itineroj, aŭ route-up-skripto, kiu instalas nur tion, kion vi intencas. Tiam la dua tunelo portas precize la prefiksojn, kiujn vi nomas, kaj nenion alian. Tiam vi decidas, kiuj prefiksoj iras kien, anstataŭ malkovri tion poste.

Politika itinerado estas la meza opcio. Regulo elektas apartan tabelon por unu fonta adreso aŭ fajroŝirma marko, kaj tiu tabelo portas la itinerojn de la dua tunelo. Inverse-voja filtrado estas la kaptilo ĉi tie, ĉar respondo, kiu alvenas sur malsama interfaco ol tiu, kiun la tabelo elektus, estas forĵetata, do kontrolu la agordon rp_filter antaŭ ol konkludi, ke la tunelo rompiĝis.

ip rule add from 10.44.7.0/24 table 100
ip route add default dev tun1 table 100
sysctl net.ipv4.conf.all.rp_filter

Retaj nomspacoj estas la plej peza kaj plej pura opcio. Startigu la duan klienton ene de ip netns, donu al ĝi veth-paron, kaj eniru tiun nomspacon por uzi ĝin. Interfero malaperas ĉar ĉiu nomspaco posedas siajn proprajn tabelojn anstataŭ dividi unu, kio valoras la plian agordon, kiam ambaŭ tuneloj devas resti supre semajnojn.

Laŭ aplikaĵo, kaj ĉenado kiel aparta problemo

Foje nur unu programo devus uzi la duan tunelon. En Linux, politika itinerado laŭ uzanto, cgroup aŭ pordo atingas tiun rezulton, kaj unu celloko povas esti fiksita al interfaco sen tuŝi la defaŭlton. Aplikaĵo, kiu fiksas sian ingon al unu interfaco, tute ne konsultas la itineran tabelon, do lanĉilo povas daŭre uzi la fizikan adaptilon ĝis adreso elektiĝos en ĝiaj propraj agordoj.

Ĉenado estas alia operacio ol ruli du tunelojn unu apud la alia. Ĉeni A super B signifas, ke la adreso de la interna servilo devas esti atingebla de ene de la ekstera tunelo. La ekstera kliento ankaŭ ne devas konfuzi la ĉifritajn pakaĵojn de la interna kliento kun liko. Unu kliento ene de virtuala maŝino estas la kruda sed fidinda versio; ambaŭ sur unu gastiganto postulas la itineran laboron supre plus eksteran vojon al la interna servilo, kiu neniam eniras la internan tunelon.

Notu la posedanton de la defaŭlto, la prefiksan liston, kiun portas ĉiu tunelo, kaj la DNS-vojon. Tiuj tri faktoj igas la sekvan okazon serĉo anstataŭ enketo.