Hindi maabot ang Docker container sa VPN? Ihambing ang mga subnet

Sumasagot ang mga container sa LAN ng opisina, pagkatapos ay tumitigil sa pagsagot sa sandaling kumonekta ang VPN ng kumpanya. Walang nagbago sa container: walang restart, walang update ng image, walang pag-edit ng config. Ang nagbago ay ang routing table ng host, kung saan ang rutang idinagdag ng tunnel ay sumasakop na sa address na ibinigay ng Docker. Bago mo i-edit ang isang subnet o humingi ng exemption sa VPN, ilagay ang dalawang plano ng address nang magkatabi, dahil magkaibang-magkaiba ang oras na kailangan ng bawat pag-aayos.

Basahin ang ruta bago mo baguhin ang config

Magsimula sa network na aktwal na itinayo ng Docker. Ang IPAM block ang plano ng address, at ang subnet ang linyang mahalaga:

docker network inspect project_default --format '{{json .IPAM.Config}}'
# [{"Subnet":"172.18.0.0/16","Gateway":"172.18.0.1"}]

Default na naglalaan ang Compose ng /16 para sa bawat bagong proyekto, kaya dalawang serbisyo ang maaaring umupo sa loob ng saklaw na 65,536 address. Ang lapad na ito ang dahilan kung bakit karaniwan ang overlap: ang random na piniling /16 ay sapat na malaki para lamunin ang isang site na naaabot mo sa tunnel, at walang nakakapansin hanggang sa umangat ang tunnel.

Pagkatapos, ihambing ang pagpili ng ruta para sa isang address ng container, isang beses na patay ang tunnel at isang beses na buhay ito:

ip route get 172.18.0.7
# 172.18.0.7 dev br-3f2a9c src 172.18.0.1

Dalawang anyo ng sagot ang humahantong sa magkaibang lugar. Kung pinapangalanan ng output ang tun0, wg0 o ibang device ng tunnel, ang prefix ng VPN ay kasing-specipiko ng ruta ng tulay at hindi kailanman umaabot ang packet sa container. Kung pinapangalanan pa rin nito ang tulay, naaabot ng host ang container, at ang depekto mo ay pag-filter, DNS, o return path na pumapalya sa isang direksyon lang.

Bakit madaling matamaan ang banggaan ng /16

Kinukuha ng Docker ang mga bridge network mula sa mga pribadong pool, at ang default na pool ay nagmumula sa bloke ng 172.16.0.0/12 sa mga hiwa na /16. Madalas gamitin ng mga corporate network ang parehong pribadong espasyo, at itinutulak ng remote-access VPN ang mga prefix na iyon sa bawat client na kumonekta. Kapag parehong panig ay naniniwalang pag-aari nila ang 172.18.0.0/16, may dalawang magkasalungat na pag-aangkin sa isang routing table.

Ang haba ng prefix ang nagpapasya sa panalo, hindi ang pagkakasunod-sunod ng ruta. Ang tunnel na nagtutulak ng 10.0.0.0/8 ay hindi natalo ang rutang tulay na 172.18.0.0/16, dahil mas hindi specipiko ang /8. Ang tunnel na nagtutulak ng 172.18.0.0/16, o 172.18.5.0/24 sa loob nito, ay nananalo. Ito ang dahilan kung bakit gumagana ang isang laptop sa network ng opisina at pumapalya sa Wi-Fi ng hotel sa parehong VPN: magkaibang prefix ang natatanggap ng client.

Ang parehong table ang namamahala sa kabilang direksyon. Ang container na nangangailangan ng internal host sa 10.8.4.20 ay nagpapadala ng packet sa bridge gateway nito, at pagkatapos ay iruruta ito ng host papasok sa tunnel. Karaniwang gumagana ang landas na iyon dahil ginagawa ng host ang NAT, ngunit pumapalya ito kapag tinatanggap lang ng corporate side ang VPN address ng laptop, o kapag itinatapon ng reverse-path filtering ang asymmetric na sagot.

Ihambing ang tatlong pag-aayos

Tatlo lang ang labasan, at magkaiba sila sa kung sino ang dapat mag-apruba at kung ano ang masisira habang inilalapat mo ang isa.

Ang muling pag-numero ang tanging pag-aayos na matatapos mo nang walang ticket, kaya doon humihinto ang karamihan ng sulatin. Mura ito sa bagong proyekto at nagiging mahal kapag may tool sa migration o naka-save na connection string na tumuturo sa literal na address. Bilangin ang mga reference na iyon bago mo i-edit ang YAML, hindi pagkatapos.

