De webserver verdwijnt zodra de VPN-client verbindt

Een dienst die verdwijnt op het moment dat een VPN-client verbindt, wordt meestal niet geblokkeerd, hij antwoordt via de verkeerde interface. Het verzoek komt binnen op de fysieke netwerkkaart, de daemon schrijft een antwoord en de routetabel geeft dat antwoord aan de tunnel, omdat de tunnel de standaardroute heeft overgenomen. De externe client ziet nooit een antwoord op een verbinding die hij opende, dus hij wacht en meldt daarna een time-out. Geen enkele firewallregel is ergens in die volgorde betrokken.

Het symptoom: verzoeken erin, antwoorden via de verkeerde deur eruit

Het teken is een inkomende verbinding die mislukt terwijl al het andere op de host werkt. Een ander teken is een host die bereikbaar is vanaf de LAN maar niet vanaf het internet, of een die werkt tot de tunnel opnieuw verbindt en dan stopt. In elk geval gedroeg de heenweg zich netjes en de terugweg niet, wat wijst op routeringsasymmetrie en niet op beleid.

Bevestig het door te kijken waar het antwoord naartoe gaat, niet door te kijken hoe het verzoek binnenkomt.

Leg tegelijk vast op de fysieke interface en op het tunnelapparaat. Als het verzoek op de fysieke interface verschijnt en het antwoord op de tunnel, is de diagnose klaar. Een antwoord dat nergens verschijnt, betekent dat de dienst de verbinding nooit heeft geaccepteerd, wat een apart onderzoek met een aparte oorzaak is.

Twee standaardroutes en één routeringsbeslissing

Een client die een standaardroute installeert, voegt een tweede vermelding toe met een betere metriek dan de LAN-gateway. Sommige clients installeren in plaats daarvan twee halve-bereikroutes, die dezelfde ruimte specifieker dekken en de opzoeking op dezelfde manier winnen. Beide technieken laten gewone uitgaande pakketten de tunnelinterface kiezen.

Die keuze wordt alleen door de bestemming gemaakt. De kernel vraagt niet waar een pakket vandaan kwam, tenzij een beleidsregel hem dat opdraagt. Dus het antwoord naar een openbaar clientadres wordt aan de tunnel gegeven, wiens verre uiteinde een pakket ontvangt met een bronadres dat het niet bezit en het weggooit of ergens nutteloos doorstuurt. Op Linux kan strikte reverse-path-filtering ook het oorspronkelijke verzoek laten vallen voordat je dienst het ooit ziet, wat van buitenaf identiek lijkt. Beide symptomen komen van dezelfde ontbrekende associatie tussen een inkomende stroom en zijn antwoord.

De tunnel gedraagt zich de hele tijd correct. Hem is gezegd de standaardroute te dragen en dat doet hij precies.

Repareer de terugweg zonder de tunnel te breken

Er bestaan drie duurzame vormen van reparatie, en de keuze hangt ervan af hoeveel van het eigen verkeer van de host in de tunnel moet blijven. De bestemming of poort van de dienst uitsluiten is de kleinste wijziging. Policy-routing op basis van bron of markering is het meest precies. Bronvertaling is het grofst en het makkelijkst uit te leggen twee jaar later.

Kies op basis van wat de host moet doen, niet op basis van welk fragment je het eerst vond.

Een bestemming uitsluiten past bij een dienst met een stabiel openbaar adres, en de daemon aan het fysieke adres binden in plaats van aan elk adres maakt die uitsluiting veiliger. Een beleidsregel die een tabel op basis van de bron kiest, houdt de eigen verbindingen van de host in de tunnel terwijl hij de antwoorden van de dienst via de WAN-gateway terugstuurt. Antwoorden op de WAN-interface masqueraden bereikt dezelfde weg tegen de prijs dat het adres van de client uit de logs van de dienst verdwijnt. Een ad hoc-wijziging van de standaardroute is een diagnose en geen configuratie, omdat de client bij elke herverbinding de routes herschrijft.

ip rule show
ip route get 203.0.113.9 from 192.0.2.44

Wanneer de host ook routeert voor een LAN erachter

Een hop verder naar buiten komt dezelfde asymmetrie terug met meer bewegende delen. Verkeer bereikt de router vanaf het internet, wordt doorgestuurd naar een intern apparaat, en de enige weg terug van dat apparaat is de tunnel, dus het antwoord bereikt de oorspronkelijke client vanaf het adres van de provider zelf. Verbindingstracking treft dan een antwoord voor een stroom waarvan het begin niet is gezien, en gooit het weg. De client ziet ondertussen helemaal niets.

Twee wijzigingen repareren het: bestemmingsvertaling zodat de inkomende verbinding het interne apparaat bereikt, en bronvertaling zodat het antwoord van dat apparaat lijkt te komen van de router zelf.

Op routerfirmware is de gebruikelijke uitdrukking een beleidsregel die port-forwarding aan de WAN-kant vastzet terwijl het eigen verkeer van de router door de tunnel gaat. Zonder bronvertaling is dat antwoord gericht aan de externe client en heeft het interne apparaat er simpelweg geen route naartoe. Test drie dingen afzonderlijk, want ze mislukken om verschillende redenen: een verbinding die van buiten komt, een die de host zelf start, en een naamopzoeking.