Docker-konteinerferkear giet foarby de VPN fan de host: hoe't jo it kontrolearje
In host-VPN dekt allinnich de netwurknammeromte fan de host. Mei dizze kontrôles fine jo út oft konteinerferkear op in brêge de tunnel yn giet of direkt nei bûten.
Jo browser op de host lit it VPN-útgongsadres sjen, de konteiner meldt jo thúsferbining en immen neamt dat in lek. Der is neat lekt. In host-tunnel is in bondel ynterfaces, rûtes en regels dy't by de netwurknammeromte fan 'e host hearre, en in konteiner op in brêge is in oare nammeromte mei syn eigen standertrûte. Ik haw op in Compose-stapel sitten dêr't de VPN-klant wiken lang ferbûn wie en net ien konteinerpakket ea deryn kommen wie.
Kontrolearje de nammeromte foar it piktogram yn 'e taakbalke
Nammeromten binne it hiele argumint. As Docker in konteiner op in brêgenetwurk start, makket it in netwurknammeromte, ferbynt ien ein fan in veth-pear deryn en jout dy nammeromte in adres en in standertrûte. It tunnel-ynterface, hoe't it ek hjit, libbet yn 'e nammeromte fan 'e host. Ferkear yn 'e konteiner kin it net sjen, en gjin klantynstelling feroaret dat fan bûten.
Twa stipe bewegingen helje jo út 'e isolaasje. --network host pleatst de konteiner yn 'e nammeromte fan 'e host, sadat er de rûtes fan 'e host en dêrmei de tunnel erft. --network container:vpn dielt de nammeromte fan in oare konteiner, en sa stjoere de measte sidecar-ûntwerpen in wurklast troch in VPN-konteiner. Beide binne eksplisite karren; meastentiids is mar ien fan beide wat de persoan dy't it útrôlet bedoelde.
Hostmodus is gjin fergees upgrade. De konteiner hat gjin eigen adres mear, poartepublikaasje jildt net mear, en in proses dat dêr NET_ADMIN hat kin it rûtesjen fan 'e host oerskriuwe. Dat akseptearje kin de juste beslissing wêze. Oannimme dat it al oan stiet is hoe't minsken in jûn besteegje oan it debuggen fan in tunnel dy't nea yn it paad wie.
Folgje it pakket fan 'e brêge ôf
In brêgekonteiner stjoert syn pakket nei syn standertgateway, dat is it brêge-ynterface op 'e host. De host stjoert it pakket dan troch en set yn 'e standertkonfiguraasje it boarneadres om nei syn eigen foardat it pakket fuortgiet. Krekt dy omsettingsstap ferslacht belied stil.
Tsjin 'e tiid dat it pakket it tunnel-einpunt berikt, draacht it it adres fan 'e host. Eltse regel, beliedsrûte of beslissing oer in splitst tunnel dy't op it oarspronklike adres fan 'e konteiner basearre is, past net mear, en twa konteiners dy't troch ferskate útgongen fuort moatte kinne net allinnich oan 'e boarne ûnderskieden wurde. As jo rûtesjen per konteiner nedich hawwe, moat de beslissing foar de omsetting of yn in nammeromte dy't jo behearskje nommen wurde.
Docker ûnderhâldt dizze regels sels, fia hokker firewall-backend de daemon ek mei konfigurearre is. Mei de hân skreaune regels bûten de stipe heak foar trochstjoerd ferkear, DOCKER-USER, kinne op 'e nij oardere of fuortsmiten wurde as de daemon op 'e nij start of de host bywurket. De Docker-dokumintaasje oer pakketfiltering lit de folchoarder fan 'e keatlingen sjen; it praktyske punt is dat elke regel in eigner en in werlaadpaad nedich hat dat jo wier test hawwe.
Test de twa systemen apart
Bewiis út ien nammeromte seit neat oer de oare. In fersyk dat yn 'e VPN-konteiner draait bewiist dat de tunnel foar dy konteiner wurket. It is gjin bewiis oer de host, en itselde kommando út in --network host-konteiner is gjin bewiis oer de brêge.
# host namespace
ip route get 1.1.1.1
ip -brief addr show
# a fresh container on the same bridge network
docker run --rm --network appnet alpine sh -c 'ip route; cat /etc/resolv.conf; ip -6 route'Werhelje de test dan yn 'e echte applikaasjekonteiner ynstee fan in ferlykber image. De app kin in ekstra rûte, in proxy-omjouwingsfariabele of in oare resolver drage, en elk dêrfan feroaret it antwurd. Kontrolearje namme-oplossing en de twadde adresfamylje elke kear: konteiners op troch de brûker definiearre brêgen wurde oplost fia de ynboude resolver fan Docker op 127.0.0.11, en in IPv6-standertrûte op 'e brêge kin ferkear nei bûten bringe wylst jo dwaande binne mei it testen fan in tunnel dy't allinnich IPv4 is.
Lês it patroan foardat jo oan legitimasjes komme
As de host wurket en de konteiner net, is de oarsaak hast altyd struktureel, en kaaien draaie of de klant op 'e nij ynstallearje kostet in middei. Sortearje earst it symptoom en de oplossing neamt himsels meastentiids.
| What you see | Usual cause | First check |
|---|---|---|
| Host exits through the VPN, container shows the ISP address | The container never entered the tunnel | Default route inside the container |
| Container works until the daemon restarts, then stops | Rules outside the supported hook, or a changed backend | Daemon's reported firewall backend and DOCKER-USER |
| Container loses internal hosts after the tunnel comes up | VPN prefix overlaps the Docker bridge subnet | ip route on the host, then docker network inspect |
| Small replies arrive, large ones hang | Tunnel MTU or missing MSS clamping | Link MTU on both ends of the tunnel |
| Container falls back to the ISP address when the tunnel drops | Nothing enforces the kill switch for forwarded traffic | Stop the tunnel with a request in flight |
De oerlaaprige hat syn eigen sin fertsjinne. In VPN-profyl dat in rûte skoot foar 172.17.0.0/16, of foar in 10.0.0.0/8 dy't tafallich jo brêgeprefiks befettet, makket dat de tunnel it konteinersubnet opeasket, en antwurden nei omsette adressen sille de ferkearde kant út gean of ferdwine. It Docker-netwurk op 'e nij nûmerje is meastentiids skjinner as útsûnderingen op te sparjen.
Meitsje de dekking eksplisyt en brek se dan mei opset
Twa ûntwerpen hâlde stân by in resinsje. Diel de nammeromte fan 'e VPN-konteiner en elke dekte wurklast brûkt ien tunnel mei ien werstartgrins, wat ienfâldich is oant ien tsjinst in oare útgong of syn eigen DNS-paad nedich hat. Of rûtesje it konteinernetwurk nei in VPN-gateway op 'e host: trochstjoering oan, it brêgeprefiks op 'e tunnel rjochte, weromferkear eksplisyt behannele. Dat keapet kontrôle per netwurk en kostet jo in regelset dy't jo by daemon- en klantbywurkingen byhâlde moatte.
Hoe dan ek, de test dy't ta docht is it gefal fan mislearring. Stop de tunnel mei in konteinerfersyk ûnderweis en sjoch wêr't it pakket hinne giet. As it weromfalt op it direkte paad, waard dekking nea ôftwongen, want in kill switch fan 'e klant regelet it eigen ferkear fan 'e klant en net trochstjoerde pakketten fan in brêge. Start dêrnei de daemon en de host op 'e nij en befêstigje it resultaat in twadde kear; dat is it momint dat mei de hân skreaune regels ferdwine.
Foardat jo it klear neame, befêstigje fjouwer dingen: it tunnel-ynterface sit yn deselde nammeromte as it ferkear, de konteinertest rûn yn 'e echte konteiner, namme-oplossing en beide adresfamyljes waarden kontrolearre, en de tunnel-mislearringstest mislearret noch hieltyd ticht. Skriuw dan de firewall-backend, de klantferzje en de eigner fan elke regel op. Dy registraasje is wat foarkomt dat de folgjende bywurking in ûndokumintearre miks fan âlde oannames efterlit.