Hvorfor Docker VPN-portmappingen din aldri når OpenVPN

Containeren din kan lytte på UDP 1195 mens verten publiserer 1194, og det er riktig så lenge mappingen sier det. Tallene utgjør en oversettelsestabell: klienten ringer vertsporten, Docker skriver om målet til containerporten, og OpenVPN svarer på porten som dens egen konfigurasjon angir. Avvik i en av disse lenkene gir en stille feil som ser ut som en brannmur. Sertifikater og chiffere ligger nedstrøms og kan ikke reparere det.

Følg én pakke fra klient til prosess før du endrer noe ved autentiseringen.

Tre tall, én forbindelse

De tre tallene er det eksterne målet klienten bruker, den publiserte mappingen på verten og lytteren inne i containeren. De trenger ikke være like, men de må danne en kjede. Like tall er et spesialtilfelle som tilfeldigvis er det vanligste, og derfor er avvik lett å skrive én gang og vanskelig å se senere.

Skriv ned kjeden på én linje før feilsøking: klientadresse og -port, vertsmapping, containerlytter, transport. En feil i kjeden viser seg som et tall som dukker opp to ganger med ulike verdier.

Hva den korte syntaksen faktisk sier

I kortformen er venstre side vertsporten og høyre side containerporten, og et skråstrek-suffiks velger transporten. Utelater du suffikset, behandler Docker mappingen som TCP, så en UDP-lytter bak en mapping uten protokoll er en lytter ingen kan nå. Den standarden er dokumentert og overrasker fortsatt folk som fikk tallene til å stemme og kalte det ferdig.

Langformen låser bindeadresse og protokoll eksplisitt, noe som er verdt ekstralinjene på alt som vender mot et nettverk. Les den publiserte mappingen tilbake i stedet for å stole på filen som lagde den.

ports:
  - 1194:1195/udp

Hvor pakken kan stoppe

En forespørsel kan bli droppet før Docker, i Docker eller hos lytteren. Foran Docker kan det være en skybrannmur eller en ruter som gjør sin egen videresending, og den enheten trenger vertsporten og riktig transport. Inne i Docker videresender en mapping til feil containerport til en lukket socket.

Så lytteren: OpenVPN-konfigurasjonen angir en port og en protokoll, og en klient som ankommer en annen inne i containeren når ingenting. TCP-testing av en UDP-tjeneste beviser ingenting på noen av disse trinnene, så bruk transporten klienten kommer til å bruke.

Bindeadresser avgjør tilgjengelighet

En publisert mapping bundet til loopback er bare tilgjengelig fra verten, mens en bundet til alle grensesnitt er tilgjengelig der brannmuren tillater det. De to ser identiske ut i en Compose-fil som utelater adressen, og Docker-standarden er den brede.

Bestem hvilken eksponering utrullingen er ment å ha, og skriv den så eksplisitt. En intern test som kobler til over loopback, og en fjernklient som ikke får koblet til, kan begge være nøyaktige beskrivelser av samme container.

Les den kjørende tilstanden

Undersøk den kjørende containerens faktiske mapping og lytteren i nettverksnavnerommet. En Compose-fil kan ha blitt redigert etter at containeren startet, bildemetadata kan erklære en port uten å publisere den, og en andre container kan allerede holde vertsporten. Å erklære en port i et bilde er ikke å publisere den, og ingen av delene er det samme som å lytte.

Tre forskjellige tilstander, tre forskjellige kommandoer, og bare den siste involverer OpenVPN.

Når mappingen er riktig

Når pakken når OpenVPN, er loggen stedet å lese om TLS og autentisering. Å generere sertifikater på nytt for å rette en pakke som aldri kom, er bortkastet arbeid som legger til en andre variabel. Hold mappingnotatet ved klientprofilen slik at neste person leser én linje i stedet for å gjenoppdage alle tre tallene. Én pakkefangst på vertssiden avgjør hvilken av de tre lenkene som er feil, og det koster mindre enn en sertifikatfornyelse.

Publisering over bro er tilfellet som beskrives her. Vertsnettverk og rutede containeradresser hopper over oversettelsen, så de samme tallene betyr noe annet i de designene.