Pag-publish ng Port ng Docker laban sa VPN: Saan Napupunta ang Tugon

Ang na-publish na container ay tumutugon mula sa sariling address bago ang reverse NAT. Dalawang disenyo ang maaaring magpanatili ng tugon sa pampublikong landas, na may magkaibang gastos.

Patuloy na sumasagot ang host sa SSH pagkatapos bumangon ang isang VPN na full tunnel, habang ang serbisyong na-publish sa Docker sa parehong makina ay tumatahimik. Walang mali sa listener: tumatakbo ang container, umiiral ang port mapping, at dumarating ang packet. Malusog ang container at talagang naaabot ito ng request. Ang pagkakaiba ay kung saan nagsisimula ang tugon kapag pumipili ang Linux ng ruta nito, at ang pagkakaibang iyon ang nagpapasya kung alin sa dalawang disenyo sa ibaba ang kailangan mo.

Sundan ang tuple sa pamamagitan ng destination NAT

Kumuha ng host sa 192.0.2.10 na nag-publish ng TCP 2222 sa isang container sa 172.30.240.5:22. Ang request mula sa 198.51.100.25 ay isinasalin bago pa man umabot sa container, at tumutugon ang container bilang sarili nito.

WAN request:      198.51.100.25 -> 192.0.2.10:2222
after DNAT:       198.51.100.25 -> 172.30.240.5:22
container reply:  172.30.240.5:22 -> 198.51.100.25

Sa desisyon ng ruta ng host, dinadala pa rin ng tugon ang source address ng container. Ibinalik ng reverse translation ang na-publish na tuple mamaya, at iyon ang dahilan kung bakit mukhang mali ang packet sa eksaktong sandaling pinipili ang ruta.

Bakit ito namimiss ng tuntuning para sa host lamang

Ang tuntuning pumipili ng WAN table para lamang sa mga packet mula sa 192.0.2.10 ay sumasaklaw sa sariling mga daemon ng host at tuluyang namimiss ang forward na tugon na ito. Ang source address sa tugon ay 172.30.240.5, hindi ang host.

Ang sobrang pagwawasto ay ang i-ruta ang lahat mula sa container sa pamamagitan ng WAN, na naglalabas din sa VPN ng mga walang kaugnayang palabas na koneksyon ng container. Iba itong patakaran sa hiniling, at karaniwang may nagugulat mamaya.

Ang pagtutugma pagkatapos ng DNAT ay ibang hook

Ang dokumentasyon ng Docker tungkol sa firewall ay nagsasaad na nakikita ng ordinaryong user filtering ang destinasyon pagkatapos ng DNAT, kaya ang pagtutugma ng na-publish na port 2222 sa normal na tuntunin ay hindi katulad ng pagtutugma ng port 22 ng container. Kung mahalaga ang orihinal na tuple, gamitin ang sinusuportahang mekanismo ng orihinal na destinasyon sa halip na hulaan kung aling port ang nakikita.

Ang kalituhan sa hook na ito ay lumilikha ng mga tuntuning mukhang tama at hindi kailanman tumutugma. Suriin ang mga counter sa mismong tuntunin bago muling isulat ang patakaran. Ang tuntuning walang hit ay nagsasabi sa iyo na sinusuri ito sa lugar na hindi naaabot ng packet.

Disenyo A: dalhin ang desisyon bilang estado ng koneksyon

Maaaring dalhin ng mark ng koneksyon ang desisyon sa pagpasok sa paglipas ng salin, ngunit kailangan itong ibalik sa packet bago ang mahalagang paghahanap ng ruta. Ang mga yugto ay:

  1. Magreserba ng patlang ng mark at priyoridad ng tuntunin na hindi bumabangga sa Docker, sa VPN o sa ibang may-ari ng patakaran.
  2. Tukuyin lamang ang sinadyang bagong koneksyon sa WAN sa isang puntong bago ang DNAT kung saan available ang pagsubaybay ng koneksyon.
  3. Itala ang desisyon sa mark ng koneksyon, nang hindi pinipilit ang orihinal na request mismo sa WAN table.
  4. Sa direksyon ng tugon, ibalik lamang ang sarili mong mga mark bit sa packet bago ang routing.
  5. Pumili ng kumpletong WAN table nang sapat na maaga upang hindi manalo muna ang tuntunin ng VPN.

Kailangan ng tabelang iyon ang tunay na konektadong mga ruta at ang gateway. Kailangan din nito ang tinukoy na pag-uugali kapag kulang ang ruta. Ang tahimik na pagkahulog sa tunnel ang pinakamasamang resulta, dahil mukhang gumagana pa rin ang configuration. Sa halip, mabigo nang sarado at i-log ito.

Disenyo B: tapusin sa host

Ang sadyang na-configure na frontend sa panig ng host, tulad ng TCP proxy o reverse proxy sa harap ng container, ay nagpapanatili ng tugon na nagmumula sa address ng host. Pagkatapos, ang mga tuntuning isinulat para sa host ay kumikilos ayon sa inaasahan, at nananatili ang container sa sarili nitong pribadong network.

Ang gastos ay isa pang gumagalaw na bahagi na may sariling configuration, paghawak ng source address at mga kontrol sa access. Karaniwan itong ang mas simpleng sinusuportahang hangganan, at madalas ito ang tamang sagot kapag ang patakaran sa routing ay pag-aalaga ng isang taong maaaring umalis.

I-verify ang pagbabago, hindi ang layunin

Magbukas ng bagong awtorisadong koneksyon mula sa pampublikong panig at kumpirmahin na lumalabas ang tugon sa sinadyang interface. Pagkatapos, suriin kung ang walang kaugnayang request na sinimulan ng container ay sumusunod pa rin sa VPN.

Huwag i-flush ang connection table ng makina para subukan ang isang tuntunin: pinapanatili ng mga umiiral na entry ang dating mapping, at ang pag-flush ay sumisira sa lahat ng iba pa sa host. Ang pag-publish ng port ay tumutukoy sa maabot. Hindi nito tinutukoy ang landas ng tugon. Isulat ang napiling disenyo kasama ang mga pangalan ng table nito, upang hindi na kailangang muli itong tuklasin ng susunod na tao sa panahon ng insidente.

Kaugnay na mga artikulo