OpenVPN: local kontra tunneladressen, två olika sockets

Klienten vägrar starta och klagar på att den inte kan binda en lokal adress, och den uppenbara rättelsen ser ut som att peka den mot den tunneladress den förväntar sig att få. Det kan inte fungera, och skälet är värt att förstå: innan tunneln finns finns ingen inre adress, och socketen som kontaktar servern måste finnas först. Två olika adresser är inblandade, och bara en av dem kan väljas lokalt.

Bind-felet namnger en lokal adress

När OpenVPN rapporterar att det inte kan binda en lokal adress talar det om transportsocketen: UDP- eller TCP-slutpunkten som bär den krypterade anslutningen till peeren.

Ett explicit local-direktiv ber daemonen binda den socketen till en specifik lokal adress. Adressen måste finnas i det nätverksnamnrymme där processen körs, och den måste kunna tilldelas i det ögonblick klienten startar.

En offentlig adress som översätts i en router eller vid en molnkant är inte en lokal adress som daemonen kan binda, även om det är adressen servern ser. Den skillnaden förklarar varför en profil fungerar hemma och misslyckas på en molninstans. Den förklarar också varför det inte hjälper att lägga den offentliga adressen på ett loopback-gränssnitt, eftersom transporten då skulle hämta sin källa från en adress som nätverket inte kan routa tillbaka till. Läs gränssnittslistan innan du redigerar profilen.

Vad local och remote faktiskt väljer

remote namnger peeren att kontakta. local binder den nära änden av samma socket. nobind låter operativsystemet välja både lokal adress och port, vilket är varför klienter bakom hemmaroutrar normalt fungerar utan något av de två direktiven.

Inget av direktiven har något med adressen inne i tunneln att göra.

I en container eller ett nätverksnamnrymme gäller samma regel med snävare gränser: värdens adresser finns inte på insidan, så en local-rad kopierad från värdkonfigurationen misslyckas av en helt annan orsak än en felaktig adress skulle göra.

ip -brief address show
ip route get 203.0.113.10

Den inre adressen kommer från servern

Adressen inne i tunneln förhandlas eller tilldelas efter att kontrollkanalen har upprättats. Med en dynamisk pool bestämmer servern den vid anslutningen, och med klientspecifik konfiguration kan den vara fast per identitet.

Att skriva local med en inre adress ber inte servern tilldela den adressen. I bästa fall misslyckas bindningen; i värsta fall hittar klienten en orelaterad värdadress med samma värde och börjar använda den för transporten.

Gränssnitten man ska läsa är också andra. Parametrar för ifconfig och poolkonfiguration beskriver insidan, medan remote, local, proto och nobind beskriver utsidan. Att hålla de två listorna åtskilda förklarar nästan varje förvirrande exempel du hittar på ett forum. Därför dokumenterar OpenVPN 2.6-handboken dem i separata avsnitt.

Fällan: en full tunnel som fångar sin egen transport

När tunneln är uppe och bär standardrutten får paketen som håller den vid liv inte routas in i den. Det är ett routingproblem och inte ett adresseringsproblem, och daemonen hanterar det genom att installera en mer specifik rutt till serverns egen adress via den ursprungliga gatewayen.

Om du fäster transporten vid en specifik lokal adress och senare ändrar den väg adressen använder kan den yttre anslutningen tappa riktningen medan insidan förblir konfigurerad. Tunneln fortsätter rapportera ansluten eftersom insidan är i ordning. Bara transporten är trasig, och därför läses loggarna som motsägelser.

Symtomen ser då ut som en tunnel som ansluter och fryser, eller en som återansluter i en loop utan användbart fel. Kontrollera rutten till peerens adress innan du kontrollerar något inne i tunneln, och bekräfta att den lokala adress du band fortfarande tillhör det gränssnitt du förväntade dig.

En vana som förebygger förvirringen

Läs varje adress i en profil och avgör vilket lager den tillhör innan du redigerar den.

Om den namnger transportens bortre ände eller binder dess nära ände är den en yttre adress och måste finnas före start. Om den beskriver vad som händer inne i tunneln kommer den från servern eller från topologin, och inget lokalt direktiv kan ersätta den.

Skriv de två listorna i driftsättningsanteckningarna bredvid profilen. Nästa felsökningspass börjar då med lagret i stället för med en gissning.