Host dosáhne na IPsec protějšek, kontejner Dockeru ne

Pingnete vzdálený hostitel z linuxového stroje a on odpovídá, takže tunel funguje. Kontejner vedle vás stále končí časovým limitem a přirozeným dalším krokem je restart Dockeru. Kontejner na mostové síti obvykle začíná s jinou zdrojovou adresou a do hostitele vstupuje přes forwarding, nikoli vlastní výstupní cestou aplikace na hostiteli, takže úspěšný test měřil jiný paket. U tunelu strongSwan založeného na politice nestačí obyčejná trasa ke vzdálené podsíti, když forwardovaný paket neodpovídá nainstalované politice IPsec.

Následující postup sleduje jeden cíl přes dva zdroje a čte stav dřív, než cokoli změní.

Začněte jedním cílem a dvěma zdroji

Nejprve zvolte známou službu podle IP, abyste zároveň neladili DNS. Zapište tři skutečnosti: mostový prefix kontejneru, zdrojovou adresu požadavku hostitele, který prošel, a vyjednané místní a vzdálené selektory provozu pro tunel. Ta tři čísla vysvětlují téměř každý případ tohoto příznaku.

Pak zopakujte neúspěšný požadavek zevnitř kontejneru a zachyťte zdroj, který skutečně používá. Pokud tuto adresu místní selektor nepokrývá, výsledek už znáte a žádné znovuvytvoření kontejneru to nezmění.

Přečtěte politiky dřív, než se dotknete Dockeru

Kontroly hostitele jen pro čtení pokrývají rozhodnutí směrování, databázi politik a pravidla, která mezi nimi vybírají:

ip rule show
ip route show table all
ip xfrm policy

Výpis politik ukazuje selektory a směr, aniž byste potřebovali výpis stavu IPsec plný klíčového materiálu, a proto je bezpečné ho vložit do tiketu. Hledejte místní selektor, který pokrývá adresu hostitele, ale ne mostový prefix. Zkontrolujte také překryv: trasa kontejneru, která vzdálený cíl považuje za místní, nikdy nevytvoří forwardovaný paket, který očekáváte, a tunel za to dostane vinu. Uložte ten výpis vedle zdrojové adresy kontejneru, protože ty dvě věci dohromady tvoří celé srovnání.

Když prefix kontejneru chybí, zastavte se a rozhodněte architekturu dřív, než upravíte cokoli dalšího. Zbytek tohoto postupu předpokládá, že jste se shodli, která zdrojová adresa se má objevit na drátě.

Zkontrolujte filtrování a překlad popořadě

Linuxový mostový firewall Dockeru může blokovat forwarding nezávisle na IPsec. S backendem iptables prohlédněte cestu FORWARD a rozhodnutí DOCKER-USER a pamatujte, že pravidlo přidané po dřívějším verdiktu se nemusí nikdy spustit. Backend nftables se integruje jinak, takže nevytvářejte řetěz DOCKER-USER jen proto, že ho pojmenoval příklad pro iptables; zkontrolujte, který backend váš démon skutečně používá.

Pak zkontrolujte překlad zdroje. Široké pravidlo MASQUERADE může přeměnit paket, který dřív odpovídal selektoru IPsec, na paket, který už neodpovídá, a porucha vypadá přesně jako problém směrování. průvodce forwardingem strongSwan dokumentuje výjimku z NAT potřebnou před takovým překladem pro provoz, který už politice odpovídá.

Ta výjimka není způsob, jak do tunelu přidat nepokrytý zdroj kontejneru. Chrání jen provoz, který už do návrhu zapadá, takže nejdřív vyřešte otázky selektoru a zpáteční cesty a pak sladěte NAT a filtrování s odpovědí. Pokud začnete výjimku rozšiřovat, měnit se má selektor, ne pravidlo NAT.

Pak rozhodněte, zda routované, nebo překládané

Routovaná podsíť kontejneru vyžaduje, aby oba protějšky tuto podsíť přijaly, a vzdálenou zpáteční cestu k ní, což obvykle znamená změnu selektoru na obou koncích a rozhovor s vlastníkem vzdálené strany. Záměrně překládaný návrh naopak musí v příslušné fázi vyhledávání předložit adresu pokrytou politikou, což obvykle znamená úzké, zdokumentované pravidlo místo výchozího MASQUERADE.

Ani jedno uspořádání nevyplývá automaticky z fungujícího tunelu hostitele a volba mezi nimi je návrhové rozhodnutí s vlastníkem. Zapište, kterou jste zvolili, protože jinak ji příští inženýr znovu odvodí z čítačů firewallu.

Sledujte i hybridní poruchu: polovina sady pravidel přeložená a polovina ne, což dává občasný úspěch, který závisí na cílovém portu, a ne na ničem v síti.

Ověřte novým spojením, ne restartem

Použijte nové spojení aplikace a přitom sledujte úzké čítače firewallu a vzdálený příjemce, aby každé pozorování mělo zdroj. Restart Dockeru může změnit stav pravidel a také naruší úlohy, což vás připraví o čistý signál, který jste chtěli získat.

Trvalý výsledek jsou čtyři tvrzení, která můžete ukázat: zdroj kontejneru, odpovídající chráněná cesta, povolený forwarding a odpověď, která se vrací. Když platí všechna čtyři, kontejner dosáhne na protějšek ze stejného důvodu jako hostitel.