Host dociera do peera IPsec, kontener Docker nie

Pingujesz zdalny host z maszyny Linux i odpowiada, więc tunel działa. Kontener obok nadal kończy się przekroczeniem czasu, a naturalnym następnym krokiem jest restart Dockera. Kontener w sieci mostkowej zwykle startuje z innego adresu źródłowego i wchodzi do hosta przez forwarding, a nie przez własną ścieżkę wyjścia aplikacji na hoście, więc udany test zmierzył inny pakiet. Dla tunelu strongSwan opartego na politykach zwykła trasa do zdalnej podsieci nie wystarcza, gdy przekazywany pakiet nie pasuje do zainstalowanej polityki IPsec.

Poniższy przewodnik śledzi jeden cel przez dwa źródła, czytając stan przed zmianą czegokolwiek.

Zacznij od jednego celu i dwóch źródeł

Najpierw wybierz znaną usługę po IP, żeby nie debugować jednocześnie DNS. Zapisz trzy fakty: prefiks mostu kontenera, adres źródłowy udanego żądania z hosta oraz wynegocjowane lokalne i zdalne selektory ruchu tunelu. Te trzy liczby wyjaśniają prawie każdy przypadek tego objawu.

Potem powtórz nieudane żądanie z wnętrza kontenera i przechwyć źródło, którego naprawdę używa. Jeśli ten adres nie jest objęty lokalnym selektorem, znasz już wynik, a żadne odtworzenie kontenera tego nie zmieni.

Przeczytaj polityki, zanim dotkniesz Dockera

Kontrole hosta tylko do odczytu obejmują decyzje routingu, bazę polityk i reguły wybierające między nimi:

ip rule show
ip route show table all
ip xfrm policy

Lista polityk pokazuje selektory i kierunek bez zrzutu stanu IPsec pełnego materiału klucza, dlatego bezpiecznie wkleić ją do zgłoszenia. Szukaj lokalnego selektora obejmującego adres hosta, ale nie prefiks mostu. Sprawdź też nakładanie: trasa kontenera traktująca zdalny cel jako lokalny nigdy nie wytworzy oczekiwanego przekazywanego pakietu, a tunel zostaje obwiniony. Zachowaj tę listę obok adresu źródłowego kontenera, bo te dwie rzeczy razem to całe porównanie.

Jeśli brakuje prefiksu kontenera, zatrzymaj się i zdecyduj architekturę, zanim cokolwiek innego zmienisz. Reszta przewodnika zakłada, że uzgodniono, który adres źródłowy ma się pojawić w sieci.

Sprawdź filtrowanie i tłumaczenie po kolei

Firewall mostu Linux w Dockerze może blokować forwarding niezależnie od IPsec. Przy backendzie iptables sprawdź ścieżkę FORWARD i decyzje DOCKER-USER, pamiętając, że reguła dodana po wcześniejszym werdykcie może nigdy się nie wykonać. Backend nftables integruje się inaczej, więc nie twórz łańcucha DOCKER-USER tylko dlatego, że nazwał go przykład iptables; sprawdź, którego backendu naprawdę używa twój demon.

Potem sprawdź tłumaczenie źródła. Szeroka reguła MASQUERADE może zmienić pakiet, który wcześniej pasował do selektora IPsec, w taki, który już nie pasuje, a awaria wygląda dokładnie jak problem routingu. przewodnik forwardingu strongSwan dokumentuje wyjątek NAT potrzebny przed takim tłumaczeniem dla ruchu już zgodnego z polityką.

Ten wyjątek nie służy do dodawania nieobjętego źródła kontenera do tunelu. Chroni tylko ruch już zgodny z projektem, więc najpierw rozstrzygnij kwestie selektora i drogi powrotnej, a potem uzgodnij NAT i filtrowanie z odpowiedzią. Jeśli zaczniesz raczej rozszerzać wyjątek, zmieniać trzeba selektor, a nie regułę NAT.

Potem zdecyduj: routowane czy tłumaczone

Routowana podsieć kontenera wymaga, by oba peery akceptowały tę podsieć i by istniała zdalna droga powrotna do niej, co zwykle oznacza zmianę selektora po obu stronach i rozmowę z właścicielem dalszej strony. Projekt świadomie tłumaczony musi natomiast przedstawić adres objęty polityką na właściwym etapie wyszukiwania, co zwykle oznacza wąską, udokumentowaną regułę zamiast domyślnego MASQUERADE.

Żadne z tych rozwiązań nie wynika automatycznie z działającego tunelu hosta, a wybór między nimi jest decyzją projektową z właścicielem. Zapisz, które wybrano, bo inaczej następny inżynier wyprowadzi je ponownie z liczników firewalla.

Uważaj też na awarię hybrydową: połowa zestawu reguł przetłumaczona, połowa nie, co daje okresowe sukcesy zależne od portu docelowego, a nie od czegokolwiek w sieci.

Weryfikuj nowym połączeniem, nie restartem

Użyj nowego połączenia aplikacji, obserwując wąskie liczniki firewalla i zdalny odbiornik, żeby każde spostrzeżenie miało źródło. Restart Dockera może zmienić stan reguł i zakłóci też obciążenia, co odbiera ci czysty sygnał, który chciałeś uzyskać.

Trwałym wynikiem są cztery twierdzenia, które możesz pokazać: źródło kontenera, pasująca chroniona ścieżka, dozwolony forwarding i odpowiedź, która wraca. Gdy wszystkie cztery zachodzą, kontener dociera do peera z tego samego powodu co host.