Varför din Docker VPN-portmappning aldrig når OpenVPN

Din container kan lyssna på UDP 1195 medan värden publicerar 1194, och det är korrekt så länge mappningen säger det. Numren bildar en översättningstabell: klienten ringer värdporten, Docker skriver om målet till containerporten och OpenVPN svarar på den port som dess egen konfiguration anger. En avvikelse i någon av dessa länkar ger ett tyst fel som ser ut som en brandvägg. Certifikat och chiffer ligger nedströms och kan inte reparera det.

Följ ett paket från klient till process innan du ändrar något i autentiseringen.

Tre nummer, en anslutning

De tre numren är det fjärrmål klienten använder, den publicerade mappningen på värden och lyssnaren inne i containern. De behöver inte vara lika, men de måste bilda en kedja. Lika nummer är ett specialfall som råkar vara det vanligaste, därför är en avvikelse lätt att skriva en gång och svår att se senare.

Skriv ned kedjan på en rad före felsökning: klientadress och -port, värdmappning, containerlyssnare, transport. Ett fel i kedjan visar sig som ett nummer som dyker upp två gånger med olika värden.

Vad den korta syntaxen faktiskt säger

I kortformen är vänster sida värdporten och höger sida containerporten, och ett snedstreckssuffix väljer transporten. Utelämnar du suffixet behandlar Docker mappningen som TCP, så en UDP-lyssnare bakom en mappning utan protokoll är en lyssnare som ingen kan nå. Den standarden är dokumenterad och överraskar fortfarande folk som fick numren att stämma och kallade det klart.

Långformen låser bindadress och protokoll explicit, vilket är värt extraraderna på allt som vetter mot ett nätverk. Läs tillbaka den publicerade mappningen i stället för att lita på filen som skapade den.

ports:
  - 1194:1195/udp

Var paketet kan stanna

En begäran kan släppas före Docker, i Docker eller hos lyssnaren. Före Docker kan det finnas en molnbrandvägg eller en router som gör sin egen vidarebefordran, och den enheten behöver värdporten och rätt transport. Inne i Docker vidarebefordrar en mappning till fel containerport till en stängd socket.

Sedan lyssnaren: OpenVPN-konfigurationen anger en port och ett protokoll, och en klient som anländer på en annan inne i containern når ingenting. TCP-test av en UDP-tjänst bevisar ingenting i något av dessa steg, så använd den transport klienten kommer att använda.

Bindadresser avgör nåbarhet

En publicerad mappning bunden till loopback är bara nåbar från värden, medan en bunden till alla gränssnitt är nåbar där brandväggen tillåter det. De två ser identiska ut i en Compose-fil som utelämnar adressen, och Dockers standard är den breda.

Bestäm vilken exponering driftsättningen avser och skriv sedan ut den explicit. Ett internt test som ansluter via loopback och en fjärrklient som inte kan ansluta kan båda vara korrekta beskrivningar av samma container.

Läs det körande tillståndet

Inspektera den körande containerns faktiska mappning och lyssnaren i dess nätverksnamnrymd. En Compose-fil kan ha redigerats efter att containern startade, bildmetadata kan deklarera en port utan att publicera den, och en andra container kan redan hålla värdporten. Att deklarera en port i en bild är inte samma sak som att publicera den, och inget av dem är samma sak som att lyssna.

Tre olika tillstånd, tre olika kommandon, och bara det sista involverar OpenVPN.

När mappningen är rätt

När paketet når OpenVPN är dess logg platsen där man läser om TLS och autentisering. Att generera om certifikat för att laga ett paket som aldrig kom är bortkastat arbete som lägger till en andra variabel. Håll mappningsanteckningen bredvid klientprofilen så att nästa person läser en rad i stället för att återupptäcka alla tre numren. En paketfångst på värdsidan avgör vilken av de tre länkarna som är fel, och det kostar mindre än en certifikatförnyelse.

Publicering över brygga är fallet som beskrivs här. Värdnätverk och routade containeradresser hoppar över översättningen, så samma nummer betyder något annat i de designerna.