OpenVPN: local tegenover het tunneladres, twee verschillende sockets

De client weigert te starten en klaagt dat hij geen lokaal adres kan binden, en de voor de hand liggende oplossing lijkt hem te wijzen naar het tunneladres dat hij verwacht te krijgen. Dat kan niet werken, en de reden is het begrijpen waard: voordat de tunnel bestaat is er geen binnenadres, en de socket die contact maakt met de server moet er eerst zijn. Er zijn twee verschillende adressen in het spel, en slechts één ervan kan lokaal worden gekozen.

De bindfout noemt een lokaal adres

Wanneer OpenVPN meldt dat het geen lokaal adres kan binden, heeft het over de transportsocket: het UDP- of TCP-eindpunt dat de versleutelde verbinding met de peer draagt.

Een expliciet local-directief vraagt de daemon om die socket aan een specifiek lokaal adres te binden. Het adres moet bestaan in de netwerknaamruimte waarin het proces draait, en het moet op het moment dat de client start toewijsbaar zijn.

Een openbaar adres dat op een router of aan een cloudrand wordt vertaald, is geen lokaal adres dat de daemon kan binden, ook al is het het adres dat de server ziet. Dat onderscheid verklaart waarom het ene profiel thuis werkt en op een cloudinstantie faalt. Het verklaart ook waarom het toevoegen van het openbare adres aan een loopback-interface niet helpt, omdat het transport dan zijn oorsprong zou nemen in een adres waar het netwerk niet naar terug kan routeren. Lees de interfacelijst voordat je het profiel aanpast.

Wat local en remote werkelijk selecteren

remote wijst de peer aan die moet worden benaderd. local bindt het nabije uiteinde van dezelfde socket. nobind laat het besturingssysteem zowel het lokale adres als de poort kiezen, waardoor clients achter thuisrouters normaal zonder een van beide directieven werken.

Geen van beide directieven heeft iets te maken met het adres binnen de tunnel.

In een container of een netwerknaamruimte geldt dezelfde regel met nauwere grenzen: de adressen van de host zijn binnen niet aanwezig, dus een uit de hostconfiguratie gekopieerde local-regel faalt om een heel andere reden dan een verkeerd adres zou doen.

ip -brief address show
ip route get 203.0.113.10

Het binnenadres komt van de server

Het adres binnen de tunnel wordt onderhandeld of toegewezen nadat het besturingskanaal tot stand is gebracht. Met een dynamische pool beslist de server erover op het moment van verbinden, en met cliëntspecifieke configuratie kan het per identiteit vastliggen.

Het schrijven van local met een binnenadres vraagt de server niet om dat adres toe te wijzen. In het beste geval mislukt de bind; in het slechtste geval vindt de client een ongerelateerd hostadres met dezelfde waarde en gaat hij dat voor het transport gebruiken.

De interfaces die je moet lezen zijn ook anders. ifconfig-parameters en poolconfiguratie beschrijven de binnenkant, terwijl remote, local, proto en nobind de buitenkant beschrijven. Die twee lijsten gescheiden houden verklaart bijna elk verwarrend voorbeeld dat je op een forum vindt. De handleiding van OpenVPN 2.6 documenteert ze daarom in aparte secties.

De valkuil: een volledige tunnel die zijn eigen transport opvangt

Zodra de tunnel actief is en de standaardroute draagt, mogen de pakketten die hem in stand houden niet in hem worden gerouteerd. Dat is een routeringsprobleem en geen adresseringsprobleem, en de daemon lost het op door een specifiekere route naar het eigen adres van de server via de oorspronkelijke gateway te installeren.

Als je het transport aan een specifiek lokaal adres vastpint en later het pad wijzigt dat dat adres gebruikt, kan de buitenste verbinding de weg kwijtraken terwijl de binnenkant geconfigureerd blijft. De tunnel blijft verbonden melden omdat de binnenkant in orde is. Alleen het transport is kapot, en daarom lezen de logboeken als tegenstrijdigheden.

Symptomen zien er dan uit als een tunnel die verbindt en bevriest, of een die in een lus opnieuw verbindt zonder nuttige fout. Controleer de route voor het adres van de peer voordat je iets binnen de tunnel controleert, en bevestig dat het lokale adres dat je bond nog steeds bij de interface hoort die je verwachtte.

Een gewoonte die de verwarring voorkomt

Lees elk adres in een profiel en bepaal bij welke laag het hoort voordat je het aanpast.

Als het het verre uiteinde van het transport benoemt of het nabije uiteinde ervan bindt, is het een buitenadres en moet het voor de start bestaan. Als het beschrijft wat er binnen de tunnel gebeurt, komt het van de server of van de topologie, en geen enkel lokaal directief kan dat vervangen.

Schrijf de twee lijsten in de implementatienotities naast het profiel. De volgende probleemoplossingssessie begint dan bij de laag in plaats van bij een gok.