Puni tunel OpenVPN prekida vašu SSH sesiju: popravite povratnu putanju

Uključivanje OpenVPN klijenta s punim tunelom na mašini kojoj pristupate preko SSH može prekinuti sesiju u sekundi, a mašina ne radi ništa pogrešno. Tunel ne mijenja kako paketi stižu do servera; mijenja kako odgovori izlaze. Kad zadana ruta pokaže na tun0, odgovor vašem SSH klijentu odlazi u mrežu provajdera, koja nema rutu natrag do vaše adrese. Veza se zablokira, sljedeći pokušaj istekne, a demon sve vrijeme sluša na portu 22.

Pročitajte tabelu rutiranja prije nego pročitate VPN log. Log će reći da je tunel podignut i bit će u pravu. Pitanje je kojem interfejsu se predaje svaki odgovor, a to je pretraga po paketu u tabeli koju je tunel upravo prepisao.

Zašto odgovor izlazi na pogrešna vrata

Dolazni paketi i dalje stižu na fizički interfejs, jer VPN klijent ne može promijeniti kako internet stiže do javne adrese vašeg servera. Odgovori su zasebna odluka: za svaki paket kernel traži odredište, a nakon --redirect-gateway zadani unos kaže tunel. Izlaz provajdera vidi odredište koje ne opslužuje i odbacuje paket.

OpenVPN-ova vlastita zaštita pokriva tačno jedno odredište. Priručnik za 2.6 opisuje --redirect-gateway kao niz: dodaje host rutu za VPN peer kroz gateway koji se koristio prije tunela, tako da šifrirani saobraćaj ne može skrenuti sam u sebe, a zatim zamjenjuje zadanu rutu. Ta host ruta je samo za peer. Vaš SSH klijent je samo još jedna internet adresa i ne dobija izuzetak.

Jednu grešku s prefiksom vrijedi isključiti rano. ip route add -net 0.0.0.0 gw 10.8.0.1 dev tun0 bez dužine odgovara jednoj adresi 0.0.0.0, a ne internetu; mora biti 0.0.0.0/0. A ako preuzimanje zadane rute slomi vlastiti transport tunela, dodajte krajnju tačku kao host rutu kroz fizički interfejs, koristeći stvarnu adresu provajdera.

Prikvačite adresu svog SSH klijenta za trenutnu popravku

Najbrža popravka je host ruta za adresu vašeg klijenta kroz gateway koji je server koristio prije tunela. Sa svoje strane pronađite adresu koju će server vidjeti, pa pročitajte serverovu tabelu da biste znali stari gateway:

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

Na serveru dodajte izuzetak prije nego klijent krene. Adrese su ovdje zamjenske; bitan je oblik:

sudo ip route add 80.128.240.55 via 192.168.178.1

Ovo je popravka korištena u prijavljenom slučaju i radi odmah. Također je krhka na dva predvidiva načina: ruta nestaje pri ponovnom pokretanju i postaje pogrešna onog trenutka kad vam ISP dodijeli drugu adresu. Tretirajte je kao hitnu mjeru i namjerno je učinite trajnom, kroz mrežnu jedinicu ili dispatcher hook, ili prihvatite da je privremena i zapišite put oporavka.

Spriječite klijent da preuzme zadanu rutu

Čistija opcija je spriječiti tunel da uopće zamijeni zadanu rutu. route-nopull, korišten s --client ili --pull, prihvata gurane opcije osim ruta, block-outside-dns i opcija u stilu DHCP kao što su DNS serveri, pa dodajete samo prefikse koji su vam potrebni. Uže sredstvo je filtar povlačenja, koji odbacuje jednu problematičnu direktivu i zadržava ostale:

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

Koristite jedno ili drugo, ne oboje, i budite jasni šta se mijenja. Bez zadane rute kroz tunel, server više ne pretražuje internet kroz provajdera; dostiže samo ono što ste izričito usmjerili. Ako je puni tunel bio cijeli smisao postavke, ovo je pogrešan prekidač i host ruta iznad je prava.

Podijelite povratnu putanju po izvoru ili po vezi

Kad je dolazna adresa stabilna, pravilo izvora drži odgovore lokalno bez diranja tunelovih vlastitih ruta. Dajte adresi fizičkog interfejsa vlastitu tabelu s LAN prefiksom i fizičkim zadanim izlazom, pa odaberite tu tabelu za saobraćaj koji dolazi s nje:

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

Ovo radi jer odgovori na dolaznu SSH vezu potiču s adrese na koju se klijent povezao. Prijavljeni slučaj u kojem je svaka dolazna usluga morala nastaviti raditi koristio je upravo ovaj oblik. Kad dolazna adresa lebdi ili je put dinamičan, umjesto toga označite vezu: postavite conntrack oznaku na prvi paket koji stigne s fizičkog interfejsa, kopirajte je na odgovorne pakete u OUTPUT i usmjerite označene pakete kroz tabelu koja pokazuje na fizički gateway.

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

Držite oznaku veze, firewall oznaku i broj tabele različitim tokom testiranja. Ponovno korištenje jednog broja za dvije uloge daje pravilo koje izgleda ispravno i pogađa pogrešne pakete. Zadani unos tabele također traži via s LAN gatewayem na običnoj Ethernet vezi; goli dev eth0 radi samo kad je interfejs point-to-point ili se sljedeći skok rješava na drugi način. Prijavljeni Jessie host je slučajno bio na vezi gdje je goli oblik radio, što nije pravilo distribucije za kopiranje.

Provjerite bez toga da se zaključate

Ne testirajte tako što ćete se odspojiti. Držite prvu sesiju otvorenom, podignite tunel i pitajte kernel kojim bi putem išla vaša vlastita adresa:

ip route get 80.128.240.55

Odgovor treba navesti fizički interfejs i stari gateway, ne tunel. Zatim otvorite drugu SSH vezu; to je pravi test, jer stara sesija može preživjeti na stanju koje nova veza ne može reproducirati. Ako se druga zablokira dok prva još odgovara, pravilo nikada nije pogodilo saobraćaj koji je bitan, a oznake ili izvorna adresa su mjesto gdje treba tražiti.

Držite vanpojasnu konzolu dostupnom tokom cijele vježbe. Server čiji je jedini put pristupa tunel koji ste upravo slomili ne može se popraviti kroz taj tunel, a vraćanje je lakše kad ste zapisali brojeve tabela i prefikse koje ste dodali.