Ang exemption mula sa tunnel ang pinakamalinis na sagot kapag ang overlap ay nasa saklaw na tunay na pag-aari ng kumpanya mo. Ito rin ang pinakamabagal, at walang gamit ito sa kontraktor na hindi mababago ang profile ng client. Ang nai-publish na port o maliit na reverse proxy ay umiiwas sa pagtatalo: kausap ng client ang address na tama nang irinuruta ng tunnel, at ang port na iyon lang ang kailangang maabot.

I-pin ang isang saklaw nang sadya

Para sa isang proyekto, ideklara ang subnet sa compose file para tumigil ang proyekto sa pagkuha mula sa shared pool:

networks:
  default:
    ipam:
      config:
        - subnet: 10.201.7.0/24

Kunin ang saklaw na iyon mula sa registry na pinapanatili ng team mo, hindi mula sa halimbawang nakita mo habang naghahanap. Suriin ito laban sa mga prefix na itinutulak ng VPN, sa mga home LAN na pinagtatrabahuhan ng mga tao, at sa iba pang container network sa parehong host. Pagkatapos ay planuhin ang muling paggawa, dahil pinapanatili ng umiiral na network ang lumang subnet nito: docker compose down, pagkatapos ay up -d. Tumatanggi ang docker network rm habang may nakakabit na endpoint, at ang anumang entry na ipv4_address sa file ay dapat pumasok sa bagong saklaw.

Para sa mga network na siyang ginagawa ng Docker, magtakda ng daemon pool sa /etc/docker/daemon.json:

{
  "default-address-pools": [
    { "base": "10.201.0.0/16", "size": 24 },
    { "base": "10.202.0.0/16", "size": 24 }
  ]
}

Nalalapat ang pool sa mga network na ginawa pagkatapos mag-restart ang daemon, at pinapanatili ng mga tulay na umiiral na ang kanilang address. Maginhawa iyon at madaling makalimutan, kaya ituring na overlap pa rin ang lumang proyekto hanggang may gumawa muli ng network nito. Ang dokumentasyon ng networking ng engine ng Docker ay naglalarawan ng mga tuntunin sa paglalaan kung kailangan mong ipagtanggol ang pool sa isang review.

Iba ang pagpalya ng Linux bridge at Docker Desktop

Sa host na Linux, nakaupo ang mga container sa mga tulay sa namespace ng host. Isang table ang nagpapasya sa lahat, kaya ang paghahambing sa itaas ang buong kuwento: basahin ang ruta ng tulay, basahin ang ruta ng tunnel, at tingnan kung alin ang nananalo para sa totoong address ng container.

Inilalagay ng Docker Desktop ang mga container sa likod ng VM na may sariling NAT. Wala talagang ruta ang host patungo sa address ng container; naaabot nito ang serbisyo sa pamamagitan ng nai-publish na port, kadalasang nakatali sa 127.0.0.1. Kaya maaaring sirain ng VPN client ang serbisyo nang walang anumang subnet overlap: sa pamamagitan ng pag-install ng ruta para sa internal na saklaw ng VM o sa pagharang sa loopback traffic habang konektado ang tunnel. Kung ang ip route get sa host ay nag-uulat na walang ruta para sa address ng container, inaasahan iyon at hindi ang bug.

Ang praktikal na bunga ay kung saan ka muna titingin. Sa Linux, magsimula sa routing table. Sa Desktop, magsimula sa nai-publish na port at sa mga patakaran ng firewall ng VPN client, pagkatapos ay tingnan kung ang internal na subnet ng VM ay bumabangga sa anumang itinutulak ng tunnel.

I-verify habang buhay ang tunnel

Kumonekta muli sa VPN nang dalawang beses bago mo sabihing ayos na, dahil ang profile na nagtutulak ng ruta sa pagkonekta at nag-aalis nito sa pagdiskonekta ay maaaring magmukhang tama pagkatapos ng unang pagtatangka. Pagkatapos ay patakbuhin ang mga pagsusuring aktwal na ginagawa ng client:

1. ip route get mula sa host, gamit ang totoong address ng container.
2. Isang kahilingan mula sa ibang container, para patunayang malusog ang serbisyo mismo.
3. curl -sv http://127.0.0.1:8080/ mula sa client habang buhay ang tunnel, pagkatapos ay traceroute -n patungo sa address ng container mula sa isang makina sa LAN.
4. sysctl net.ipv4.conf.all.rp_filter kung umaabot ang kahilingan sa host ngunit nawawala ang sagot.

Sa huli, isulat ang napiling saklaw sa parehong registry na ginamit mo upang piliin ito, kasama ang petsa at ang proyektong nagmamay-ari nito. Ang susunod na overlap ay magmumula sa proyektong walang nagdokumento, at ang tanging depensa ay ang saklaw ay sadyang inireserba sa halip na kinuha nang random.