OpenVPN: local kontra tunneladressen, to forskjellige sockets

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

Bind-feilen navngir en lokal adresse

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

Et 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 klienten starter.

En offentlig adresse som oversettes i en ruter eller på en skylkant er ikke en lokal adresse daemonen kan binde, selv om det er adressen serveren ser. Den forskjellen forklarer hvorfor én profil fungerer 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 hente kilden sin fra en adresse nettverket ikke kan rute tilbake til. Les grensesnittlisten før du redigerer profilen.

Hva local og remote faktisk velger

remote navngir peer-en som skal kontaktes. local binder den nære enden av samme socket. nobind lar operativsystemet velge både lokal adresse og port, og derfor fungerer klienter bak hjemmerutere normalt uten noen av de to direktivene.

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

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

ip -brief address show
ip route get 203.0.113.10

Innsideadressen kommer fra serveren

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

Å skrive local med en innsideadresse ber ikke serveren om å 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 man skal lese er også andre. ifconfig-parametere og poolkonfigurasjon beskriver innsiden, mens remote, local, proto og nobind beskriver utsiden. Å holde de to listene fra hverandre forklarer nesten hvert forvirrende eksempel du finner på et forum. Derfor dokumenterer OpenVPN 2.6-håndboken dem i egne avsnitt.

Fellen: en full tunnel som fanger sin egen transport

Når tunnelen er oppe og bærer standardruten, må pakkene som holder den oppe ikke rutes inn i den. Det er et ruteproblem og ikke et adresseringsproblem, og daemonen håndterer det ved å legge inn 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 miste retningen mens innsiden forblir konfigurert. Tunnelen fortsetter å melde tilkoblet fordi innsiden er i orden. Bare transporten er brutt, og derfor leses loggene som motsetninger.

Symptomene ser da ut som en tunnel som kobler til og fryser, eller en som kobler til på nytt i en løkke uten nyttig feil. Sjekk ruten til peer-ens 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 forhindrer 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 den en utsideadresse og må finnes før oppstart. Hvis den beskriver det som skjer inne i tunnelen, kommer den fra serveren eller fra topologien, og ingen lokal direktiv kan erstatte den.

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