Polni tunel OpenVPN prekine vašo sejo SSH: popravite povratno pot

Vklop odjemalca OpenVPN s polnim tunelom na stroju, do katerega dostopate po SSH, lahko prekine sejo v sekundi, stroj pa ne dela nič narobe. Tunel ne spremeni, kako paketi dosežejo strežnik; spremeni, kako odhajajo odgovori. Takoj ko privzeta pot kaže na tun0, odgovor vašemu odjemalcu SSH odide v omrežje ponudnika, ki nima poti nazaj na vaš naslov. Povezava obvisi, naslednji poskus poteče in daemon ves čas posluša na vratih 22.

Preberite usmerjevalno tabelo, preden preberete dnevnik VPN. Dnevnik bo rekel, da se je tunel dvignil, in ima prav. Vprašanje je, kateremu vmesniku se preda vsak odgovor, in to je iskanje za vsak paket v tabeli, ki jo je tunel pravkar prepisal.

Zakaj odgovor izstopi skozi napačna vrata

Vhodni paketi še vedno prihajajo na fizični vmesnik, ker odjemalec VPN ne more spremeniti, kako internet doseže javni naslov vašega strežnika. Odgovori so ločena odločitev: za vsak paket jedro poišče cilj, po --redirect-gateway pa privzeti vnos pravi tunel. Izhod ponudnika vidi cilj, ki ga ne oskrbuje, in paket zavrže.

Lastna zaščita OpenVPN pokriva natanko en cilj. Priročnik za 2.6 opisuje --redirect-gateway kot zaporedje: doda pot gostitelja za peer VPN prek prehoda, ki je bil v uporabi pred tunelom, da se šifriran promet ne more zavrteti nazaj vase, nato pa zamenja privzeto pot. Ta pot gostitelja je samo za peer. Vaš odjemalec SSH je le še en internetni naslov in ne dobi nobene izjeme.

Eno napako s predpono se je vredno izogniti zgodaj. ip route add -net 0.0.0.0 gw 10.8.0.1 dev tun0 brez dolžine se ujema z enim naslovom 0.0.0.0, ne z internetom; mora biti 0.0.0.0/0. In če prevzem privzete poti pokvari lastni transport tunela, dodajte končno točko kot pot gostitelja skozi fizični vmesnik, z resničnim naslovom ponudnika.

Pripnite naslov svojega odjemalca SSH za takojšnjo popravko

Najhitrejša popravka je pot gostitelja za naslov vašega odjemalca skozi prehod, ki ga je strežnik uporabljal pred tunelom. Na svoji strani poiščite naslov, ki ga bo strežnik videl, in nato preberite tabelo strežnika, da boste poznali stari prehod:

curl -s https://ifconfig.co
ip route

Na strežniku dodajte izjemo, preden se odjemalec zažene. Naslovi tukaj so nadomestni znaki; pomembna je oblika:

sudo ip route add 80.128.240.55 via 192.168.178.1

To je popravka, uporabljena v prijavljenem primeru, in deluje takoj. Je tudi krhka na dva predvidljiva načina: pot izgine ob ponovnem zagonu in postane napačna v trenutku, ko vam ISP dodeli drug naslov. Obravnavajte jo kot nujni ukrep in jo namerno naredite trajno, prek omrežne enote ali kljuke razpošiljatelja, ali sprejmite, da je začasna, in zapišite pot obnovitve.

Preprečite odjemalcu prevzem privzete poti

Čistejša možnost je, da tunelu sploh ne dovolite zamenjati privzete poti. route-nopull, uporabljen z --client ali --pull, sprejme potisnjene možnosti razen poti, block-outside-dns in možnosti v slogu DHCP, kot so strežniki DNS, zato dodate le predpone, ki jih potrebujete. Ožje orodje je filter vlečenja, ki zavrže eno problematično direktivo in obdrži ostalo:

route-nopull
pull-filter ignore "redirect-gateway"

Uporabite eno ali drugo, ne obojega, in bodite jasni, kaj se spremeni. Brez privzete poti skozi tunel strežnik ne brska več po internetu prek ponudnika; doseže le tisto, kar ste izrecno usmerili. Če je bil polni tunel ves smisel nastavitve, je to napačna ročica in pot gostitelja zgoraj je prava.

Razdelite povratno pot po viru ali po povezavi

Ko je vhodni naslov stabilen, pravilo vira ohrani odgovore lokalne, ne da bi se dotaknilo lastnih poti tunela. Dajte naslovu fizičnega vmesnika svojo tabelo s predpono LAN in fizično privzeto potjo, nato pa izberite to tabelo za promet, ki prihaja od tam:

ip rule add from 192.168.1.11 table 128
ip route add table 128 to 192.168.1.0/24 dev eth0
ip route add table 128 default via 192.168.1.1

To deluje, ker odgovori na vhodno povezavo SSH izvirajo z naslova, na katerega se je odjemalec povezal. Prijavljen primer, kjer je morala vsaka vhodna storitev še naprej delovati, je uporabil natanko to obliko. Ko vhodni naslov plava ali je pot dinamična, namesto tega označite povezavo: postavite oznako conntrack na prvi paket s fizičnega vmesnika, jo kopirajte na pakete odgovora v OUTPUT in usmerite označene pakete skozi tabelo, ki kaže na fizični prehod.

iptables -t mangle -A PREROUTING -i eth0 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1234
iptables -t mangle -A OUTPUT -m connmark --mark 1234 -j MARK --set-mark 4321
ip route add default via 192.168.1.1 dev eth0 table 3412
ip rule add fwmark 4321 table 3412

Med testiranjem imejte oznako povezave, oznako požarnega zidu in številko tabele ločene. Ponovna uporaba ene številke za dve vlogi ustvari pravilo, ki je videti pravilno in zadene napačne pakete. Privzeti vnos tabele potrebuje tudi via s prehodom LAN na običajni povezavi Ethernet; goli dev eth0 deluje le, kadar je vmesnik točka-točka ali se naslednji skok razreši drugače. Prijavljeni gostitelj Jessie je sedel na povezavi, kjer je gola oblika delovala, kar ni distribucijsko pravilo za kopiranje.

Preverite, ne da bi se zaklenili zunaj

Ne preizkušajte z odklopom. Pustite prvo sejo odprto, dvignite tunel in vprašajte jedro, po kateri poti bi šel vaš lastni naslov:

ip route get 80.128.240.55

Odgovor bi moral navesti fizični vmesnik in stari prehod, ne tunela. Nato odprite drugo povezavo SSH; to je pravi preizkus, ker lahko stara seja preživi na stanju, ki ga nova povezava ne more ponoviti. Če druga obvisi, medtem ko prva še odgovarja, pravilo ni nikoli zadela prometa, ki šteje, in treba je pogledati oznake ali izvorni naslov.

Med celotno vajo imejte pri roki konzolo zunaj pasu. Strežnika, katerega edina pot dostopa je tunel, ki ste ga pravkar zlomili, ni mogoče popraviti po tem tunelu, in razveljavitev je lažja, ko ste zapisali številke tabel in predpone, ki ste jih dodali.