Хост дасягае IPsec-партнёра, Docker-кантэйнер не

Вы пінгуеце аддалены хост з машыны Linux, і ён адказвае, значыць тунель працуе. Кантэйнер побач усё яшчэ выходзіць па тайм-аўце, а натуральны наступны крок — перазапусціць Docker. Кантэйнер у маставой сетцы звычайна пачынаецца з іншага адрасу крыніцы і ўваходзіць у хост праз перанакіраванне, а не праз уласны выхадны шлях праграмы на хосце, таму паспяховы тэст вымераў іншы пакет. Для тунеля strongSwan на аснове палітыкі звычайнага маршруту да аддаленай падсеткі недастаткова, калі перанакіраваны пакет не адпавядае ўсталяванай палітыцы IPsec.

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

Пачніце з адной мэты і дзвюх крыніц

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

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

Прачытайце палітыкі, перш чым чапаць Docker

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

ip rule show
ip route show table all
ip xfrm policy

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

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

Праверце фільтраванне і пераклад па парадку

Моставы файрвол Linux у Docker можа блакаваць перанакіраванне незалежна ад IPsec. З бэкэндам iptables агледзьце шлях FORWARD і рашэнні DOCKER-USER, памятаючы, што правіла, дададзенае пасля ранейшага вердыкту, можа ніколі не выканацца. Бэкэнд nftables інтэгруецца інакш, таму не стварайце ланцуг DOCKER-USER толькі таму, што прыклад iptables так яго назваў; праверце, які бэкэнд ваш дэман сапраўды выкарыстоўвае.

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

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

Потым вырашыце: маршрутызавана ці перакладзена

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

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

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

Правярайце новым злучэннем, а не перазапускам

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

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