Хостът стига до IPsec партньора, Docker контейнерът не

Правите ping към отдалечения хост от машината Linux и той отговаря, значи тунелът работи. Контейнерът до вас все още изтича по време, а естествената следваща стъпка е рестарт на Docker. Контейнер в мостова мрежа обикновено започва с друг адрес на източника и влиза в хоста през препращане, а не през собствения изходен път на приложението на хоста, затова успешният тест измери друг пакет. За тунел strongSwan, базиран на политика, обикновен маршрут към отдалечената подмрежа не е достатъчен, когато препратеният пакет не съответства на инсталираната IPsec политика.

Ръководството по-долу проследява една дестинация през два източника, като чете състоянието, преди да промени нещо.

Започнете с една дестинация и два източника

Първо изберете известна услуга по IP, за да не отстранявате едновременно проблеми с DNS. Запишете три факта: мостовия префикс на контейнера, адреса на източника на успешната заявка от хоста и договорените локални и отдалечени селектори на трафик за тунела. Тези три числа обясняват почти всеки случай на този симптом.

След това повторете неуспешната заявка отвътре в контейнера и уловете източника, който той наистина използва. Ако този адрес не е покрит от локалния селектор, вече знаете резултата и никакво пресъздаване на контейнера няма да го промени.

Прочетете политиките, преди да пипате Docker

Проверките на хоста само за четене покриват решенията за маршрутизиране, базата с политики и правилата, които избират между тях:

ip rule show
ip route show table all
ip xfrm policy

Списъкът с политики показва селектори и посока без нужда от изхвърляне на IPsec състояние, пълно с ключов материал, затова е безопасно да го поставите в тикет. Търсете локален селектор, който покрива адреса на хоста, но не мостовия префикс. Проверете и застъпването: маршрут на контейнера, който третира отдалечената дестинация като локална, никога няма да произведе очаквания препратен пакет и тунелът е обвинен. Запазете списъка до адреса на източника на контейнера, защото двете заедно са цялото сравнение.

Ако липсва префиксът на контейнера, спрете и решете архитектурата, преди да редактирате друго. Останалата част от ръководството предполага, че сте се разбрали кой адрес на източника трябва да се появи в мрежата.

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

Мостовата защитна стена на Linux в Docker може да блокира препращането независимо от IPsec. С backend iptables прегледайте пътя FORWARD и решенията DOCKER-USER, като помните, че правило, добавено след по-ранна присъда, може никога да не се изпълни. Backend nftables се интегрира различно, затова не създавайте верига DOCKER-USER само защото пример с iptables я е нарекъл така; проверете кой backend вашият демон наистина използва.

След това проверете превода на източника. Широко правило MASQUERADE може да превърне пакет, който преди е съответствал на IPsec селектор, в такъв, който вече не съответства, и отказът изглежда точно като проблем с маршрутизирането. ръководството за препращане на strongSwan документира NAT изключението, необходимо преди такъв превод за трафик, който вече съответства на политика.

Това изключение не е начин да добавите непокрит източник на контейнера към тунела. То защитава само трафик, който вече пасва на дизайна, затова първо решете въпросите за селектора и обратния път, а после съгласувайте NAT и филтрирането с отговора. Ако започнете да разширявате изключението, това, което трябва да се промени, е селекторът, а не правилото NAT.

След това решете маршрутизирано или преведено

Маршрутизирана подмрежа на контейнера изисква двата партньора да приемат тази подмрежа и отдалечен обратен път до нея, което обикновено означава промяна на селектора в двата края и разговор със собственика на далечната страна. Умишлено преведеният дизайн вместо това трябва да представи адрес, покрит от политиката, на съответния етап на търсене, което обикновено означава тясно, документирано правило вместо подразбиращо се MASQUERADE.

Нито едно от двете решения не следва автоматично от работещия тунел на хоста, а изборът между тях е проектно решение с собственик. Запишете кое сте избрали, иначе следващият инженер ще го изведе отново от броячите на защитната стена.

Внимавайте и за хибридния отказ: половината набор от правила преведени, половината не, което дава периодичен успех, зависещ от порта на дестинацията, а не от нещо в мрежата.

Проверявайте с нова връзка, не с рестарт

Използвайте нова връзка на приложението, докато наблюдавате тесни броячи на защитната стена и отдалечения получател, за да има всяко наблюдение източник. Рестарт на Docker може да промени състоянието на правилата и също ще смути работните натоварвания, което ви лишава от чистия сигнал, който сте искали.

Трайният резултат са четири твърдения, които можете да покажете: източникът на контейнера, съответстващият защитен път, разрешеното препращане и отговор, който се връща. Когато и четирите са валидни, контейнерът стига до партньора по същата причина като хоста.