Публікацыя портаў Docker і крыніцы VPN: два супадзенні, якія вы прапускаеце

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

Міф: дазвольце сервер VPN — і ўсё гатова

Маршрутызаваны VPN можа захоўваць адрас тунэля кліента аж да хоста Docker. Шлюз, які выконвае трансляцыю крыніцы, можа замяніць гэты адрас сваім. Абедзве схемы законныя, і яны даюць розныя крыніцы для аднаго і таго ж дзеяння карыстальніка.

Такім чынам, фраза IP сервера VPN апісвае здагадку, а не назіранне. Пакуль вы не ведаеце, якая з дзвюх схем перад вамі, правіла застаецца здагадкай.

Крыніца: пул кліентаў або трансляваны шлюз

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

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

Порт: DNAT змяняе лік, з якім вы супастаўляеце

Для звычайнай публікацыі праз мост Linux з Docker iptables адлюстраванне хоста з 8443 на порт кантэйнера 443 транслюецца да таго, як запрацуе фільтр перасылкі. Пакет прыходзіць да фільтра з портам прызначэння 443. Правіла, якое супадае з 8443 у гэты момант, ніколі не спрацоўвае, нават калі 8443 — гэта тое, што набраў кліент.

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

Вызначце, які лік выражае намер. Супастаўляйце порт кантэйнера пасля DNAT, калі правіла абараняе сэрвіс унутры кантэйнера. Супастаўляйце зыходнае прызначэнне з опцыяй conntrack, калі правіла павінна апісваць тое, што запытаў кліент, і прыміце дадатковыя выдаткі на супастаўленне і асцярожнасць з парадкам правілаў, якія з гэтым ідуць.

Ланцуг: DOCKER-USER, а не INPUT

Кіраўніцтва Docker па iptables змяшчае палітыку перасылкі карыстальніка ў ланцуг DOCKER-USER, які ацэньваецца перад уласнымі правіламі перасылкі Docker. Правіла, скапіяванае з хост-сэрвісу ў ланцуг INPUT, фільтруе трафік, адрасаваны хосту, а не трафік, які перасылаецца ў кантэйнер. Гэтая памылка дае правіла, якое выглядае правільным і не ўплывае на шлях кантэйнера.

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

Правярайце новымі злучэннямі

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

Парадак ланцугоў і паводзіны трансляцыі порта за гэтымі праверкамі апісвае кіраўніцтва Docker па iptables. Прачытайце яго перад капіяваннем рэцэпту і пацвердзіце, які бэкенд выкарыстоўвае ўсталяваны Docker, бо бэкенд nftables інтэгруе палітыку інакш.