Az OpenVPN teljes alagútja megszakítja az SSH-munkamenetet: javítsd a visszaút

Egy teljes alagútú OpenVPN-kliens bekapcsolása egy SSH-n elért gépen egy másodpercen belül elvághatja a munkamenetet, és a gép semmit sem tesz rosszul. Az alagút nem változtatja meg, hogyan érkeznek a csomagok a szerverhez; azt változtatja meg, hogyan távoznak a válaszok. Amint az alapértelmezett útvonal a tun0 felé mutat, az SSH-kliensednek szóló válasz a szolgáltató hálózatába kerül, amelynek nincs visszaút a címedhez. A kapcsolat megakad, a következő kísérlet időtúllépéssel meghiúsul, a démon pedig egész idő alatt a 22-es porton figyel.

Olvasd el az útvonaltáblát, mielőtt a VPN-naplót olvasod. A napló azt fogja mondani, hogy az alagút felállt, és igaza van. A kérdés az, melyik interfésznek adódik át minden válasz, és ez csomagonkénti keresés egy olyan táblában, amelyet az alagút épp most írt át.

Miért a rossz ajtón távozik a válasz

A bejövő csomagok továbbra is a fizikai interfészen érkeznek, mert egy VPN-kliens nem változtathatja meg, hogyan éri el az internet a szervered nyilvános címét. A válaszok külön döntés: minden csomagnál a kernel megkeresi a célt, és --redirect-gateway után az alapértelmezett bejegyzés azt mondja: alagút. A szolgáltató kijárata olyan célt lát, amelyet nem szolgál ki, és eldobja a csomagot.

Az OpenVPN saját védelme pontosan egy célt fed le. A 2.6-os kézikönyv a --redirect-gateway beállítást sorrendként írja le: hozzáad egy gazdaútvonalat a VPN-peer számára az alagút előtt használt átjárón keresztül, hogy a titkosított forgalom ne fordulhasson vissza önmagába, majd lecseréli az alapértelmezett útvonalat. Ez a gazdaútvonal csak a peeré. Az SSH-kliensed csupán egy újabb internetcím, és nem kap kivételt.

Érdemes korán kizárni egy előtaghibát. A ip route add -net 0.0.0.0 gw 10.8.0.1 dev tun0 hosszúság nélkül az egyetlen 0.0.0.0 címre illeszkedik, nem az internetre; 0.0.0.0/0 kell legyen. És ha az alapértelmezett átvétele megtöri az alagút saját átvitelét, add hozzá a végpontot gazdaútvonalként a fizikai interfészen keresztül, a szolgáltató valódi címével.

Rögzítsd az SSH-kliensed címét az azonnali javításhoz

A leggyorsabb javítás egy gazdaútvonal az ügyfélcímedhez azon az átjárón keresztül, amelyet a szerver az alagút előtt használt. A te oldaladról keresd meg a címet, amelyet a szerver látni fog, majd olvasd el a szerver tábláját, hogy ismerd a régi átjárót:

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

A szerveren add hozzá a kivételt, mielőtt az ügyfél elindul. A címek itt helyőrzők; a forma a fontos:

sudo ip route add 80.128.240.55 via 192.168.178.1

Ez a jelentett esetben használt javítás, és azonnal működik. Két kiszámítható módon is törékeny: az útvonal újraindításkor eltűnik, és abban a pillanatban válik hibássá, amikor a szolgáltatód másik címet ad. Kezeld vészintézkedésként, és tedd szándékosan tartóssá egy hálózati egységen vagy egy dispatcher-hookon keresztül, vagy fogadd el, hogy ideiglenes, és írd fel a helyreállítás útját.

Akadályozd meg, hogy a kliens átvegye az alapértelmezett útvonalat

A tisztább lehetőség megakadályozni, hogy az alagút egyáltalán lecserélje az alapértelmezett útvonalat. A route-nopull, a --client vagy a --pull mellett használva elfogadja a továbbított beállításokat az útvonalak, a block-outside-dns és a DHCP-szerű beállítások, például a DNS-szerverek kivételével, így csak a szükséges előtagokat adod hozzá. Szűkebb eszköz a húzószűrő, amely eldob egy problémás utasítást, és megtartja a többit:

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

Használd az egyiket vagy a másikat, ne mindkettőt, és legyél tisztában azzal, mi változik. Alapértelmezett útvonal nélkül az alagúton át a szerver már nem böngészi az internetet a szolgáltatón keresztül; csak azt éri el, amit kifejezetten irányítottál. Ha a teljes alagút volt a beállítás egész értelme, ez a rossz kapcsoló, és a fenti gazdaútvonal a helyes.

Oszd ketté a visszautat forrás vagy kapcsolat szerint

Amikor a bejövő cím stabil, egy forrásszabály helyben tartja a válaszokat anélkül, hogy hozzányúlna az alagút saját útvonalaihoz. Adj a fizikai interfész címének saját táblát a LAN-előtaggal és a fizikai alapértelmezéssel, majd válaszd ezt a táblát az onnan induló forgalomhoz:

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

Ez azért működik, mert a bejövő SSH-kapcsolatra adott válaszok arról a címről indulnak, amelyhez az ügyfél csatlakozott. Egy jelentett esetben, ahol minden bejövő szolgáltatásnak működnie kellett, pontosan ez a forma szerepelt. Amikor a bejövő cím lebeg, vagy az útvonal dinamikus, jelöld meg inkább a kapcsolatot: tegyél conntrack-jelet a fizikai interfészről érkező első csomagra, másold át a válaszcsomagokra az OUTPUT-ban, és irányítsd a megjelölt csomagokat egy olyan táblán keresztül, amely a fizikai átjáróra mutat.

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

A tesztelés alatt tartsd külön a kapcsolatjelet, a tűzfaljelet és a táblaszámot. Egy szám két szerepre való újrafelhasználása olyan szabályt ad, amely helyesnek látszik, és a rossz csomagokra illeszkedik. A tábla alapértelmezett bejegyzéséhez via is kell a LAN-átjáróval egy közönséges Ethernet-linken; a csupasz dev eth0 csak akkor működik, ha az interfész pont-pont, vagy a következő ugrás más módon oldódik fel. A jelentett Jessie-gazda véletlenül olyan linken ült, ahol a csupasz forma működött, ami nem másolható disztribúciós szabály.

Ellenőrizd anélkül, hogy kizárnád magad

Ne tesztelj leválasztással. Tartsd nyitva az első munkamenetet, hozd fel az alagutat, és kérdezd meg a kernelt, melyik utat venné a saját címed:

ip route get 80.128.240.55

A válasznak a fizikai interfészt és a régi átjárót kell megneveznie, nem az alagutat. Aztán nyiss egy második SSH-kapcsolatot; ez az igazi teszt, mert a régi munkamenet olyan állapoton élhet túl, amelyet egy új kapcsolat nem tud reprodukálni. Ha a második megakad, miközben az első még válaszol, a szabály soha nem illeszkedett a számító forgalomra, és a jelek vagy a forráscím az, ahol keresni kell.

Tarts sávon kívüli konzolt elérhetően az egész gyakorlat alatt. Egy szervert, amelynek egyetlen hozzáférési útja az az alagút, amelyet épp most törtél el, nem lehet azon az alagúton keresztül megjavítani, és a visszaállítás könnyebb, ha felírtad a hozzáadott táblaszámokat és előtagokat.