Įjungus viso tunelio OpenVPN klientą mašinoje, prie kurios jungiatės per SSH, sesija gali nutrūkti per sekundę, o mašina nedaro nieko blogo. Tunelis nekeičia to, kaip paketai pasiekia serverį; jis keičia tai, kaip išeina atsakymai. Kai numatytasis maršrutas nukreipiamas į tun0, atsakymas jūsų SSH klientui patenka į tiekėjo tinklą, kuris neturi maršruto atgal į jūsų adresą. Ryšys pakimba, kita užklausa baigiasi skirtuoju laiku, o demonas visą laiką klausosi 22 prievade.

Perskaitykite maršrutizavimo lentelę prieš skaitydami VPN žurnalą. Žurnalas pasakys, kad tunelis pakilo, ir bus teisus. Klausimas, kuriam sąsajai perduodamas kiekvienas atsakymas, ir tai yra paieška kiekvienam paketui lentelėje, kurią tunelis ką tik perrašė.

Kodėl atsakymas išeina pro netinkamas duris

Įeinantys paketai vis dar atvyksta į fizinę sąsają, nes VPN klientas negali pakeisti to, kaip internetas pasiekia jūsų serverio viešąjį adresą. Atsakymai yra atskiras sprendimas: kiekvienam paketui branduolys ieško paskirties, o po --redirect-gateway numatytasis įrašas sako tunelis. Tiekėjo išėjimas mato paskirtį, kurios neaptarnauja, ir meta paketą.

OpenVPN apsauga pati savaime dengia lygiai vieną paskirtį. 2.6 vadovas aprašo --redirect-gateway kaip seką: jis prideda pagrindinio kompiuterio maršrutą VPN peerui per šliuzą, naudotą prieš tunelį, kad šifruotas srautas negalėtų grįžti į save, o tada pakeičia numatytąjį maršrutą. Tas maršrutas skirtas tik peerui. Jūsų SSH klientas yra tik dar vienas interneto adresas ir negauna jokios išimties.

Vieną priešdėlio klaidą verta pašalinti anksti. ip route add -net 0.0.0.0 gw 10.8.0.1 dev tun0 be ilgio atitinka vieną adresą 0.0.0.0, o ne internetą; turi būti 0.0.0.0/0. Ir jei numatytojo ėmimas sugriauna patį tunelio transportą, pridėkite galinį tašką kaip pagrindinio kompiuterio maršrutą per fizinę sąsają, naudodami tikrąjį tiekėjo adresą.

Prisekite savo SSH kliento adresą, kad ištaisytumėte iškart

Greičiausias taisymas yra pagrindinio kompiuterio maršrutas jūsų kliento adresui per šliuzą, kurį serveris naudojo prieš tunelį. Iš savo pusės raskite adresą, kurį matys serveris, tada perskaitykite serverio lentelę, kad žinotumėte senąjį šliuzą:

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

Serveryje pridėkite išimtį prieš klientui paleidžiant. Adresai čia yra vietos rezervai; forma yra tai, kas svarbu:

sudo ip route add 80.128.240.55 via 192.168.178.1

Tai yra taisymas, naudotas praneštame atvejyje, ir jis veikia iš karto. Jis taip pat trapus dvejopai nuspėjamai: maršrutas dingsta perkraunant, ir jis tampa neteisingas tuo metu, kai jūsų ISP suteikia kitą adresą. Laikykite tai avarine priemone ir sąmoningai padarykite ilgalaikį, per tinklo įrenginį ar dispatcher kablį, arba pripažinkite, kad jis laikinas, ir užsirašykite atkūrimo kelią.

Neleiskite klientui paimti numatytojo maršruto

Švaresnė parinktis yra neleisti tuneliui apskritai pakeisti numatytojo maršruto. route-nopull, naudojamas su --client arba --pull, priima stumiamas parinktis, išskyrus maršrutus, block-outside-dns ir DHCP stiliaus parinktis, tokias kaip DNS serveriai, todėl pridedate tik reikiamus priešdėlius. Siauresnis įrankis yra traukimo filtras, kuris atmeta vieną problemišką direktyvą ir palieka likusias:

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

Naudokite vieną arba kitą, ne abu, ir aiškiai supraskite, kas keičiasi. Be numatytojo maršruto per tunelį serveris nebe naršo interneto per tiekėją; jis pasiekia tik tai, ką aiškiai maršrutizavote. Jei visas tunelis buvo visas sąrankos tikslas, tai netinkama svirtis, o aukščiau pateiktas maršrutas yra tinkamas.

Padalinkite grįžtamąjį kelią pagal šaltinį arba jungtį

Kai įeinantis adresas yra stabilus, šaltinio taisyklė išlaiko atsakymus vietinius neliesdama pačių tunelio maršrutų. Duokite fizinės sąsajos adresui savo lentelę su LAN priešdėliu ir fiziniu numatytuoju maršrutu, tada pasirinkite tą lentelę iš jo ateinančiam srautui:

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

Tai veikia todėl, kad atsakymai į įeinančią SSH jungtį siunčiami iš adreso, prie kurio prisijungė klientas. Praneštas atvejis, kai kiekviena įeinanti paslauga turėjo toliau veikti, naudojo būtent tokią formą. Kai įeinantis adresas plūduriuoja arba kelias dinamiškas, pažymėkite jungtį: uždėkite conntrack žymą pirmam paketui iš fizinės sąsajos, nukopijuokite ją atsakymo paketams OUTPUT, ir maršrutizuokite pažymėtus paketus per lentelę, kuri rodo į fizinį šliuzą.

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

Bandymo metu laikykite jungties žymą, ugniasienės žymą ir lentelės numerį atskirai. Vieno numerio naudojimas dviem vaidmenims sukuria taisyklę, kuri atrodo teisinga ir pataiko netinkamus paketus. Lentelės numatytajam įrašui taip pat reikia via su LAN šliuzu įprastoje Ethernet jungtyje; plikas dev eth0 veikia tik kai sąsaja yra taškas-taškas arba kitas šuolis sprendžiamas kitaip. Praneštas Jessie kompiuteris atsitiktinai buvo jungtyje, kur plika forma veikė, ir tai nėra platinimo taisyklė, kurią verta kopijuoti.

Patikrinkite neužsirakindami

Nebandykite atsijungdami. Palikite pirmą sesiją atvirą, pakelkite tunelį ir paklauskite branduolio, kokiu keliu eitų jūsų pačių adresas:

ip route get 80.128.240.55

Atsakymas turėtų įvardyti fizinę sąsają ir senąjį šliuzą, o ne tunelį. Tada atidarykite antrą SSH jungtį; tai tikrasis bandymas, nes sena sesija gali išlikti būsenoje, kurios nauja jungtis negali atkurti. Jei antroji pakimba, o pirmoji dar atsako, taisyklė niekada nepataikė svarbaus srauto, ir žymos ar šaltinio adresas yra vieta, kur reikia žiūrėti.

Viso pratimo metu turėkite pasiekiamą užjuostę konsolę. Serverio, kurio vienintelis prieigos kelias yra ką tik sugadintas tunelis, negalima sutaisyti per tą tunelį, o atsukimas atgal lengvesnis, kai užsirašote lentelių numerius ir priešdėlius, kuriuos pridėjote.

Susiję straipsniai