Plný tunel OpenVPN prerušuje vašu SSH reláciu: opravte cestu odpovede

Zapnutie klienta OpenVPN s plným tunelom na stroji, ku ktorému sa pripájate cez SSH, môže prerušiť reláciu za sekundu, a stroj pritom nerobí nič nesprávne. Tunel nemení, ako pakety dorazia na server; mení, ako odchádzajú odpovede. Hneď ako predvolená trasa ukazuje na tun0, odpoveď vášmu SSH klientovi ide do siete poskytovateľa, ktorá nemá trasu späť na vašu adresu. Spojenie zamrzne, ďalší pokus vyprší a démon celý čas počúva na porte 22.

Prečítajte si smerovaciu tabuľku skôr, než prečítate log VPN. Log povie, že tunel vstal, a bude mať pravdu. Otázka je, ktorému rozhraniu sa každá odpoveď odovzdá, a to je vyhľadanie pre každý paket v tabuľke, ktorú tunel práve prepísal.

Prečo odpoveď vychádza nesprávnymi dverami

Prichádzajúce pakety stále prichádzajú na fyzické rozhranie, pretože klient VPN nemôže zmeniť, ako sa internet dostane na verejnú adresu vášho servera. Odpovede sú samostatné rozhodnutie: pre každý paket jadro hľadá cieľ a po --redirect-gateway predvolený záznam hovorí tunel. Výstup poskytovateľa vidí cieľ, ktorému neposkytuje službu, a paket zahodí.

Vlastná ochrana OpenVPN pokrýva presne jeden cieľ. Manuál k 2.6 opisuje --redirect-gateway ako postupnosť: pridá hostiteľskú trasu pre peer VPN cez bránu používanú pred tunelom, aby sa šifrovaná premávka nemohla zacykliť sama do seba, a potom nahradí predvolenú trasu. Tá hostiteľská trasa je len pre peer. Váš SSH klient je len ďalšia internetová adresa a nedostane žiadnu výnimku.

Jednu chybu s prefixom sa oplatí vylúčiť zavčasu. ip route add -net 0.0.0.0 gw 10.8.0.1 dev tun0 bez dĺžky zodpovedá jedinej adrese 0.0.0.0, nie internetu; musí to byť 0.0.0.0/0. A ak prevzatie predvolenej trasy pokazí vlastnú dopravu tunela, pridajte koncový bod ako hostiteľskú trasu cez fyzické rozhranie, s použitím skutočnej adresy poskytovateľa.

Pripnite adresu svojho SSH klienta pre okamžitú opravu

Najrýchlejšia oprava je hostiteľská trasa pre adresu vášho klienta cez bránu, ktorú server používal pred tunelom. Zo svojej strany nájdite adresu, ktorú server uvidí, a potom si prečítajte tabuľku servera, aby ste poznali starú bránu:

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

Na serveri pridajte výnimku skôr, než klient naštartuje. Adresy sú tu zástupné; dôležitý je tvar:

sudo ip route add 80.128.240.55 via 192.168.178.1

Toto je oprava použitá v hlásenom prípade a funguje okamžite. Je tiež krehká dvoma predvídateľnými spôsobmi: trasa zmizne pri reštarte a bude nesprávna v momente, keď vám ISP pridelí inú adresu. Berte ju ako núdzové opatrenie a zámerne ju urobte trvalou, cez sieťovú jednotku alebo háčik dispečera, alebo prijmite, že je dočasná, a zapíšte cestu obnovy.

Zabráňte klientovi prevziať predvolenú trasu

Čistejšou možnosťou je zabrániť tunelu vôbec nahrádzať predvolenú trasu. route-nopull, použitý s --client alebo --pull, prijíma posielané voľby okrem trás, block-outside-dns a volieb v štýle DHCP, akými sú servery DNS, takže pridávate len prefixy, ktoré potrebujete. Užším nástrojom je filter sťahovania, ktorý zahodí jednu problematickú direktívu a zvyšok ponechá:

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

Použite jedno alebo druhé, nie oboje, a majte jasno v tom, čo sa mení. Bez predvolenej trasy cez tunel server už neprehliada internet cez poskytovateľa; dosiahne len to, čo ste výslovne nasmerovali. Ak bol plný tunel celým zmyslom nastavenia, toto je nesprávna páčka a hostiteľská trasa vyššie je tá správna.

Rozdeľte spiatočnú cestu podľa zdroja alebo spojenia

Keď je prichádzajúca adresa stabilná, pravidlo zdroja udrží odpovede lokálne bez toho, aby sa dotklo vlastných trás tunela. Dajte adrese fyzického rozhrania vlastnú tabuľku s prefixom LAN a fyzickou predvolenou trasou a potom túto tabuľku vyberte pre premávku, ktorá z nej pochádza:

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

Funguje to preto, lebo odpovede na prichádzajúce SSH spojenie vychádzajú z adresy, na ktorú sa klient pripojil. Hlásený prípad, v ktorom každá prichádzajúca služba musela ďalej fungovať, použil presne tento tvar. Keď prichádzajúca adresa pláva alebo je cesta dynamická, označte spojenie: nastavte značku conntrack na prvý paket z fyzického rozhrania, skopírujte ju na pakety odpovede v OUTPUT a smerujte označené pakety cez tabuľku, ktorá ukazuje na fyzickú bránu.

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

Počas testovania držte značku spojenia, značku firewallu a číslo tabuľky oddelene. Opätovné použitie jedného čísla na dve roly vytvára pravidlo, ktoré vyzerá správne a zasiahne nesprávne pakety. Predvolený záznam tabuľky tiež potrebuje via s bránou LAN na bežnom Ethernet spojení; holý dev eth0 funguje len vtedy, keď je rozhranie bod-bod alebo sa ďalší skok vyrieši inak. Hlásený hostiteľ Jessie sedel na spojení, kde holý tvar fungoval, čo nie je distribučné pravidlo na kopírovanie.

Overte bez toho, aby ste sa uzamkli vonku

Netestujte odpojením. Nechajte prvú reláciu otvorenú, zdvihnite tunel a spýtajte sa jadra, akou cestou by išla vaša vlastná adresa:

ip route get 80.128.240.55

Odpoveď by mala pomenovať fyzické rozhranie a starú bránu, nie tunel. Potom otvorte druhé SSH spojenie; to je skutočný test, pretože stará relácia môže prežiť na stave, ktorý nové spojenie nedokáže reprodukovať. Ak druhé zamrzne, kým prvé ešte odpovedá, pravidlo nikdy nezasiahlo premávku, na ktorej záleží, a hľadať treba v značkách alebo v zdrojovej adrese.

Po celý čas majte poruke konzolu mimo pásma. Server, ktorého jediná cesta prístupu je tunel, ktorý ste práve rozbili, sa nedá opraviť cez ten tunel, a návrat je ľahší, keď máte zapísané čísla tabuliek a prefixy, ktoré ste pridali.