Waarom is het subnet achter een OpenVPN-client onbereikbaar?

Pings naar het tunneladres van de server slagen, de eigen routetabel van de client ziet er goed uit, en het LAN achter die client blijft onbereikbaar. De routetabel van de client ziet er correct uit, de server heeft een route naar de tunnel, en pakketten verdwijnen nog steeds. Dit is het klassieke symptoom van een layer-3-tunnel die niet weet dat een van zijn clients ook een gateway is.

Een tun-interface heeft geen next hop per client. De kernel ziet één interface met veel peers, dus de beslissing welke client een pakket voor een extern LAN moet ontvangen, moet binnen het OpenVPN-proces worden genomen. Die beslissing wordt met iroute geconfigureerd, en zonder die regel heeft het pakket nergens heen te gaan.

De server routeert per client, niet per interface

Wanneer de server een pakket naar het tunneladres van een client moet sturen, is het antwoord ondubbelzinnig: het adres hoort bij de sessie van die client. Wanneer de bestemming een heel subnet achter die client is, hoort het adres bij niemand die de server kent, en de kernelroute naar de tunnel zegt alleen "via deze interface", zonder te zeggen welke peer.

OpenVPN lost dit op met een interne routetabel die een bestemmingsprefix aan een specifieke client koppelt. Die tabel wordt uit iroute-regels opgebouwd, daarom is een gewone route op de serverhost niet genoeg. De kernelroute brengt het pakket naar de tunnelinterface; de interne koppeling bepaalt welke sessie het ontvangt. Daarom verschijnt de reparatie nooit in de route-uitvoer van de kernel.

Ontbreekt de koppeling, dan komt het pakket bij de server aan, past bij de tunnelroute en wordt weggegooid omdat geen enkele client de bestemming opeist. Niets logt een nette fout, daarom lijkt de storing op een stil zwart gat in plaats van een routeringslus.

De iroute-regel schrijven die de client benoemt

iroute staat in een clientspecifiek configuratiebestand, niet in de hoofdconfiguratie van de server. Wijs de server met de optie client-config-dir naar een map, maak vervolgens een bestand waarvan de naam de common name van het clientcertificaat is en zet de prefix erin.

Voor een filiaal waarvan het LAN 10.20.0.0/24 is en waarvan de certificaat-common name branch-router is, bevat het bestand op dat pad een regel zoals iroute 10.20.0.0 255.255.255.0. De hoofdconfiguratie heeft alleen de mapoptie nodig; de prefix staat bij de client.

De common name is het kwetsbare deel. Een certificaat dat met een ander subject is uitgegeven, of een uitrol die gebruikers op gebruikersnaam authenticeert terwijl het bestand naar het certificaat is vernoemd, levert een bestand op dat nooit wordt gelezen. Controleer de naam die de server werkelijk voor de sessie rapporteert, en overweeg de optie die een niet-passende client laat falen in plaats van stilzwijgend zonder zijn routes te verbinden. Het bestand hernoemen zodat het bij het certificaat past is een correctie van vijf minuten die een zeer lange avond voorkomt.

Eén client kan meerdere prefixen bezitten. Voeg één iroute-regel per netwerk toe en houd de lijst naast de overige instellingen van die client, zodat de koppeling controleerbaar blijft.

Het retourpad in beide richtingen opbouwen

Pakketten naar het externe LAN brengen is het halve werk. De client moet ook het verkeer van dat LAN de tunnel in sturen, wat meestal gebeurt door een route naar de client te pushen: een regel zoals push "route 10.8.0.0 255.255.255.0" vertelt elke client hoe hij het netwerk aan de serverkant bereikt. Voor het filiaal wijst de equivalente route naar de tunnel voor alles wat het aan de serverkant moet bereiken.

De retourrichting heeft een eigenaar aan de andere kant nodig. Daar moet iemand de weg terug kennen: een statische route op de LAN-router die de VPN-pool naar de server wijst, of adresvertaling op de server voordat het verkeer het LAN binnenkomt. De statische route houdt de oorspronkelijke adressen zichtbaar in logs en toegangsregels, maar vereist de medewerking van de LAN-eigenaar; vertaling is zelfvoorzienend, maar verbergt wie daadwerkelijk verbinding maakte.

Doorsturen moet zijn ingeschakeld op de serverhost. Zonder dat accepteert de kernel het pakket van de tunnel en weigert het naar de LAN-interface door te geven, wat vanuit het perspectief van de client identiek lijkt aan een ontbrekende iroute.

Bereikbaarheid controleren met de juiste probes

Test in lagen in plaats van het verre uiteinde te pingen en te gissen. Controleer vanaf de server dat de interne koppeling voor de prefix bestaat en dat de kernelroute naar de tunnel wijst. Bevestig vanaf de client dat de gepushte route is geïnstalleerd en dat zijn standaardpad naar het LAN-adres de tunnel is.

Kijk dan naar de pakketten. Een capture op de tunnelinterface laat zien of de server richting de client uitzendt, en een capture op de LAN-interface laat zien of hij doorstuurt. Als de eerste pakketten toont en de tweede niets, is doorsturen of een filter het probleem; als geen van beide iets toont, is de opzoeking eerder mislukt.

Twee servers die met een tunnel zijn verbonden, herhalen dezelfde regel aan beide kanten: elk heeft een iroute voor de pool van de ander nodig, en elk heeft de route en het doorsturen nodig die het pad symmetrisch maken. Routering en beleid zijn hier gescheiden zaken. Routering bepaalt waar een pakket heen kan, terwijl een FORWARD-regel bepaalt of het mag, dus een client met twee iroute-regels bereikt beide prefixen, tenzij een filter anders zegt.