OpenVPN: den lokale adressen mot tunneladressen – to forskjellige sockets

Klienten nekter å starte og klager over at den ikke kan binde en lokal adresse, og den åpenbare løsningen ser ut som å peke den mot tunneladressen den forventer å få. Det kan ikke virke, og grunnen er verdt å forstå: før tunnelen finnes, er det ingen indre adresse, og socketen som kontakter serveren, må finnes først. Det er to forskjellige adresser involvert, og bare én av dem kan velges lokalt.

Bind-feilen nevner en lokal adresse

Når OpenVPN melder at den ikke kan binde en lokal adresse, snakker den om transportsocketen: UDP- eller TCP-endepunktet som bærer den krypterte forbindelsen til peeren.

En eksplisitt local-direktiv ber daemonen binde den socketen til en bestemt lokal adresse. Adressen må finnes i nettverksnavnerommet der prosessen kjører, og den må kunne tildeles i det øyeblikket klienten starter.

En offentlig adresse oversatt i en ruter eller i skykanten er ikke en lokal adresse daemonen kan binde, selv om det er adressen serveren ser. Den forskjellen forklarer hvorfor én profil virker hjemme og feiler på en skyinstans. Den forklarer også hvorfor det ikke hjelper å legge den offentlige adressen til et loopback-grensesnitt, siden transporten da ville gå ut fra en adresse nettverket ikke kan svare på. Les grensesnittlisten før du redigerer profilen.

Hva local og remote egentlig velger

remote navngir peeren som skal kontaktes. local binder den nære enden av samme socket. nobind lar operativsystemet velge både den lokale adressen og porten, og derfor virker klienter bak hjemmerutere vanligvis uten noen av de to direktivene.

Ingen av direktivene har noe med adressen inne i tunnelen å gjøre.

I en container eller et nettverksnavnerom gjelder samme regel med snevrere grenser: vertens adresser finnes ikke inni, så en local-linje kopiert fra vertskonfigurasjonen feiler av en helt annen grunn enn en feil adresse.

ip -brief address show
ip route get 203.0.113.10

Den indre adressen kommer fra serveren

Adressen inne i tunnelen forhandles eller tildeles etter at kontrollkanalen er etablert. Med et dynamisk basseng bestemmer serveren den ved tilkobling, og med klientspesifikk konfigurasjon kan den være fast per identitet.

Å skrive local med en indre adresse ber ikke serveren tildele den adressen. I beste fall feiler bindingen; i verste fall finner klienten en urelatert vertsadresse med samme verdi og begynner å bruke den til transporten.

Grensesnittene som skal leses, er også forskjellige. ifconfig-parametere og bassengkonfigurasjon beskriver det indre, mens remote, local, proto og nobind beskriver det ytre. Å holde de to listene atskilt forklarer nesten hvert forvirrende eksempel du finner på et forum. OpenVPN 2.6-håndboken dokumenterer dem i egne avsnitt av nettopp den grunnen.

Fellen: en full tunnel som fanger sin egen transport

Når tunnelen er oppe og bærer standardruten, må pakkene som holder den i gang, ikke rutes inn i den. Det er et ruteproblem og ikke et adresseproblem, og daemonen håndterer det ved å installere en mer spesifikk rute til serverens egen adresse gjennom den opprinnelige gatewayen.

Hvis du fester transporten til en bestemt lokal adresse og senere endrer veien den adressen bruker, kan den ytre forbindelsen gå seg vill mens det indre forblir konfigurert. Tunnelen fortsetter å rapportere at den er tilkoblet fordi det indre er i orden. Bare transporten er ødelagt, og derfor leses loggene som motsigelser.

Symptomene ser da ut som en tunnel som kobler til og fryser, eller en som kobler til på nytt i en løkke uten en nyttig feil. Sjekk ruten til peerens adresse før du sjekker noe inne i tunnelen, og bekreft at den lokale adressen du bandt, fortsatt tilhører grensesnittet du forventet.

En vane som forebygger forvirringen

Les hver adresse i en profil og avgjør hvilket lag den tilhører før du redigerer den.

Hvis den navngir den fjerne enden av transporten eller binder den nære enden av den, er det en ytre adresse, og den må finnes før oppstart. Hvis den beskriver hva som skjer inne i tunnelen, kommer den fra serveren eller fra topologien, og ingen lokal direktiv kan erstatte den.

Skriv de to listene i distribusjonsnotatene ved siden av profilen. Den neste feilsøkingsøkten begynner da med laget i stedet for med en gjetning.