OpenVPN iroute of kernelroute: welke ontbreekt?

Een pakket voor 10.77.20.0/24 neemt twee afzonderlijke beslissingen op een OpenVPN-server: het besturingssysteem moet het aan de VPN-interface afgeven, en OpenVPN moet weten welke verbonden client dat prefix bezit. Een ontbrekende kernelroute laat het vóór de tunnel vallen, een ontbrekende peerroute daarna. De twee fouten zien er vanaf het externe LAN identiek uit, en om te diagnosticeren welke je hebt is één commando aan elke kant nodig.

In het klassieke datapad in de gebruikersruimte brengt de kernelroute het pakket in het tunnelproces, en iroute vertelt dat proces welke peer het moet ontvangen. Geen van beide vervangt de ander, en een configuratie met slechts één ervan ziet er redelijk uit tot de eerste ping.

Twee beslissingen, niet één route

Stel je een verbinding tussen locaties voor waarbij 10.77.20.0/24 achter één client ligt. De kernelroute van de server, bijvoorbeeld ip route add 10.77.20.0/24 dev tun0, stuurt overeenkomende pakketten naar het tunnelapparaat. Daarna raadpleegt OpenVPN zijn eigen interne tabel, opgebouwd uit iroute-regels in de configuratiemap van de client, om te bepalen welke peerverbinding ze ontvangt. Zonder de kernelroute bereikt het pakket het proces nooit, en zonder de peerroute bereikt het het proces en gaat het nergens heen.

Die splitsing is makkelijk te vergeten, omdat één routelijn in een clientprofiel kan lijken of die beide taken doet. Dat doet die niet: een route pushen vertelt clients wat ze door de tunnel moeten sturen, terwijl iroute de server vertelt wie een adresbereik achter een client bezit. Ze leven in verschillende bestanden, worden door verschillende kanten gelezen en falen in tegengestelde richtingen.

Waar iroute hoort en wat het zegt

De regel hoort in een bestand per client, genoemd naar de common_name van de client, onder client-config-dir, als iroute 10.77.20.0/24. De bestandsnaam moet exact kloppen: OpenVPN zoekt de geauthenticeerde identiteit op en leest het bestand met precies die naam, dus een bestand met de naam site-a werkt alleen voor een client waarvan de common name site-a is. Voeg ccd-exclusive toe als clients zonder zo’n bestand helemaal geweigerd moeten worden, wat de juiste instelling is wanneer elke client een sitegateway is. Houd één bestand per gateway aan en noem het naar het certificaatsubject dat je werkelijk uitgeeft.

Test de regel vanaf de server voordat je het externe LAN de schuld geeft. Het statusbestand vermeldt verbonden clients met hun common names, en een server die met --verb 4 draait, logt het installeren van iroute op het moment dat de peer verbindt. Verschijnt er niets bij het verbinden, dan staat het bestand in de verkeerde map of noemt het de verkeerde identiteit.

De val: bestand aanwezig, verkeerde identiteit

Een iroute die er correct uitziet maar aan de verkeerde peer hangt, kost meer tijd dan een ontbrekend bestand, omdat alles op schijf juist lijkt. Het hernoemen van certificaten, dubbele common names en username-as-common-name dat de effectieve identiteit verandert, veroorzaken het allemaal. Controleer welke identiteit de server authenticeerde in plaats van welke je verwachtte: de statusuitvoer is gezaghebbend, terwijl de bestandsnaam alleen een zoeksleutel is.

Een route kan zijn eigenaar overleven. Statische routes en iroute-regels beschrijven een prefix, geen beschikbaarheidsgarantie, dus verkeer kan naar een peer blijven worden gerouteerd die op dit moment is losgekoppeld.

Voltooi het pad voorbij de peer

Peer-eigendom is het midden van het pad, niet het einde. De client moet pakketten van de tunnel naar zijn eigen LAN doorsturen, wat betekent dat IP-doorgifte op die host aan staat en een firewallregel de doorgang toestaat. Hosts op het externe LAN hebben een terugweg nodig voor het tunneladres: ofwel een route die terugwijst naar de gateway, ofwel een bewust NAT-ontwerp aan de clientzijde. Bevestig de doorgifte-instelling op de client met sysctl net.ipv4.ip_forward in plaats van een distributiestandaard aan te nemen.

Als andere VPN-clients dat subnet moeten bereiken, groeit de opzet opnieuw: de server heeft client-to-client nodig, en die clients moeten het prefix via de tunnel routeren. Niets daarvan volgt uit de eigen routetabel van de server.

Verifieer één bestemming vanaf een echte bron in plaats van vanaf de server zelf. Een ping van een onbetrokken LAN-host naar een host achter de client beproeft de terugweg, de doorgifteregel en het peer-eigendom in één beweging, terwijl een geslaagde handshake alleen identiteit bewijst. Koppel daarna de bezittende peer los en noteer wat de route doet, want dat antwoord is je faalmodus.