Docker контейнерлеринин трафиги хосттун VPN кызматын айланып өтөт: кантип текшерүү керек
Хосттун VPN кызматы хосттун тармактык аттар мейкиндигин гана камтыйт. Бул текшерүүлөр менен көпүрөдөгү контейнерлердин трафиги туннелге кирерин же түз чыгарын аныктаңыз.
Хосттогу браузериңиз VPNдин чыгуу дарегин көрсөтөт, контейнер үй байланышыңыз тууралуу билдирет, ал эми бирөө муну агып кетүү деп атайт. Эч нерсе аккан жок. Хосттун туннели — хосттун тармактык аттар мейкиндигине таандык интерфейстердин, маршруттардын жана эрежелердин жыйындысы, ал эми көпүрөдөгү контейнер өзүнүн демейки маршруту бар башка аттар мейкиндиги. Мен VPN клиенти жумалар бою туташып турган, бирок бир да контейнер пакети эч качан кирбеген Compose стегинде отургам.
Аттар мейкиндигин трей белгичесинен мурун текшериңиз
Аттар мейкиндиктери — бүткүл далил. Docker көпүрөлүү тармакта контейнерди иштеткенде, ал тармактык аттар мейкиндигин түзөт, veth жубунун бир учун анын ичине туташтырат жана бул мейкиндикке дареги менен демейки маршрутту берет. Туннелдин интерфейси, кандай аталбасын, хосттун аттар мейкиндигинде жашайт. Контейнердин ичиндеги трафик аны көрө албайт, жана эч бир клиент параметри муну сырттан өзгөртпөйт.
Окуулангандыктан чыгаруучу эки колдоого алынган кадам бар. --network host контейнерди хосттун аттар мейкиндигине жайгаштырат, ошондуктан ал хосттун маршруттарын жана ошону менен туннелди мураска алат. --network container:vpn башка контейнердин аттар мейкиндигин бөлүшөт, жана sidecar курулуштарынын көбү жүктү VPN контейнери аркылуу ушундай жөнөтөт. Экөө тең ачык тандоо; адатта алардын бири гана жайгаштыруучунун оюнда болгон.
Хост режими бекер жаңыртуу эмес. Контейнер өз дарегин ээлөөнү токтотот, портторду жарыялоо колдонулбай калат, жана ал жерде NET_ADMIN кармаган процесс хосттун маршруттоосун кайра жаза алат. Муну кабыл алуу туура чечим болушу мүмкүн. Ал мурунтан күйүп турат деп болжолдоо — адамдардын жолдо эч качан болбогон туннелди кечинде оңдошунун себеби.
Пакетти көпүрөдөн чыгарып көзөмөлдөңүз
Көпүрөдөгү контейнер пакетин өзүнүн демейки дарбазасына жөнөтөт, ал хосттогу көпүрө интерфейси. Андан кийин хост пакетти өткөрүп жиберет жана демейки конфигурацияда пакет чыкпай туруп, булак дарегин өз дарегине которот. Ушул которуу баскычы саясатты үнсүз жок кылат.
Пакет туннелдин акыркы чекитине жеткенде, ал хосттун дарегин алып жүрөт. Контейнердин баштапкы дарегине таянган каалаган эреже, саясат маршруту же бөлүнгөн туннел чечими дал келүүнү токтотот, жана ар башка чыгуулардан чыгууга тийиш болгон эки контейнерди булак боюнча гана айырмалоо мүмкүн эмес. Эгер сизге контейнер боюнча маршруттоо керек болсо, чечим которууга чейин же өзүңүз көзөмөлдөгөн аттар мейкиндигинде кабыл алынышы керек.
Docker бул эрежелерди өзү кармайт, daemon кайсы firewall backend менен конфигурацияланган болсо, ошонун аркылуу. Өткөрүлүүчү трафик үчүн колдоого алынган илгичтен тышкары кол менен жазылган эрежелер, DOCKER-USER, daemon кайра иштетилгенде же хост жаңыртылганда кайра иреттелиши же өчүрүлүшү мүмкүн. Dockerдин пакеттерди чыпкалоо боюнча документтери чынжырлардын иретин көрсөтөт; практикалык маселе — ар бир эрежеге ээси жана чындап сынаган кайра жүктөө жолу керек.
Эки системаны өз-өзүнчө сынаңыз
Бир аттар мейкиндигинен алынган далил экинчиси жөнүндө эч нерсе айтпайт. VPN контейнеринин ичинде аткарылган сурам туннелдин ошол контейнер үчүн иштээрин далилдейт. Бул хост жөнүндө далил эмес, жана --network host контейнеринен аткарылган ошол эле буйрук көпүрө жөнүндө далил эмес.
# 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'Андан кийин сыноону окшош имиджден эмес, чыныгы колдонмо контейнеринин ичинде кайталаңыз. Колдонмо кошумча маршрут, прокси чөйрөсүнүн өзгөрмөсү же башка чечүүчү алып жүрүшү мүмкүн, жана алардын ар бири жоопту өзгөртөт. Ар жолу аттарды чечүүнү жана экинчи даректер үй-бүлөсүн текшериңиз: колдонуучу аныктаган көпүрөлөрдөгү контейнерлер Dockerдин курулган чечүүчүсү аркылуу 127.0.0.11 дарегинде чечилет, ал эми көпүрөдөгү IPv6 демейки маршруту сиз IPv4 гана туннелин сынап жатканда трафикти сыртка алып чыга алат.
Күбөлүктөргө тийүүдөн мурун үлгүнү окуңуз
Хост иштеп, контейнер иштебегенде, себеп дээрлик ар дайым структуралык, жана ачкычтарды айландыруу же клиентти кайра орнотуу жарым күндү текке кетирет. Адегенде симптомду иреттеңиз, оңдоо адатта өзүн өзү атайт.
| 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 |
Кайчылашуу сабы өзүнүн сүйлөмүнө татыктуу. 172.17.0.0/16 үчүн же көпүрө префиксиңизди кокустан камтыган 10.0.0.0/8 үчүн маршрутту түрткөн VPN профили туннелди контейнердин ички тармагына доомат коюуга мажбурлайт, жана которулган даректерге барган жооптор туура эмес тарапка кетет же жок болот. Docker тармагын кайра номурлоо адатта өзгөчөлүктөрдү жыйноодон тазараак.
Камтууну ачык кылыңыз, анан аны атайылап бузуңуз
Эки долбоор кароого туруштук берет. VPN контейнеринин аттар мейкиндигин бөлүшүңүз, ошондо камтылган ар бир жүк бир кайра иштетүү чеги бар бир туннелди колдонот, бул бир кызматка башка чыгуу же өзүнүн DNS жолу керек болгонго чейин жөнөкөй. Же контейнерлер тармагын хосттогу VPN дарбазасына багыттаңыз: өткөрүп жиберүү күйүк, көпүрө префикси туннелге багытталган, кайтарылган трафик ачык иштетилген. Бул ар бир тармакка көзөмөл сатып алат жана daemon менен клиенттин жаңыртуулары боюнча кармоого тийиш болгон эрежелер жыйындысын кымбатка түшүрөт.
Кандай болбосун, маанилүү сыноо — иштебей калуу учуру. Контейнердин сурамы учуп жатканда туннелди токтотуңуз жана пакеттин кайда кетерин караңыз. Эгер ал түз жолго кайта турса, камтуу эч качан аткарылган эмес, анткени клиенттин kill switch клиенттин өз трафигин башкарат, көпүрөдөн өткөрүлгөн пакеттерди эмес. Андан кийин daemon менен хостту кайра иштетип, натыйжаны экинчи жолу ырастаңыз; кол менен жазылган эрежелер жоголгон так ошол учур.
Аны бүттү деп атоодон мурун төрт нерсени ырастаңыз: туннелдин интерфейси трафик менен бир аттар мейкиндигинде, контейнер сыноосу чыныгы контейнердин ичинде өттү, аттарды чечүү жана эки дарек үй-бүлөсү тең текшерилди, жана туннелдин иштебей калуу сыноосу дагы эле жабык түрдө иштебейт. Андан кийин firewall backend, клиенттин версиясы жана ар бир эреженин ээсин жазыңыз. Ушул жазуу кийинки жаңыртуунун эски божомолдордун документтелбеген аралашмасын калтырууга жол бербейт.