Docker порттарын жариялау және VPN көздері: өткізіп жіберетін екі сәйкестік

Ереже VPN серверінің мекенжайын жарияланған қызметке рұқсат етіңіз дейді, ал қосылым бәрібір үзіледі. Бұл нәтиже жиі кездеседі және Docker ақауы емес. Екі бөлек сәйкестік қате: сіз жазған көз хост қабылдайтын көз болмауы мүмкін, ал сіз жазған порт сүзгі көретін порт болмауы мүмкін. Екеуін де түзету үшін қызмет схемасына емес, пакеттің жолына қарау керек.

Аңыз: VPN серверіне рұқсат бердіңіз — бітті

Маршрутталған VPN клиенттің туннель мекенжайын Docker хостіне дейін сақтай алады. Көзді аударатын шлюз бұл мекенжайды өзінікімен алмастыра алады. Екі құрылым да заңды және бір пайдаланушы әрекетіне әртүрлі көз береді.

Сондықтан 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 саясатты басқаша біріктіреді.