Proč se mapování portů VPN v Dockeru nikdy nedostane do OpenVPN

Váš kontejner může naslouchat na UDP 1195, zatímco hostitel zveřejňuje 1194, a je to správně, pokud to mapování říká. Čísla tvoří překladovou tabulku: klient vytáčí port hostitele, Docker přepisuje cíl na port kontejneru a OpenVPN odpovídá na portu, který udává jeho vlastní konfigurace. Nesoulad v kterémkoli z těchto článků vyvolá tichou poruchu, která vypadá jako firewall. Certifikáty a šifry jsou až za tím a nemohou to napravit.

Projděte jeden paket od klienta k procesu, než změníte cokoli v autentizaci.

Tři čísla, jedno spojení

Tři čísla jsou vzdálený cíl, který klient používá, zveřejněné mapování na hostiteli a naslouchač uvnitř kontejneru. Nemusejí být stejná, ale musí tvořit řetěz. Stejná čísla jsou zvláštní případ, který je náhodou nejběžnější, a proto se nesoulad snadno jednou napíše a těžko se později vidí.

Zapište řetěz na jeden řádek před laděním: adresa a port klienta, mapování hostitele, naslouchač kontejneru, transport. Závada v řetězu se projeví jako číslo, které se objeví dvakrát s různými hodnotami.

Co krátká syntaxe skutečně říká

V krátké formě je levá strana port hostitele a pravá port kontejneru a přípona s lomítkem volí transport. Vynechejte příponu a Docker mapování považuje za TCP, takže naslouchač UDP za mapováním bez protokolu je naslouchač, ke kterému se nikdo nedostane. Toto výchozí chování je zdokumentované a stále překvapuje lidi, kteří čísla srovnali a považovali věc za hotovou.

Dlouhá forma výslovně fixuje adresu navázání a protokol, což stojí za řádky navíc u všeho vystaveného síti. Přečtěte si zveřejněné mapování zpět, místo abyste věřili souboru, který ho vytvořil.

ports:
  - 1194:1195/udp

Kde se paket může zastavit

Požadavek může být zahozen před Dockerem, v Dockeru nebo u naslouchače. Před Dockerem může být cloudový firewall nebo router s vlastním přesměrováním a to zařízení potřebuje port obrácený k hostiteli a správný transport. Uvnitř Dockeru mapování na špatný port kontejneru přesměruje na zavřený socket.

Pak naslouchač: konfigurace OpenVPN uvádí port a protokol a klient, který uvnitř kontejneru dorazí na jiný port, se nikam nedostane. Testování UDP služby přes TCP nic nedokáže v žádné z těchto fází, proto použijte transport, který bude klient používat.

Adresy navázání rozhodují o dosažitelnosti

Zveřejněné mapování navázané na loopback je dosažitelné jen z hostitele, zatímco mapování navázané na všechna rozhraní je dosažitelné všude, kde to firewall dovolí. V souboru Compose, který adresu vynechává, vypadají obě stejně a výchozí hodnota Dockeru je ta širší.

Rozhodněte, jaké vystavení nasazení zamýšlí, a pak ho zapište výslovně. Interní test, který se připojuje přes loopback, a vzdálený klient, který se připojit nemůže, mohou být oba přesné popisy téhož kontejneru.

Přečtěte si běžící stav

Zkontrolujte efektivní mapování běžícího kontejneru a naslouchač v jeho síťovém jmenném prostoru. Soubor Compose mohl být upraven po spuštění kontejneru, metadata image mohou deklarovat port, aniž by ho zveřejňovala, a druhý kontejner už může držet port hostitele. Deklarovat port v image není totéž jako ho zveřejnit a ani jedno není totéž jako naslouchat.

Tři různé stavy, tři různé příkazy a jen ten poslední zahrnuje OpenVPN.

Až je mapování správné

Jakmile paket dorazí do OpenVPN, jeho log je místo, kde se čte o TLS a autentizaci. Znovu generovat certifikáty, abyste opravili paket, který nikdy nedorazil, je zbytečná práce, která přidá druhou proměnnou. Nechte poznámku o mapování u profilu klienta, aby si příští člověk přečetl jeden řádek místo znovuobjevování všech tří čísel. Jeden odchyt paketů na straně hostitele rozhodne, který ze tří článků je špatný, a stojí méně než obnova certifikátu.

Zveřejnění přes most je případ popsaný zde. Síť hostitele a směrované adresy kontejnerů překlad přeskakují, takže v těchto návrzích znamenají stejná čísla něco jiného.