Zašto vaše Docker VPN mapiranje portova nikada ne stiže do OpenVPN-a

Vaš kontejner može slušati na UDP 1195 dok host objavljuje 1194, i to je ispravno ako mapiranje tako kaže. Brojevi tvore tablicu prevođenja: klijent bira port hosta, Docker prepisuje odredište na port kontejnera, a OpenVPN odgovara na portu koji imenuje njegova vlastita konfiguracija. Nesklad u bilo kojoj od tih veza daje tihi neuspjeh koji izgleda kao vatrozid. Certifikati i šifre nalaze se nizvodno i ne mogu ga popraviti.

Ispraćajte jedan paket od klijenta do procesa prije nego što promijenite bilo što u vezi s autentifikacijom.

Tri broja, jedna veza

Tri broja su udaljeno odredište koje klijent koristi, objavljeno mapiranje na hostu i slušatelj unutar kontejnera. Ne moraju biti jednaki, ali moraju tvoriti lanac. Jednaki brojevi su poseban slučaj koji je slučajno najčešći, zato je nesklad lako napisati jednom i teško primijetiti kasnije.

Zapišite lanac u jednom redu prije otklanjanja greške: adresa i port klijenta, mapiranje hosta, slušatelj kontejnera, transport. Greška u lancu pokazuje se kao broj koji se pojavljuje dvaput s različitim vrijednostima.

Što kratka sintaksa zapravo kaže

U kratkom obliku lijeva strana je port hosta, a desna port kontejnera, a sufiks s kosom crtom odabire transport. Izostavite li sufiks, Docker mapiranje tretira kao TCP, pa je UDP slušatelj iza mapiranja bez protokola slušatelj do kojeg nitko ne može doći. To je zadano ponašanje dokumentirano i još uvijek iznenađuje ljude koji su uskladili brojeve i proglasili posao završenim.

Dugi oblik eksplicitno fiksira adresu vezanja i protokol, što vrijedi dodatnih redaka za sve što je okrenuto mreži. Pročitajte objavljeno mapiranje natrag umjesto da vjerujete datoteci koja ga je stvorila.

ports:
  - 1194:1195/udp

Gdje se paket može zaustaviti

Zahtjev može biti odbačen prije Dockera, u Dockeru ili kod slušatelja. Ispred Dockera može biti vatrozid u oblaku ili usmjerivač koji sam preusmjerava, a taj uređaj treba port okrenut hostu i ispravan transport. Unutar Dockera mapiranje na pogrešan port kontejnera prosljeđuje na zatvorenu utičnicu.

Zatim slušatelj: OpenVPN konfiguracija imenuje port i protokol, a klijent koji unutar kontejnera stigne na drugi port ne doseže ništa. TCP testiranje UDP usluge ne dokazuje ništa ni u jednoj od tih faza, zato koristite transport koji će klijent koristiti.

Adrese vezanja odlučuju dostupnost

Objavljeno mapiranje vezano na loopback dostupno je samo s hosta, dok je ono vezano na sva sučelja dostupno gdje god vatrozid dopušta. Ta dva izgledaju jednako u Compose datoteci koja izostavlja adresu, a Docker zadana vrijednost je šira.

Odlučite koje izlaganje raspoređivanje namjerava, pa to zapišite eksplicitno. Interni test koji se spaja preko loopbacka i udaljeni klijent koji se ne može spojiti mogu oba biti točni opisi istog kontejnera.

Pročitajte radno stanje

Provjerite stvarno mapiranje pokrenutog kontejnera i slušatelj u njegovom mrežnom imenskom prostoru. Compose datoteka možda je uređena nakon pokretanja kontejnera, metapodaci slike mogu navesti port bez objavljivanja, a drugi kontejner možda već drži port hosta. Navesti port u slici nije isto kao objaviti ga, a ni jedno od toga nije isto kao slušati.

Tri različita stanja, tri različite naredbe, a samo posljednja uključuje OpenVPN.

Nakon što je mapiranje ispravno

Kad paket stigne do OpenVPN-a, njegov dnevnik je mjesto na kojem se čita o TLS-u i autentifikaciji. Ponovno generiranje certifikata da bi se popravio paket koji nikada nije stigao uzaludan je posao koji dodaje drugu varijablu. Držite bilješku o mapiranju uz profil klijenta kako bi sljedeća osoba pročitala jedan redak umjesto da iznova otkriva sva tri broja. Jedno snimanje paketa na strani hosta rješava koja je od tri veze pogrešna i košta manje od obnove certifikata.

Ovdje je opisan slučaj objavljivanja preko mosta. Mreža hosta i usmjerene adrese kontejnera preskaču prevođenje, pa isti brojevi u tim izvedbama znače nešto drugo.