Docker-porda publikigo kaj VPN-fontoj: du kongruoj, kiujn vi maltrafas

La regulo diras permesi la adreson de la VPN-servilo al la publikigita servo, kaj tamen la konekto falas. Tiu rezulto oftas, kaj ĝi ne estas cimo de Docker. Du apartaj kongruoj estas malĝustaj: la fonto, kiun vi skribis, eble ne estas la fonto, kiun la gastiganto ricevas, kaj la pordo, kiun vi skribis, eble ne estas la pordo, kiun la filtrilo vidas. Ripari ambaŭ postulas rigardi la pakan vojon anstataŭ la servan diagramon.

La mito: permesu la VPN-servilon kaj vi finis

Enkursigita VPN povas konservi la tunelan adreson de la kliento ĝis la Docker-gastiganto. Kluzo, kiu faras fontan tradukon, povas anstataŭigi tiun adreson per sia propra. Ambaŭ dezajnoj estas legitimaj, kaj ili produktas malsamajn fontojn por la sama uzanto-ago.

Do la frazo IP de la VPN-servilo priskribas supozon, ne observon. Ĝis vi scias, kiu el la du dezajnoj staras antaŭ vi, la regulo estas konjekto.

Fonto: klienta baseno aŭ tradukita kluzo

Kontrolu kvar aferojn laŭorde. Unue, la klientan adresan basenon, ekzemple 10.90.0.0/24. Due, ĉu la kluzo tradukas tiun basenon antaŭ ol ĝi atingas la gastiganton. Trie, la fonton, kiun la gastiganto efektive observas por unu nova konekto. Kvare, ĉu la aplikaĵa aŭtentikigo distingas unuopajn uzantojn, ĉar komuna tradukita adreso ne povas.

Se la baseno konserviĝas, regulo kongruanta nur la publikan adreson de la kluzo maltrafas ĉiun klienton. Se la kluzo tradukas intence, permeso de la tradukita adreso enlasas ĉiun uzanton malantaŭ ĝi, kio povas esti akceptebla por servo kun propra ensaluto kaj neakceptebla por io ajn alia.

Pordo: DNAT ŝanĝas la nombron, kiun vi kongruas

Ĉe ordinara Linuksa ponto-publikigo kun Docker iptables, gastiganta mapado de 8443 al kontenera pordo 443 tradukiĝas antaŭ ol la plusendada filtrilo ruliĝas. La paketo alvenas al la filtrilo kun cella pordo 443. Regulo kongruanta 8443 en tiu punkto neniam ekfunkcias, kvankam 8443 estas tio, kion la kliento tajpis.

La publikigita pordo ankoraŭ ekzistas en konekta spurato, tial la origina celloko povas esti kongruata tie, kiam vi vere bezonas ĝin.

Decidu, kiu nombro esprimas la intencon. Kongruu la konteneran pordon post DNAT, kiam la regulo protektas la servon ene de la kontenero. Kongruu la originan cellokon per la conntrack-opcio, kiam la regulo devas priskribi, kion la kliento petis, kaj akceptu la plian kongruan koston kaj la zorgon pri regula ordo, kiuj venas kun ĝi.

Ĉeno: DOCKER-USER, ne INPUT

La iptables-gvidilo de Docker metas la plusendadan politikon de uzanto en la ĉenon DOCKER-USER, kiu estas taksata antaŭ la propraj plusendadaj reguloj de Docker. Regulo kopiita el gastiganta servo en la ĉenon INPUT filtras trafikon adresitan al la gastiganto, ne trafikon plusendatan al kontenero. Tiu eraro produktas regulon, kiu aspektas ĝusta kaj havas neniun efikon al la kontenera vojo.

Tenu la fontan intervalon, la efikan cellan pordon, la protokolon kaj la enigan interfacon kune en la sama regulo. Permeso nur laŭ fonto por ĉiu plusendata celloko estas pli larĝa ol permesi unu publikigitan servon.

Kontrolu per novaj konektoj

Testu ambaŭ direktojn per novaj konektoj: unu permesita VPN-kliento kaj unu fonto, kiu devus resti malpermesita. Ekzistanta konekta stato povas teni seancon viva post kiam la politiko ŝanĝiĝis, do malnova konekto pruvas nenion pri la nova regulo. Poste kontrolu la respondon vojon, ĉar la kontenero ankoraŭ devas enkursigi reen al la fonto, kiun ĝi vidas.

La iptables-gvidilo de Docker dokumentas la ĉenan ordon kaj la pordan tradukan konduton malantaŭ tiuj kontroloj. Legu ĝin antaŭ ol kopii recepton, kaj konfirmu, kiun backend la instalita Docker uzas, ĉar la nftables-backend integras politikon alimaniere.