Hvorfor din Docker VPN-portmapping aldrig når OpenVPN

Din container kan lytte på UDP 1195, mens værten udgiver 1194, og det er korrekt, så længe mappingen siger det. Tallene udgør en oversættelsestabel: klienten ringer til værtsporten, Docker omskriver destinationen til containerporten, og OpenVPN svarer på den port, som dets egen konfiguration angiver. Uoverensstemmelse i et af disse led giver en tavs fejl, der ligner en firewall. Certifikater og ciphers ligger nedstrøms og kan ikke reparere det.

Følg én pakke fra klient til proces, før du ændrer noget ved godkendelsen.

Tre tal, én forbindelse

De tre tal er den fjerne destination, klienten bruger, den udgivne mapping på værten og lytteren inde i containeren. De behøver ikke være ens, men de skal danne en kæde. Ens tal er et særtilfælde, som tilfældigvis er det almindelige, og derfor er en uoverensstemmelse let at skrive én gang og svær at se senere.

Skriv kæden ned på én linje før fejlfinding: klientadresse og -port, værtsmapping, containerlytter, transport. En fejl i kæden viser sig som et tal, der optræder to gange med forskellige værdier.

Hvad den korte syntaks faktisk siger

I den korte form er venstre side værtsporten og højre side containerporten, og et skråstregs-suffiks vælger transporten. Udelader du suffikset, behandler Docker mappingen som TCP, så en UDP-lytter bag en mapping uden protokol er en lytter, som ingen kan nå. Den standard er dokumenteret og overrasker stadig folk, der har fået tallene til at passe og kaldt det færdigt.

Den lange form fastlåser bindeadresse og protokol eksplicit, hvilket er de ekstra linjer værd på alt, der vender mod et netværk. Læs den udgivne mapping tilbage i stedet for at stole på den fil, der skabte den.

ports:
  - 1194:1195/udp

Hvor pakken kan stoppe

En anmodning kan blive droppet før Docker, i Docker eller ved lytteren. Foran Docker kan der være en cloud-firewall eller en router, der videresender selv, og den enhed skal have værtsporten og den rigtige transport. Inde i Docker videresender en mapping til den forkerte containerport til en lukket socket.

Så lytteren: OpenVPNs konfiguration angiver en port og en protokol, og en klient, der ankommer på en anden inde i containeren, når ingenting. TCP-test af en UDP-tjeneste beviser intet på nogen af disse trin, så brug den transport, klienten vil bruge.

Bindeadresser afgør tilgængelighed

En udgivet mapping bundet til loopback er kun tilgængelig fra værten, mens en bundet til alle grænseflader er tilgængelig, hvor firewalling tillader det. De to ser identiske ud i en Compose-fil, der udelader adressen, og Docks standard er den brede.

Beslut, hvilken eksponering udrulningen sigter mod, og skriv den så eksplicit. En intern test, der forbinder via loopback, og en fjernklient, der ikke kan forbinde, kan begge være præcise beskrivelser af den samme container.

Læs den kørende tilstand

Undersøg den kørende containers effektive mapping og lytteren i dens netværksnavnerum. En Compose-fil kan være redigeret, efter containeren startede, image-metadata kan erklære en port uden at udgive den, og en anden container kan allerede holde værtsporten. At erklære en port i et image er ikke at udgive den, og ingen af delene er det samme som at lytte.

Tre forskellige tilstande, tre forskellige kommandoer, og kun den sidste involverer OpenVPN.

Når mappingen er rigtig

Når pakken når OpenVPN, er dets log stedet at læse om TLS og godkendelse. At regenerere certifikater for at rette en pakke, der aldrig ankom, er spildt arbejde, der tilføjer en anden variabel. Hold mappingnoten ved klientprofilen, så den næste person læser én linje i stedet for at genopdage alle tre tal. Én pakkefangst på værtsiden afgør, hvilket af de tre led der er forkert, og den koster mindre end en certifikatfornyelse.

Udgivelse via bro er det tilfælde, der beskrives her. Værtsnetværk og rutede containeradresser springer oversættelsen over, så de samme tal betyder noget andet i de designs.