Домаќинот стигнува до 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 backend, прегледајте ја патеката FORWARD и одлуките DOCKER-USER, имајќи на ум дека правило додадено по претходна пресуда може никогаш да не се изврши. nftables backend се интегрира поинаку, затоа не создавајте DOCKER-USER синџир само затоа што пример за iptables го нарече така; проверете кој backend вашиот демон навистина го користи.

Потоа проверете го преводот на изворот. Широко MASQUERADE правило може да претвори пакет што претходно одговарал на IPsec селектор во таков што веќе не одговара, а дефектот изгледа точно како проблем со рутирање. водичот за препраќање на strongSwan го документира NAT исклучокот потребен пред таков превод за сообраќај што веќе одговара на политика.

Тој исклучок не е начин да се додаде непокриен извор на контејнер во тунелот. Тој штити само сообраќај што веќе одговара на дизајнот, затоа прво решете ги прашањата за селекторот и повратната патека, а потоа усогласете ги NAT и филтрирањето со одговорот. Ако почнете да го проширувате исклучокот, она што треба да се смени е селекторот, не NAT правилото.

Потоа одлучете рутирано или преведено

Рутирана подмрежа на контејнер бара двата партнера да ја прифатат таа подмрежа и да постои далечинска повратна патека до неа, што обично значи промена на селекторот на двата краја и разговор со сопственикот на далечната страна. Намерно преведен дизајн пак мора да прикаже адреса покриена со политиката во соодветната фаза на пребарување, што обично значи тесно, документирано правило наместо стандардно MASQUERADE.

Ниту едно од двете уредувања не произлегува автоматски од работниот тунел на домаќинот, а изборот меѓу нив е дизајнерска одлука со сопственик. Запишете кое го избравте, инаку следниот инженер повторно ќе го изведе од бројачите на огнениот ѕид.

Внимавајте и на хибридниот дефект: половина од множеството правила преведени, половина не, што дава повремен успех зависен од одредишниот порт, а не од нешто на мрежата.

Проверете со нова врска, не со рестарт

Користете нова врска на апликацијата додека гледате тесни бројачи на огнениот ѕид и далечинскиот примач, така што секое набљудување има извор. Рестартот на Docker може да ја смени состојбата на правилата и исто така ќе ги наруши работните оптоварувања, што ве лишува од чистиот сигнал што сакавте да го добиете.

Трајниот резултат се четири тврдења што можете да ги покажете: изворот на контејнерот, соодветната заштитена патека, дозволеното препраќање и одговор што се враќа. Кога сите четири важат, контејнерот стигнува до партнерот од истата причина како домаќинот.