Zakaj drugi tunel VPN zlomi prvega?

Namestitev drugega odjemalca VPN za doseganje enega omrežja stranke je običajen način, kako se to začne, in prvi tunel ugasne, medtem ko oba odjemalca poročata o uspehu. Vsak odjemalec je namestil privzeto pot, druga je bila bolj natančna, in jedro ji zdaj sledi za vse razen za lastno zunanjo povezavo prvega tunela. Nič se ni zrušilo in noben profil ni napačen. Ena pot je zamenjala drugo, rešitev pa je odločiti, kateri tunel naj ima privzeto pot.

Simptom: drugi odjemalec tiho zmaga

OpenVPN: možnost redirect-gateway def1 ne prepiše 0.0.0.0/0. Doda 0.0.0.0/1 in 128.0.0.0/1: skupaj pokrivata vsak naslov IPv4 in vsaka predpona premaga običajno privzeto pot po dolžini. Prvotna privzeta pot ostane v tabeli in se ne uporablja več za običajen promet, pot do gostitelja strežnika VPN pa tunelu prepreči, da bi ujel lastne zunanje pakete. Oba odjemalca to počneta, drugi pa preprosto namesti svoj par pozneje.

Zato je prvi tunel videti mrtev, ne prekinjen. Njegov vmesnik je gor, krmilni kanal je živ, in noben promet aplikacij ne pride več do njega. Nasprotna pritožba ima isti manjkajoči push: telefon, ki se poveže, a nič ne pošlje, se običajno pogovarja s strežnikom, ki nikoli ni objavil redirect-gateway, zato naprava obdrži svojo privzeto pot in doseže le bazen.

Naredite posnetek poti pred povezavo drugega odjemalca in po njej. Dve polovični poti, ki se pojavita v tabeli, sta vsa sprememba in pojasnjujeta obe pritožbi. Nič drugega v tabeli se ne mora premakniti, da se simptom pojavi. Zato odstranitev drugega odjemalca takoj obnovi prvega.

Preberite, kateri tunel resnično zmaga

Ne sklepajte zmagovalca iz vrstnega reda zagona odjemalcev ali iz ikone v pladnju. Vprašajte jedro, katero pot bi uporabilo za cilj zunaj obeh zasebnih omrežij, in preberite vrnjeni vmesnik.

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

Prva dva sta odgovor Linuxa, zadnja dva pa ustreznica Windows. Zaženite ju, ko sta oba tunela gor, nato enega prekinite in ju zaženite znova. Razlika med dvema izhodoma je dejstvo, ki ga potrebujete pred izbiro rešitve, in traja manj časa kot branje dnevnika katerega koli odjemalca.

Zabeležite rezultat, vključno z imenom vmesnika in predpono, ki se je ujemala. Zahtevek, ki pravi, da je drugi VPN pokvaril prvega, je opis simptoma, ne trditev o usmerjanju, na katero bi se kdo lahko oprl. Iskanje ga spremeni v dejstvo, ki ga naslednji inženir ponovi z enim ukazom.

Windows: preprečite, da bi en profil imel privzeto pot

Windows shranjuje profile, vgrajeni odjemalec pa dovoljuje, da je eden odvisen od drugega, tako da se prvi dvigne samodejno, ko se drugi poveže. Profil, ki se je povezal nazadnje, navadno obdrži privzeto pot, zato je praktični lastnik zadnja povezava in ne prva. Vsakemu profilu dajte lastne push poti in vklopite split tunneling za tistega, ki ne bi smel imeti privzete poti.

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

Split tunneling to spremeni: v tabelo pridejo le predpone, ki jih potisne strežnik, kar pusti privzeto pot pri prvem tunelu. Zasnova še vedno odpove, če oba strežnika potisneta privzeto pot, ker takrat zmaga zadnja povezava in nobena nastavitev na strani odjemalca tega ne spremeni. Popravite push na strani strežnika ali sprejmite enega lastnika.

Profili, ki jih sproži aplikacija, so druga funkcija in vredna poznavanja: profil Windows se lahko zažene, ko se zažene imenovana izvršljiva datoteka, prometni filtri pa odločajo, kaj nosi. To je nastavitev profila in ne pravilo požarnega zidu, in rešuje drugačen problem od konflikta privzete poti.

Linux: držite drugi tunel zunaj glavne tabele

Izvajanje dveh primerkov openvpn --config na enem stroju postavi oba odjemalca v isto tabelo, tri možnosti pa ju ločijo z naraščajočo izolacijo. Najlažje je drugemu odjemalcu povsem prepovedati urejanje tabele: route-nopull z izrecnimi potmi ali skript route-up, ki namesti le tisto, kar nameravate. Potem drugi tunel nosi natanko predpone, ki jih navedete, in nič drugega. Potem se sami odločite, katere predpone kam gredo, namesto da bi to odkrili pozneje.

Usmerjanje po pravilniku je srednja možnost. Pravilo izbere ločeno tabelo za en naslov vira ali oznako požarnega zidu, in ta tabela nosi poti drugega tunela. Filtriranje vzvratne poti je tu past, ker se odgovor, ki prispe na drug vmesnik, kot bi ga izbrala tabela, zavrže, zato preverite nastavitev rp_filter, preden sklenete, da je tunel pokvarjen.

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

Imenski prostori omrežja so najtežja in najčistejša možnost. Zaženite drugega odjemalca znotraj ip netns, dajte mu par veth in vstopite v ta imenski prostor, da ga uporabite. Motnje izginejo, ker ima vsak imenski prostor svoje tabele namesto ene skupne, kar je vredno dodatne nastavitve, ko morata oba tunela ostati gor tedne.

Na aplikacijo in veriženje kot ločen problem

Včasih naj bi drugi tunel uporabljala le ena programska oprema. Na Linuxu to doseže usmerjanje po pravilniku glede na uporabnika, cgroup ali vrata, in eno ciljno mesto je mogoče pripeti na vmesnik, ne da bi se privzete poti sploh dotaknili. Aplikacija, ki pripne svojo vtičnico na en vmesnik, tabele usmerjanja sploh ne posvetuje, zato lahko zaganjalnik še naprej uporablja fizični vmesnik, dokler v njegovih lastnih nastavitvah ni izbran naslov.

Veriženje je druga operacija kot izvajanje dveh tunelov drug ob drugem. Verižiti A prek B pomeni, da mora biti naslov notranjega strežnika dosegljiv znotraj zunanjega tunela. Zunanji odjemalec tudi ne sme imeti šifriranih paketov notranjega odjemalca za uhajanje. En odjemalec v navideznem stroju je groba, a zanesljiva različica; oba na enem gostitelju zahtevata opisano delo z usmerjanjem ter zunanjo pot do notranjega strežnika, ki nikoli ne vstopi v notranji tunel.

Zapišite lastnika privzete poti, seznam predpon, ki jih nosi vsak tunel, in pot DNS. Ta tri dejstva spremenijo naslednji dogodek v iskanje namesto preiskave.