OpenVPN-i täistunnel katkestab sinu SSH-sessiooni: paranda tagasitee

Täistunneliga OpenVPN-kliendi sisselülitamine masinal, kuhu pääsed SSH kaudu, võib sessiooni sekundi jooksul katkestada, ja masin ei tee midagi valesti. Tunnel ei muuda seda, kuidas paketid serverini jõuavad; see muudab seda, kuidas vastused väljuvad. Niipea kui vaikimisi marsruut osutab tun0-le, läheb vastus sinu SSH-kliendile teenusepakkuja võrku, millel pole sinu aadressile tagasiteed. Ühendus jääb rippuma, järgmine katse aegub ja deemon kuulab kogu aja pordil 22.

Loe marsruutimistabelit enne, kui loed VPN-logi. Logi ütleb, et tunnel tõusis, ja sellel on õigus. Küsimus on, millisele liidesele iga vastus üle antakse, ja see on iga paketi otsing tabelist, mille tunnel just ümber kirjutas.

Miks vastus väljub vale ukse kaudu

Sissetulevad paketid jõuavad endiselt füüsilisele liidesele, sest VPN-klient ei saa muuta seda, kuidas internet jõuab sinu serveri avaliku aadressini. Vastused on eraldi otsus: iga paketi puhul otsib kernel sihtkoha, ja pärast --redirect-gateway ütleb vaikekirje tunnel. Teenusepakkuja väljund näeb sihtkohta, mida ta ei teeninda, ja viskab paketi ära.

OpenVPN enda kaitse katab täpselt ühe sihtkoha. 2.6 käsiraamat kirjeldab --redirect-gateway järjestusena: see lisab VPN-peerile hostmarsruudi enne tunnelit kasutusel olnud lüüsi kaudu, et krüpteeritud liiklus ei saaks iseenda sisse tagasi keerata, ja asendab seejärel vaikimisi marsruudi. See hostmarsruut on ainult peeri jaoks. Sinu SSH-klient on lihtsalt veel üks internetiaadress ja ei saa mingit erandit.

Üht prefiksiviga tasub varakult välistada. ip route add -net 0.0.0.0 gw 10.8.0.1 dev tun0 ilma pikkuseta vastab üksikule aadressile 0.0.0.0, mitte internetile; see peab olema 0.0.0.0/0. Ja kui vaikimisi marsruudi võtmine lõhub tunneli enda transporti, lisa lõpp-punkt hostmarsruudina läbi füüsilise liidese, kasutades teenusepakkuja tegelikku aadressi.

Kinnita oma SSH-kliendi aadress koheseks paranduseks

Kiireim parandus on hostmarsruut sinu kliendi aadressile läbi lüüsi, mida server kasutas enne tunnelit. Oma poolt leia aadress, mida server näeb, ja loe siis serveri tabelit, et teada vana lüüsi:

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

Serveris lisa erand enne, kui klient käivitub. Aadressid on siin kohahoidjad; tähtis on vorm:

sudo ip route add 80.128.240.55 via 192.168.178.1

See on raporteeritud juhtumis kasutatud parandus ja see töötab kohe. See on ka hapra kahel etteaimataval viisil: marsruut kaob taaskäivitamisel ja muutub valeks hetkel, mil sinu ISP annab sulle teise aadressi. Käsitle seda hädaabimeetmena ja tee see meelega püsivaks, võrguüksuse või dispetšeri konksu kaudu, või lepi, et see on ajutine, ja kirjuta taastetee üles.

Takista kliendil vaikimisi marsruudi võtmine

Puhtam valik on takistada tunnelil vaikimisi marsruuti üldse asendada. route-nopull, kasutatuna koos --client või --pull-ga, võtab vastu lükatud valikud peale marsruutide, block-outside-dns ja DHCP-laadsete valikute nagu DNS-serverid, nii et lisad ainult vajalikud prefiksid. Kitsam tööriist on tõmbe filter, mis viskab ära ühe problemaatilise direktiivi ja hoiab ülejäänud:

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

Kasuta ühte või teist, mitte mõlemat, ja ole selge, mis muutub. Ilma vaikimisi marsruudita läbi tunneli ei sirvi server enam internetti teenusepakkuja kaudu; see jõuab ainult selleni, mida sa selgesõnaliselt marsruutisid. Kui täistunnel oli kogu seadistuse mõte, on see vale hoob ja ülalolev hostmarsruut on õige.

Jaga tagasitee allika või ühenduse järgi

Kui sissetulev aadress on stabiilne, hoiab allika reegel vastused kohalikuna ilma tunneli enda marsruute puutumata. Anna füüsilise liidese aadressile oma tabel, mis sisaldab LAN-prefiksit ja füüsilist vaikemarsruuti, ja vali siis see tabel sellelt lähtuvale liiklusele:

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

See töötab, sest sissetuleva SSH-ühenduse vastused pärinevad aadressilt, millega klient ühendus. Raporteeritud juhtum, kus iga sissetulev teenus pidi edasi töötama, kasutas täpselt sellist vormi. Kui sissetulev aadress hõljub või tee on dünaamiline, märgi hoopis ühendus: pane conntrack-märk esimesele füüsiliselt liideselt saabuvale paketile, kopeeri see OUTPUT-is vastusepakettidele ja marsruudi märgitud paketid läbi tabeli, mis osutab füüsilisele lüüsile.

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

Hoia testimise ajal ühenduse märk, tulemüüri märk ja tabelinumber eraldi. Ühe numbri korduskasutamine kahes rollis annab reegli, mis näeb õige välja ja tabab valesid pakette. Tabeli vaikekirje vajab tavalises Ethernet-lingis ka via koos LAN-lüüsiga; paljas dev eth0 töötab ainult siis, kui liides on punkt-punkt või järgmine hüpe lahendatakse muul viisil. Raporteeritud Jessie-host juhtus olema lingil, kus paljas vorm töötas, mis ei ole kopeeritav distributsioonireegel.

Kontrolli, ilma et end välja lukustaksid

Ära testi lahtiühendamisega. Hoia esimene sessioon lahti, tõsta tunnel üles ja küsi kernelilt, millist teed sinu enda aadress läheks:

ip route get 80.128.240.55

Vastus peaks nimetama füüsilise liidese ja vana lüüsi, mitte tunnelit. Seejärel ava teine SSH-ühendus; see on tõeline test, sest vana sessioon võib jääda püsima olekule, mida uus ühendus ei suuda taastada. Kui teine jääb rippuma, samal ajal kui esimene veel vastab, ei tabanud reegel kunagi olulist liiklust, ja märgid või allikaaadress on koht, kuhu vaadata.

Hoia kogu harjutuse ajal käepärast välisvõrgu konsooli. Serverit, mille ainus juurdepääsutee on tunnel, mille sa just lõhkusid, ei saa selle tunneli kaudu parandada, ja tagasipööramine on lihtsam, kui oled tabelinumbrid ja lisatud prefiksid üles kirjutanud.