Volledige tunnel doodde je SSH-sessie: pin de retourroute

Start een OpenVPN client op de machine waarop je via SSH werkt, en midden in het commando bevriest de sessie. De tunnel meldt dat hij verbonden is, de host bereikt het internet erdoor, en je toetsaanslagen komen nog steeds aan terwijl er niets terugkomt. Wat veranderd is, is niet de tunnel: het is de retourweg voor pakketten die aan jou geadresseerd zijn, die nu overeenkomt met de nieuwe standaardroute en een tunnel in gaat die de externe gateway niet zal gebruiken om je bureau te bereiken.

Wat redirect-gateway werkelijk installeert

In zijn def1 vorm redirect-gateway voegt het 0.0.0.0/1 en 128.0.0.0/1 toe in plaats van de standaardroute te overschrijven. Die twee helften dekken de hele adresruimte terwijl beide langere prefixen blijven dan 0.0.0.0/0, dus elke bestemming zonder specifiekere match gaat nu de tunnel in. Dat is het mechanisme dat je moet onthouden, want elke oplossing hieronder werkt door een specifiekere match te installeren.

Je beheeradres is een van die bestemmingen.

De VPN-server stuurt verkeer van zijn clients richting internet. Hij heeft geen route naar het openbare adres waarvandaan je verbindt, en geen reden om die pakketten anders te behandelen dan verkeer dat van een client komt, dus hij gooit ze weg. Ondertussen bereikte het verzoek dat je stuurde de host toch, en daarom lijkt de sessie maar aan één kant levend.

ip route show table main | head -n 20
ip route get 198.51.100.23

Vind je bronadres en het pad vóór de tunnel

Op de server, lijst de opgezette SSH-verbinding op en noteer het peeradres waar die vandaan kwam. Dat adres is wat je retourroute moet dekken, en het is niet altijd wat je denkt: een spronghost, een NAT-gateway of een vertaler van de provider kan een andere bron invullen.

Zoek daarna de fysieke gateway en de interface die het verkeer droegen voordat de tunnel begon. In de def1 opstelling staat de standaardroute nog steeds onder de half-standaarden, dus de informatie is beschikbaar, al nodigt een lange routetabel met het oog lezen uit tot fouten.

Noteer beide waarden en de interfacenaam samen, want de route die je gaat toevoegen heeft alle drie nodig. Als de host een policy routing-regel gebruikte om zijn uplink te kiezen, wordt een gewone route misschien helemaal niet bekeken, en die mogelijkheid verandert de oplossing.

Pin een hostroute die de half-standaarden overtreft

Een /32 route is langer dan elk van de twee half-standaarden, dus antwoorden naar jouw adres nemen die in plaats van de tunnel. De volgende hop is de gateway vóór de tunnel en het apparaat is de fysieke interface, wat het pakket op het pad houdt dat het gebruikte voordat de tunnel bestond.

ip route add 198.51.100.23/32 via 203.0.113.1 dev eth0

Controleer met een opzoeking in plaats van de tabel te bekijken: het antwoord moet eth0 en de gateway noemen, nooit tun0.

OpenVPN voegt al een hostroute naar het eigen adres van de VPN-server om dezelfde reden toe, dus het patroon is bekend en het beheeradres is gewoon nog een uitzondering. Grijp niet naar route-nopull om dit op te lossen, want dat gooit de gepushte routes weg die de tunnel nodig heeft, inclusief het externe netwerk en de DNS-opties.

Zorg dat het een herverbinding overleeft

Een met de hand toegevoegde route verdwijnt wanneer de client opnieuw verbindt en zijn eigen route installeert, wat een oplossing in een terugkerende storing verandert. Hang het commando aan iets dat draait nadat de routes zijn geïnstalleerd.

Zowel een route-up script als de pre-up-hook van de netwerkbeheerder werken, en de betrouwbare controle is een herverbinding gevolgd door dezelfde opzoeking.

Op Windows is het equivalent een blijvende route die met -p wordt toegevoegd, die herstarts overleeft maar na een netwerkwijziging nog steeds naar de juiste gateway moet wijzen. Welk platform dan ook, schrijf de reden naast de route: de volgende beheerder moet weten dat hij bestaat om een beheersessie te beschermen, niet omdat het netwerkontwerp het eiste.

Wanneer een gepinde route nog steeds niet genoeg is

Filtering van de omgekeerde route kan een pakket weggooien dat op de ene interface binnenkomt en via een andere vertrekt, en dat is precies wat een gepinde route creëert. Controleer de effectieve rp_filter waarde voordat je iets globaal uitschakelt, en repareer liever de asymmetrie dan de controle uit te zetten. De instelling per interface is degene die geldt, en de loose-modus logt vaak alleen de asymmetrie in plaats van het pakket weg te gooien. Lees beide voordat je concludeert dat het filter jouw schuld is.

Hosts met policy routing hebben een regel nodig naast een route, omdat de regelbasis de tabel kiest voordat de route daarin wordt bekeken. Een route in de main-tabel is onzichtbaar voor een stroom die overeenkomt met een regel die naar een andere tabel wijst. Lees de regels voordat je iets aan main toevoegt. Als een regel al beheerverkeer dekt, hoort de uitzondering in de tabel van die regel.

Houd een out-of-band-console open terwijl je test, en controleer opnieuw vanaf een tweede login voordat je de login loskoppelt die je gebruikt. Een route die je eigen beheerverkeer de tunnel in stuurt, snijdt de verbinding door waar je het mee repareert. Weer binnenkomen betekent dan een seriële console of een reddingsboot, wat een slechte ruil is voor het overslaan van één verificatiestap.