Full tunnel i OpenVPN kutter SSH-økten din: reparer returveien

Å slå på en OpenVPN-klient med full tunnel på en maskin du når over SSH kan kutte økten i løpet av et sekund, og maskinen gjør ingenting galt. Tunnelen endrer ikke hvordan pakker når serveren; den endrer hvordan svarene går ut. Straks standardruten peker på tun0, går et svar til SSH-klienten din inn i leverandørens nettverk, som ikke har noen rute tilbake til adressen din. Forbindelsen henger, neste forsøk går ut på tid, og daemonen lytter fortsatt på port 22 hele tiden.

Les rutetabellen før du leser VPN-loggen. Loggen vil si at tunnelen kom opp, og den har rett. Spørsmålet er hvilket grensesnitt hvert svar overleveres til, og det er et oppslag per pakke i en tabell som tunnelen nettopp har skrevet om.

Hvorfor svaret går ut gjennom feil dør

Innkommende pakker ankommer fortsatt på det fysiske grensesnittet, fordi en VPN-klient ikke kan endre hvordan internett når serverens offentlige adresse. Svarene er en egen beslutning: for hver pakke slår kjernen opp målet, og etter --redirect-gateway sier standardoppføringen tunnel. Leverandørens utgang ser en destinasjon den ikke betjener og slipper pakken.

OpenVPN sin egen beskyttelse dekker nøyaktig én destinasjon. 2.6-håndboken beskriver --redirect-gateway som en sekvens: den legger til en vertsrute for VPN-peeren gjennom gatewayen som ble brukt før tunnelen, slik at den krypterte trafikken ikke kan gå i loop tilbake i seg selv, og erstatter deretter standardruten. Den vertsruten er bare for peeren. SSH-klienten din er bare en annen internettadresse og får ingen unntak.

Én prefiksfeil er verdt å utelukke tidlig. ip route add -net 0.0.0.0 gw 10.8.0.1 dev tun0 uten lengde samsvarer med den ene adressen 0.0.0.0, ikke internett; den må være 0.0.0.0/0. Og hvis det å ta standarden ødelegger tunnelens egen transport, legg endepunktet til som en vertsrute gjennom det fysiske grensesnittet, med leverandørens virkelige adresse.

Fest klientadressen din for en umiddelbar reparasjon

Den raskeste reparasjonen er en vertsrute for klientadressen din gjennom gatewayen serveren brukte før tunnelen fantes. Fra din side, finn adressen serveren vil se, og les deretter serverens tabell så du kjenner den gamle gatewayen:

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

På serveren legger du til unntaket før klienten starter. Adressene her er plassholdere; formen er det som betyr noe:

sudo ip route add 80.128.240.55 via 192.168.178.1

Dette er reparasjonen som ble brukt i det rapporterte tilfellet, og den virker umiddelbart. Den er også skjør på to forutsigbare måter: ruten forsvinner ved omstart, og den blir feil i det øyeblikket ISP-en gir deg en annen adresse. Behandle den som et nødtiltak og gjør den bevisst varig, gjennom en nettverksenhet eller en dispatcher-krok, eller godta at den er midlertidig og skriv ned gjenopprettingsveien.

Hindre klienten i å ta standardruten

Det renere alternativet er å hindre tunnelen i å erstatte standardruten i det hele tatt. route-nopull, brukt med --client eller --pull, godtar push-alternativer unntatt ruter, block-outside-dns og DHCP-lignende alternativer som DNS-servere, så du legger bare til prefiksene du trenger. Et smalere verktøy er et pull-filter, som dropper én problematisk direktiv og beholder resten:

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

Bruk det ene eller det andre, ikke begge, og vær klar over hva som endres. Uten standardrute gjennom tunnelen surfer ikke serveren internett gjennom leverandøren lenger; den når bare det du eksplisitt rutet. Hvis den fulle tunnelen var hele poenget med oppsettet, er dette feil knapp, og vertsruten ovenfor er den riktige.

Del returveien etter kilde eller forbindelse

Når den innkommende adressen er stabil, holder en kilderegel svarene lokale uten å røre tunnelens egne ruter. Gi adressen til det fysiske grensesnittet sin egen tabell med LAN-prefikset og den fysiske standarden, og velg deretter den tabellen for trafikk som kommer derfra:

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 virker fordi svar på en innkommende SSH-forbindelse kommer fra adressen klienten koblet til. Et rapportert tilfelle der hver innkommende tjeneste måtte fortsette å virke, brukte nøyaktig denne formen. Når den innkommende adressen flyter eller veien er dynamisk, marker forbindelsen i stedet: sett et conntrack-merke på den første pakken fra det fysiske grensesnittet, kopier det til svarpakker i OUTPUT, og rut merkede pakker gjennom en tabell som peker 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

Hold forbindelsesmerket, brannmurmerket og tabellnummeret atskilt mens du tester. Gjenbruk av ett nummer til to roller gir en regel som ser riktig ut og treffer feil pakker. Tabellens standardoppføring trenger også via med LAN-gatewayen på en vanlig Ethernet-lenke; en naken dev eth0 virker bare når grensesnittet er punkt-til-punkt eller neste hopp løses på en annen måte. Den rapporterte Jessie-verten satt tilfeldigvis på en lenke der den nakne formen virket, noe som ikke er en distribusjonsregel å kopiere.

Verifiser uten å låse deg ute

Ikke test ved å koble fra. Hold den første økten åpen, ta tunnelen opp, og spør kjernen hvilken vei din egen adresse ville ta:

ip route get 80.128.240.55

Svaret bør navngi det fysiske grensesnittet og den gamle gatewayen, ikke tunnelen. Åpne deretter en andre SSH-forbindelse; det er den virkelige testen, fordi den gamle økten kan overleve på tilstand en ny forbindelse ikke kan gjenskape. Hvis den andre henger mens den første fortsatt svarer, har regelen aldri truffet trafikken som betyr noe, og merkene eller kildeadressen er stedet å se.

Hold en konsoll utenfor båndet tilgjengelig gjennom hele øvelsen. En server hvis eneste tilgangsvei er tunnelen du nettopp har ødelagt, kan ikke repareres over den tunnelen, og tilbakerullingen er lettere når du har skrevet ned tabellnummerne og prefiksene du la til.