DNAT у кантэйнеры VPN: перанакіраванне, а не INPUT

Пасля DNAT запыт да адрасу тунеля робіцца перанакіраваным трафікам. Абмяжуйце правіла перанакіравання, прачытайце ланцуг Docker і свядома выберыце зваротны шлях.

Запыт прыходзіць з адрасам IP тунеля і пакідае той жа кантэйнер з адрасам суседняй службы. Паміж гэтымі двума момантамі DNAT перапісаў прызначэнне, і пакет перастаў быць уваходам для кантэйнера VPN. Цяпер гэта перанакіраваны трафік, які ацэньваецца іншым правілам. Гэтая змена тлумачыць, чаму правіла міжсеткавага экрана, якое выглядае слушным для адрасу тунеля, не ўплывае на ператворанае злучэнне.

Прасочыце пакет пасля пераўтварэння

Вазьміце пул кліентаў 10.90.0.0/24 і адрас тунеля 10.90.0.1. Два кантэйнеры стаяць на адным мосце: 192.0.2.2 запускае VPN, а 192.0.2.3 запускае праграму. Кліент падключаецца да 10.90.0.1:8080, і правіла DNAT у прасторы імёнаў кантэйнера VPN перапісвае гэта на рэальны адрас і порт праграмы. Потым маршрут адпраўляе пакет праз мост. Гэтыя адрасы паказальныя, а не рэцэпт разгортвання.

Порт, на якім праграма фактычна слухае, можа адрознівацца ад любога порта, апублікаванага на хастэ. Чытайце слухача ўнутры кантэйнера, а не выказвайце здагадку, што абодва нумары супадаюць.

Дазвол належыць шляху перанакіравання

Кантэйнеру VPN патрэбна перанакіраванне IP і рашэнне аб перанакіраванні, абмежаванае пулам кліентаў, адрасам праграмы і патрэбным портам. Усталяваныя адказы патрабуюць уласнага дазволу. Правіла, якое супадае з першапачатковым адрасам тунеля, не супадзе пасля DNAT, бо прызначэнне ўжо змянілася. Дазвол INPUT — няправільны крук для трафіку, які ўжо не адрасаваны гэтаму хасту.

Трымайце ахоп вузкім: адзін дыяпазон крыніц, адно прызначэнне, адна служба. Дазвольнае правіла перанакіравання лёгка напісаць і значна цяжэй потым абараніць.

docker exec vpn-container ip route get 192.0.2.3
docker exec vpn-container iptables -t nat -S
docker exec vpn-container iptables -S FORWARD

Ланцугі Docker не з'яўляюцца ланцугамі вашага кантэйнера

Правілы ўнутры прасторы імёнаў кантэйнера не з'яўляюцца правіламі хаста Docker. Калі трафік пераходзіць з інтэрфейса тунеля на мост, міжсеткавы экран моста хаста можа прыняць іншае рашэнне. У выпадку бэкенда iptables у Docker дакументаваныя ланцугі перанакіравання і пункты супастаўлення пасля DNAT — менавіта там гэта рашэнне і з'яўляецца.

Даведка Docker па міжсеткавым экране апісвае гэтыя ланцугі і супастаўленне пасля DNAT. Не выпраўляйце адсутны дазвол адключэннем кіравання міжсеткавым экранам Docker або зрабіўшы кожны ланцуг дазвольным, бо гэта прыбірае мяжу, якую вы спрабуеце выкарыстаць.

Зрабіце зваротны шлях свядомым выбарам

Калі адрас крыніцы захаваны, праграма бачыць 10.90.0.x і павінна накіроўваць адказы назад праз кантэйнер VPN. Інакш звычайны шлюз Docker адправіць іх на хаст, які не валодае тунелем. Альтэрнатыва — вузкае пераўтварэнне крыніцы на кантэйнеры VPN, якое спрашчае адказ, але хавае кліента ад праграмы. Выбірайце свядома і запішыце, які варыянт абралі.

Праверце новае дазволенае злучэнне са звычайнага кліента, затым пераканайцеся, што непавязаныя парты застаюцца закрытымі. Калі пакет знікае, агледзіце прастору імёнаў VPN, прастору імёнаў праграмы і ўласны журнал праграмы. Пінг да шлюза моста не з'яўляецца тэстам прыёмкі для службы.

Трымайце правілы ў падтрымоўванай канфігурацыі запуску кантэйнера, бо інтэрактыўныя змены знікаюць пры яго перастварэнні. Публікацыя порта на хастэ — іншы шлях уздзеяння, і яна не патрэбна толькі таму, што служба дасягальная праз тунель.

Падобныя артыкулы