Volle tonnel in OpenVPN kap jou SSH-sessie: maak die terugpad reg

Die verstekroete stuur SSH-antwoorde in die tonnel in. Pen die peer vas, filter redirect-gateway, of roeteer volgens bron voordat jy die masjien verloor.

Om 'n volle-tonnel-OpenVPN-kliënt aan te skakel op 'n masjien wat jy oor SSH bereik, kan die sessie binne 'n sekonde afkap, en die masjien doen niks verkeerd nie. Die tonnel verander nie hoe pakkies die bediener bereik nie; dit verander hoe die antwoorde vertrek. Sodra die verstekroete na tun0 wys, gaan 'n antwoord aan jou SSH-kliënt in die verskaffer se netwerk in, wat geen roete terug na jou adres het nie. Die verbinding hang, die volgende poging verstryk, en die daemon luister die hele tyd nog op poort 22.

Lees die roeteringstabel voordat jy die VPN-log lees. Die log sal sê die tonnel het opgekom, en dit is reg. Die vraag is aan watter koppelvlak elke antwoord oorhandig word, en dit is 'n soektog per pakkie teen 'n tabel wat die tonnel pas herskryf het.

Hoekom die antwoord by die verkeerde deur uitgaan

Inkomende pakkies kom steeds op die fisiese koppelvlak aan, want 'n VPN-kliënt kan nie verander hoe die internet jou bediener se openbare adres bereik nie. Antwoorde is 'n aparte besluit: vir elke pakkie soek die kernel die bestemming op, en ná --redirect-gateway sê die verstekinskrywing tonnel. Die verskaffer se uitgang sien 'n bestemming wat hy nie bedien nie en laat die pakkie val.

OpenVPN se eie beskerming dek presies een bestemming. Die 2.6-handleiding beskryf --redirect-gateway as 'n reeks: dit voeg 'n gasheerreute vir die VPN-peer by deur die gateway wat voor die tonnel in gebruik was, sodat die versleutelde verkeer nie in homself kan teruglus nie, en vervang dan die verstekroete. Daardie gasheerreute is net vir die peer. Jou SSH-kliënt is net nog 'n internetadres en kry geen uitsondering nie.

'n Voorvoegselfout is vroeg die moeite werd om uit te skakel. ip route add -net 0.0.0.0 gw 10.8.0.1 dev tun0 sonder 'n lengte pas by die enkele adres 0.0.0.0, nie by die internet nie; dit moet 0.0.0.0/0 wees. En as die verstek die tonnel se eie vervoer breek, voeg die eindpunt as 'n gasheerreute deur die fisiese koppelvlak by, met die verskaffer se werklike adres.

Pen jou SSH-kliëntadres vas vir 'n onmiddellike oplossing

Die vinnigste herstelling is 'n gasheerreute vir jou kliëntadres deur die gateway wat die bediener voor die tonnel gebruik het. Van jou kant af, vind die adres wat die bediener sal sien, en lees dan die bediener se tabel sodat jy die ou gateway ken:

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

Op die bediener, voeg die uitsondering by voordat die kliënt begin. Die adresse hier is plekhouers; die vorm is wat saak maak:

sudo ip route add 80.128.240.55 via 192.168.178.1

Dit is die oplossing wat in die gerapporteerde geval gebruik is, en dit werk dadelik. Dit is ook broos op twee voorspelbare maniere: die roete verdwyn by herbegin, en dit word verkeerd op die oomblik dat jou ISP 'n ander adres aan jou gee. Behandel dit as 'n noodmaatstaf en maak dit doelbewus duursaam, deur 'n netwerkeenheid of 'n dispatcher-haak, of aanvaar dat dit tydelik is en skryf die herstelpad neer.

Keer dat die kliënt die verstek neem

Die skoner opsie is om te verhoed dat die tonnel die verstekroete hoegenaamd vervang. route-nopull, gebruik saam met --client of --pull, aanvaar gestuurde opsies behalwe roetes, block-outside-dns, en DHCP-agtige opsies soos DNS-bediener, so jy voeg net die voorvoegsels by wat jy nodig het. 'n Nouer gereedskap is 'n trekfilter, wat een aanstootlike richtlijn laat val en die res hou:

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

Gebruik die een of die ander, nie albei nie, en wees duidelik oor wat verander. Sonder 'n verstekroete deur die tonnel, blaai die bediener nie meer deur die verskaffer op die internet nie; dit bereik net wat jy eksplisiet gerouteer het. As die volle tonnel die hele punt van die opstelling was, is dit die verkeerde knop en is die gasheerreute hierbo die regte een.

Splits die terugpad volgens bron of verbinding

Wanneer die inkomende adres stabiel is, hou 'n bronreël antwoorde plaaslik sonder om aan die tonnel se eie roetes te raak. Gee die fisiese koppelvlakadres sy eie tabel met die LAN-voorvoegsel en die fisiese verstek, en kies dan daardie tabel vir verkeer wat daarvan afkomstig is:

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

Dit werk omdat antwoorde op 'n inkomende SSH-verbinding afkomstig is van die adres waaraan die kliënt gekoppel het. 'n Gerapporteerde geval waar elke inkomende diens moes bly werk, het presies hierdie vorm gebruik. Wanneer die inkomende adres swerf of die pad dinamies is, merk die verbinding eerder: stel 'n conntrack-merk op die eerste pakkie wat van die fisiese koppelvlak kom, kopieer dit na antwoordpakkies in OUTPUT, en roeteer gemerkte pakkies deur 'n tabel wat na die fisiese gateway wys.

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

Hou die verbindingsmerk, firewallmerk en tabelnommer apart terwyl jy toets. Om een nommer vir twee rolle te hergebruik, lewer 'n reël wat korrek lyk en die verkeerde pakkies pas. Die tabel se verstekinskrywing het ook via met die LAN-gateway op 'n gewone Ethernet-skakel nodig; 'n kaal dev eth0-verstek werk net wanneer die koppelvlak punt-tot-punt is of die volgende hop op 'n ander manier opgelos word. Die gerapporteerde Jessie-gasheer het toevallig op 'n skakel gesit waar die kaal vorm gewerk het, wat nie 'n verspreidingsreël is om te kopieer nie.

Verifieer sonder om jouself uit te sluit

Moenie deur te ontkoppel toets nie. Hou die eerste sessie oop, bring die tonnel op, en vra die kernel watter pad jou eie adres sou neem:

ip route get 80.128.240.55

Die antwoord moet die fisiese koppelvlak en die ou gateway noem, nie die tonnel nie. Maak dan 'n tweede SSH-verbinding oop; dit is die werklike toets, want die ou sessie kan oorleef op toestand wat 'n nuwe verbinding nie kan herproduseer nie. As die tweede hang terwyl die eerste nog antwoord, het die reël nooit die verkeer gepas wat saak maak nie, en die merke of die bronadres is waar jy moet kyk.

Hou 'n buitebandse konsole beskikbaar vir die hele oefening. 'n Bediener wie se enigste toegangspad die tonnel is wat jy pas gebreek het, kan nie oor daardie tonnel herstel word nie, en die terugrol is makliker wanneer jy die tabelnommers en voorvoegsels neergeskryf het wat jy bygevoeg het.

Verwante artikels