Full tunnel i OpenVPN kuttar SSH-økta di: reparer returvegen

Å slå på ein OpenVPN-klient med full tunnel på ein maskin du når over SSH kan kutte økta på eit sekund, og maskinen gjer ingenting gale. Tunnelen endrar ikkje korleis pakkar når serveren; han endrar korleis svara går ut. Straks standardruta peikar på tun0, går eit svar til SSH-klienten din inn i nettverket til leverandøren, som ikkje har noka rute tilbake til adressa di. Sambandet heng, neste forsøk går ut på tid, og daemonen lyttar framleis på port 22 heile tida.

Les rutetabellen før du les VPN-loggen. Loggen vil seie at tunnelen kom opp, og han har rett. Spørsmålet er kva grensesnitt kvart svar blir overlevert til, og det er eit oppslag per pakke i ein tabell som tunnelen nettopp har skrive om.

Kvifor svaret går ut gjennom feil dør

Innkommande pakkar kjem framleis inn på det fysiske grensesnittet, fordi ein VPN-klient ikkje kan endre korleis internett når den offentlege adressa til serveren. Svara er ei eiga avgjerd: for kvar pakke slår kjernen opp målet, og etter --redirect-gateway seier standardoppføringa tunnel. Utgangen til leverandøren ser ein destinasjon han ikkje ten på og slepp pakken.

OpenVPN sin eigen beskyttelse dekkjer nøyaktig ein destinasjon. 2.6-handboka skildrar --redirect-gateway som ein sekvens: ho legg til ei vertsrute for VPN-peeren gjennom gatewayen som var i bruk før tunnelen, slik at den krypterte trafikken ikkje kan gå i loop tilbake i seg sjølv, og erstattar deretter standardruta. Den vertsruta er berre for peeren. SSH-klienten din er berre ei anna internettadresse og får ingen unntak.

Éin prefiksfeil er verdt å utelukke tidleg. ip route add -net 0.0.0.0 gw 10.8.0.1 dev tun0 utan lengd svarer til den eine adressa 0.0.0.0, ikkje internett; ho må vere 0.0.0.0/0. Og viss det å ta standarden øydelegg for eigen transport av tunnelen, legg endepunktet til som ei vertsrute gjennom det fysiske grensesnittet, med den verkelege adressa til leverandøren.

Fest klientadressa di for ein umiddelbar reparasjon

Den raskaste reparasjonen er ei vertsrute for klientadressa di gjennom gatewayen serveren brukte før tunnelen fanst. Frå di side, finn adressa serveren vil sjå, og les deretter tabellen til serveren så du kjenner den gamle gatewayen:

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

På serveren legg du til unntaket før klienten startar. Adressene her er plasshaldarar; forma er det som tel:

sudo ip route add 80.128.240.55 via 192.168.178.1

Dette er reparasjonen som vart brukt i det rapporterte tilfellet, og han verkar med ein gong. Han er også skøyr på to føreseielege måtar: ruta forsvinn ved omstart, og ho blir feil i det augneblunken ISP-en gir deg ei anna adresse. Handsame han som eit naudtiltak og gjer han medvite varig, gjennom ei nettverksening eller ein dispatcher-krok, eller godta at han er mellombels og skriv ned gjenopprettingsvegen.

Hindre klienten i å ta standardruta

Det reinare alternativet er å hindre tunnelen i å erstatte standardruta i det heile. route-nopull, brukt med --client eller --pull, godtar push-alternativ unntatt ruter, block-outside-dns og DHCP-liknande alternativ som DNS-tenarar, så du legg berre til prefiksa du treng. Eit smalare verktøy er eit pull-filter, som droppar éin problematisk direktiv og held på resten:

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

Bruk det eine eller det andre, ikkje begge, og ver klar over kva som endrar seg. Utan standardrute gjennom tunnelen surfar ikkje serveren internett gjennom leverandøren lenger; han når berre det du eksplisitt ruta. Viss den fulle tunnelen var heile poenget med oppsettet, er dette feil knapp, og vertsruta ovanfor er den rette.

Del returvegen etter kjelde eller samband

Når den innkommande adressa er stabil, held ei kjelde-regel svara lokale utan å røre dei eigne rutene til tunnelen. Gi adressa til det fysiske grensesnittet sin eigen tabell med LAN-prefikset og den fysiske standarden, og vel deretter den tabellen for trafikk som kjem derifrå:

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

Dette verkar fordi svar på eit innkommande SSH-samband kjem frå adressa klienten kopla til. Eit rapportert tilfelle der kvar innkommande teneste måtte halde fram med å verke, brukte nøyaktig denne forma. Når den innkommande adressa flyt eller vegen er dynamisk, merk sambandet i staden: set eit conntrack-merke på den første pakken frå det fysiske grensesnittet, kopier det til svarpakkar i OUTPUT, og rut merkte pakkar gjennom ein tabell som peikar på den fysiske gatewayen.

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

Hald sambandsmerket, brannmurmerket og tabellnummeret åtskilt medan du testar. Gjenbruk av eitt nummer til to roller gir ei regel som ser rett ut og treff feil pakkar. Standardoppføringa i tabellen treng også via med LAN-gatewayen på ei vanleg Ethernet-lenke; ein naken dev eth0 verkar berre når grensesnittet er punkt-til-punkt eller neste hopp blir løyst på ein annan måte. Den rapporterte Jessie-verten sat tilfeldigvis på ei lenke der den nakne forma verka, noko som ikkje er ein distribusjonsregel å kopiere.

Stadfest utan å låse deg ute

Ikkje test ved å kopie frå. Hald den første økta open, ta tunnelen opp, og spør kjernen kva veg di eiga adresse ville ta:

ip route get 80.128.240.55

Svaret bør nemne det fysiske grensesnittet og den gamle gatewayen, ikkje tunnelen. Opne deretter eit andre SSH-samband; det er den verkelege testen, fordi den gamle økta kan overleve på tilstand eit nytt samband ikkje kan gjenskape. Viss det andre heng medan det første framleis svarar, har regelen aldri treft trafikken som tel, og merka eller kjelde-adressa er staden å sjå.

Hald ein konsoll utanfor bandet tilgjengeleg gjennom heile øvinga. Ein server der den einaste tilgangsvegen er tunnelen du nettopp har øydelagt, kan ikkje reparerast over den tunnelen, og tilbakerullinga er lettare når du har skrive ned tabellnummera og prefiksa du la til.