Prečo sa mapovanie portov VPN v Dockeri nikdy nedostane do OpenVPN

Váš kontajner môže počúvať na UDP 1195, zatiaľ čo hostiteľ zverejňuje 1194, a je to správne, pokiaľ to mapovanie hovorí. Čísla tvoria prekladovú tabuľku: klient vytočí port hostiteľa, Docker prepíše cieľ na port kontajnera a OpenVPN odpovie na porte, ktorý uvádza jeho vlastná konfigurácia. Nezhoda v ktoromkoľvek z týchto článkov spôsobí tichú poruchu, ktorá vyzerá ako firewall. Certifikáty a šifry sú až za tým a nemôžu to napraviť.

Prejdite jeden paket od klienta k procesu, skôr než zmeníte čokoľvek v autentifikácii.

Tri čísla, jedno spojenie

Tie tri čísla sú vzdialený cieľ, ktorý klient používa, zverejnené mapovanie na hostiteľovi a poslucháč vnútri kontajnera. Nemusia byť rovnaké, ale musia tvoriť reťaz. Rovnaké čísla sú špeciálny prípad, ktorý je náhodou najčastejší, preto sa nezhoda ľahko raz napíše a ťažko sa neskôr vidí.

Zapíšte reťaz na jeden riadok pred ladením: adresa a port klienta, mapovanie hostiteľa, poslucháč kontajnera, transport. Porucha v reťazi sa prejaví ako číslo, ktoré sa objaví dvakrát s rôznymi hodnotami.

Čo krátka syntax naozaj hovorí

V krátkej forme je ľavá strana port hostiteľa a pravá port kontajnera a prípona s lomkou vyberá transport. Ak príponu vynecháte, Docker mapovanie považuje za TCP, takže poslucháč UDP za mapovaním bez protokolu je poslucháč, ku ktorému sa nikto nedostane. Toto predvolené správanie je zdokumentované a stále prekvapuje ľudí, ktorí čísla zladili a považovali vec za hotovú.

Dlhá forma výslovne fixuje adresu naviazania a protokol, čo stojí za riadky navyše pri všetkom vystavenom sieti. Prečítajte si zverejnené mapovanie späť, namiesto toho, aby ste dôverovali súboru, ktorý ho vytvoril.

ports:
  - 1194:1195/udp

Kde sa paket môže zastaviť

Požiadavka môže byť zahodená pred Dockerom, v Dockeri alebo u poslucháča. Pred Dockerom môže byť cloudový firewall alebo router s vlastným presmerovaním a toto zariadenie potrebuje port otočený k hostiteľovi a správny transport. Vnútri Dockera mapovanie na nesprávny port kontajnera presmeruje na zatvorený socket.

Potom poslucháč: konfigurácia OpenVPN uvádza port a protokol a klient, ktorý vnútri kontajnera príde na iný, sa nikam nedostane. Testovanie UDP služby cez TCP nič nedokáže v žiadnej z týchto fáz, preto použite transport, ktorý bude klient používať.

Adresy naviazania rozhodujú o dostupnosti

Zverejnené mapovanie naviazané na loopback je dostupné len z hostiteľa, zatiaľ čo mapovanie naviazané na všetky rozhrania je dostupné všade, kde to firewall dovolí. V súbore Compose, ktorý adresu vynecháva, vyzerajú obe rovnako a predvolená hodnota Dockeru je tá širšia.

Rozhodnite, aké vystavenie nasadenie zamýšľa, a potom ho zapíšte výslovne. Interný test, ktorý sa pripája cez loopback, a vzdialený klient, ktorý sa pripojiť nemôže, môžu byť oba presné opisy toho istého kontajnera.

Prečítajte si bežiaci stav

Skontrolujte efektívne mapovanie bežiaceho kontajnera a poslucháča v jeho sieťovom mennom priestore. Súbor Compose mohol byť upravený po spustení kontajnera, metadáta obrazu môžu deklarovať port bez jeho zverejnenia a druhý kontajner už môže držať port hostiteľa. Deklarovať port v obraze nie je to isté ako ho zverejniť a ani jedno nie je to isté ako počúvať.

Tri rôzne stavy, tri rôzne príkazy a len ten posledný zahŕňa OpenVPN.

Keď je mapovanie správne

Keď paket dorazí do OpenVPN, jeho log je miesto, kde sa číta o TLS a autentifikácii. Znova generovať certifikáty, aby ste opravili paket, ktorý nikdy nedorazil, je zbytočná práca, ktorá pridá druhú premennú. Nechajte poznámku o mapovaní pri profile klienta, aby si nasledujúci človek prečítal jeden riadok namiesto opätovného objavovania všetkých troch čísel. Jeden odchyt paketov na strane hostiteľa rozhodne, ktorý z troch článkov je nesprávny, a stojí menej ako obnova certifikátu.

Zverejnenie cez most je prípad opísaný tu. Sieť hostiteľa a smerované adresy kontajnerov preklad preskakujú, takže v týchto návrhoch znamenajú rovnaké čísla niečo iné.