OpenVPN: lokal adresse kontra tunneladressen: to forskellige sockets

Klienten nægter at starte og klager over, at den ikke kan binde en lokal adresse, og den oplagte løsning ser ud til at pege den mod den tunneladresse, den forventer at få. Det kan ikke virke, og grunden er værd at forstå: før tunnelen findes, er der ingen indre adresse, og den socket, der kontakter serveren, skal findes først. Der er to forskellige adresser involveret, og kun én af dem kan vælges lokalt.

Bind-fejlen nævner en lokal adresse

Når OpenVPN melder, at den ikke kan binde en lokal adresse, taler den om transportsocket: UDP- eller TCP-endpunktet, der bærer den krypterede forbindelse til peer’en.

En eksplicit local-direktiv beder daemonen om at binde den socket til en bestemt lokal adresse. Adressen skal findes i det netværksnavnerum, hvor processen kører, og den skal kunne tildeles i det øjeblik, klienten starter.

En offentlig adresse, der oversættes på en router eller i cloudkanten, er ikke en lokal adresse, som daemonen kan binde, selvom det er den adresse, serveren ser. Den forskel forklarer, hvorfor én profil virker derhjemme og fejler på en cloud-instans. Den forklarer også, hvorfor det ikke hjælper at tilføje den offentlige adresse til en loopback-grænseflade, da transporten så ville komme fra en adresse, som netværket ikke kan svare tilbage til. Læs grænsefladelisten, før du redigerer profilen.

Hvad local og remote egentlig vælger

remote navngiver den peer, der skal kontaktes. local binder den nære ende af samme socket. nobind lader styresystemet vælge både den lokale adresse og porten, og derfor virker klienter bag hjemmeroutere normalt uden nogen af de to direktiver.

Ingen af direktiverne har noget med adressen inde i tunnelen at gøre.

I en container eller et netværksnavnerum gælder samme regel med snævrere grænser: værtens adresser findes ikke indeni, så en local-linje kopieret fra værtens konfiguration fejler af en helt anden grund end en forkert adresse.

ip -brief address show
ip route get 203.0.113.10

Den indre adresse kommer fra serveren

Adressen inde i tunnelen forhandles eller tildeles, efter at kontrolkanalen er etableret. Med en dynamisk pool beslutter serveren det ved forbindelsen, og med klientspecifik konfiguration kan den være fast per identitet.

At skrive local med en indre adresse beder ikke serveren om at tildele den adresse. I bedste fald fejler bindingen; i værste fald finder klienten en urelateret værtsadresse med samme værdi og begynder at bruge den til transporten.

De grænseflader, der skal læses, er også forskellige. ifconfig-parametre og poolkonfiguration beskriver det indre, mens remote, local, proto og nobind beskriver det ydre. At holde de to lister adskilt forklarer næsten hvert forvirrende eksempel, du finder på et forum. OpenVPN 2.6-manualen dokumenterer dem i adskilte afsnit af netop den grund.

Fælden: en fuld tunnel, der fanger sin egen transport

Når tunnelen er oppe og bærer standardruten, må de pakker, der holder den i gang, ikke routes ind i den. Det er et routingproblem snarere end et adresseringsproblem, og daemonen klarer det ved at installere en mere specifik rute til serverens egen adresse gennem den oprindelige gateway.

Hvis du fastgør transporten til en bestemt lokal adresse og senere ændrer den vej, adressen bruger, kan den ydre forbindelse fare vild, mens det indre forbliver konfigureret. Tunnelen fortsætter med at rapportere forbundet, fordi det indre er i orden. Kun transporten er brudt, og derfor læses loggene som modsigelser.

Symptomerne ser så ud som en tunnel, der forbinder og fryser, eller en, der genopretter forbindelse i en løkke uden en brugbar fejl. Kontroller ruten til peer’ens adresse, før du kontrollerer noget inde i tunnelen, og bekræft, at den lokale adresse, du bandt, stadig hører til den grænseflade, du forventede.

En vane, der forebygger forvirringen

Læs hver adresse i en profil, og afgør, hvilket lag den hører til, før du redigerer den.

Hvis den navngiver den fjerne ende af transporten eller binder den nære ende af den, er det en ydre adresse og skal findes før opstart. Hvis den beskriver, hvad der sker inde i tunnelen, kommer den fra serveren eller fra topologien, og ingen lokal direktiv kan erstatte den.

Skriv de to lister i udrulningsnoterne ved siden af profilen. Den næste fejlfindingssession starter så med laget i stedet for med et gæt.