Docker портторун жарыялоо жана VPN булактары: өткөрүп жиберген эки дал келүү

Эреже VPN серверинин дарегин жарыяланган кызматка уруксат бериңиз дейт, бирок байланыш баары бир үзүлөт. Мындай жыйынтык кеңири таралган жана Docker катасы эмес. Эки өзүнчө дал келүү туура эмес: сиз жазган булак хост кабыл алган булак болбошу мүмкүн, ал эми сиз жазган порт чыпка көргөн порт болбошу мүмкүн. Экөөнү тең оңдоо үчүн кызматтын схемасына эмес, пакеттин жолуна кароо керек.

Уламыш: VPN серверине уруксат бердиңиз — бүттү

Маршрутталган VPN кардардын туннель дарегин Docker хостyна чейин сактай алат. Булакты которуучу шлюз бул даректи өзүнүкү менен алмаштыра алат. Эки курулуш тең мыйзамдуу жана бир колдонуучу аракетине ар кандай булактарды берет.

Ошондуктан VPN серверинин IP деген сүйлөм божомолду сүрөттөйт, байкоону эмес. Алдыңызда эки курулуштун кайсынысы турганын билмейинче, эреже божомол бойдон калат.

Булак: кардарлар пулу же которулган шлюз

Төрт нерсени ирети менен текшериңиз. Биринчи, кардар даректеринин пулу, мисал үчүн 10.90.0.0/24. Экинчи, шлюз бул пулду хостко жетпей туруп которобу. Үчүнчү, хост бир жаңы байланыш үчүн чындап эмнени байкайт. Төртүнчү, колдонмо аутентификациясы жеке колдонуучуларды ажыратабы, анткени жалпы которулган дарек муну кыла албайт.

Эгер пул сакталса, шлюздун гана коомдук дарегине дал келген эреже ар бир кардарды өткөрүп жиберет. Эгер шлюз атайын которсо, которулган дарекке уруксат анын артындагы ар бир колдонуучуну киргизет, бул өз кирүүсү бар кызмат үчүн кабыл алынардык, ал эми калган нерселердин баары үчүн кабыл алынбастык болушу мүмкүн.

Порт: DNAT салыштырган санды өзгөртөт

Docker iptables менен кадимки Linux көпүрөсү аркылуу жарыялоодо хосттун 8443төн контейнердин 443 портуна салыштыруусу багыттоо чыпкасы иштегенге чейин которулат. Пакет чыпкага 443 багытындагы порт менен жетет. Ошол учурда 8443кө дал келген эреже эч качан иштебейт, кардар тергени 8443 болсо да.

Жарыяланган порт байланыштарды көзөмөлдөөдө дагы деле бар, ошондуктан чынында керек болгондо баштапкы багытты ошол жерден салыштырууга болот.

Кайсы сан ниетти билдирерин чечиңиз. Эреже контейнердин ичиндеги кызматты коргосо, DNATтан кийинки контейнер портуна салыштырыңыз. Эреже кардар эмнени сураганын сүрөттөшү керек болсо, conntrack параметри менен баштапкы багытка салыштырыңыз жана аны менен келген кошумча салыштыруу чыгымын жана эреже тартибине болгон кылдаттыкты кабыл алыңыз.

Чынжыр: DOCKER-USER, INPUT эмес

Dockerдин iptables колдонмосу колдонуучунун багыттоо саясатын DOCKER-USER чынжырына коёт, ал Dockerдин өзүнүн багыттоо эрежелеринен мурун бааланат. Хост кызматынан INPUT чынжырына көчүрүлгөн эреже хостко багытталган трафикти чыпкалайт, контейнерге багытталган трафикти эмес. Бул ката туура көрүнгөн жана контейнердин жолуна эч кандай таасири жок эрежени жаратат.

Булактын диапазонун, натыйжалуу багыт портун, протоколду жана кирүү интерфейсин бир эрежеде чогуу кармаңыз. Ар бир багытталган багыт үчүн булакка гана негизделген уруксат бир жарыяланган кызматка уруксат берүүдөн кененирээк.

Жаңы байланыштар менен текшериңиз

Эки багытты тең жаңы байланыштар менен сынаңыз: бир уруксат берилген VPN кардары жана баш тартылган бойдон калышы керек болгон бир булак. Учурдагы байланыш абалы саясат өзгөргөндөн кийин сессияны тирүү кармай алат, ошондуктан эски байланыш жаңы эреже жөнүндө эч нерсени далилдебейт. Андан кийин жооп жолун текшериңиз, анткени контейнер дагы эле өзү көргөн булакка карай артка багытталышы керек.

Бул текшерүүлөрдүн артындагы чынжырлардын тартибин жана порт которуу жүрүм-турумун Dockerдин iptables колдонмосу сүрөттөйт. Рецепт көчүрүүдөн мурун аны окуп чыгыңыз жана орнотулган Docker кайсы backendди колдонорун ырастаңыз, анткени nftables backend саясатты башкача бириктирет.