Plný tunel v strongSwanu vyžaduje 0.0.0.0/0 na obou stranách

Plný tunel potřebuje 0.0.0.0/0 jako remote_ts klienta a jako local_ts brány, navíc forwarding, NAT a zpětnou trasu. Zkontrolujte všechny čtyři.

Připojení strongSwan, které funguje pro jednu privátní podsíť, nebude přenášet internetový provoz jen proto, že někdo upravil jeden řádek. Plný tunel je dohoda mezi dvěma stranami o tom, které adresy child SA chrání, a každá strana pojmenovává druhou stranu vzhledem k sobě. Nastavte jednu stranu správně a druhou špatně a child SA buď nevznikne, nebo vznikne užší, než bylo zamýšleno. Pět kontrol níže sleduje tuto dohodu od klienta přes bránu až ven k internetu.

Nejprve zkontrolujte selektor klienta

Klient popisuje, co chce chránit na vzdálené straně, jako remote_ts, a vše, co odesílá, vychází z jeho vlastní přidělené adresy. Pro internetový provoz musí tato hodnota pokrývat cíle, kterých uživatel skutečně dosáhne, což v praxi znamená celý prostor IPv4. Klient, který stále uvádí jednu podsíť, žádá rozdělený tunel, ať se profil v rozhraní jmenuje jakkoli. Strana zdroje je obvykle dynamic, protože adresa se přiděluje při připojení. Pevný zdroj zapsaný tam se rozbije, jakmile se změní fond adres.

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

Fragment není úplný soubor připojení a tento předpokládá, že autentizace, identity a fond virtuálních adres jsou už nastavené. Selektor zdroje na klientovi a adresa, kterou přiděluje server, se stále musejí shodovat, jinak child SA vznikne s rozsahem, který žádná strana neočekávala. Načtěte ho pomocí swanctl --load-all a přečtěte výstup, než budete předpokládat úspěch. Soubor, který se parsuje, může být přesto odmítnut kvůli selektoru, který se nepřekrývá s návrhem protistrany.

Zkontrolujte selektor brány na její straně

Brána čte stejný pojem z opačného směru. Internetové cíle jsou pro bránu lokální, takže její local_ts je ten široký a remote_ts popisuje fond klientů. Tato inverze je nejčastější chyba v konfiguraci plného tunelu a projde revizí, protože oba řádky vypadají samostatně věrohodně.

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

Zkopírování fragmentu klienta do souboru brány vytvoří pár selektorů, který nepopisuje nic užitečného, protože obě strany by si nárokovaly stejnou roli. Průvodce forwardingem strongSwan výslovně dokumentuje párování klienta a brány a stojí za to ho číst vedle souboru připojení, ne až po selhání. Soubor brány také potřebuje definici fondu, na kterou odkazuje remote_ts. Selektor pojmenovávající neexistující fond se načte bez stížnosti a selže při připojení.

Starší ipsec.conf používá levé a pravé role s různými klíči a řádek rightsubnet není přímou náhradou hodnoty swanctl. Udržujte obě syntaxe v oddělených souborech, místo abyste jednu vkládali do druhé. Míchání v jednom adresáři je způsob, jak funkční připojení po restartu tiše přejde do starého stavu.

Zkontrolujte vyjednaný child SA, ne soubor

S uloženou konfigurací prokazujete záměr a nic víc. Protistrana může zúžit požadované a existující child SA se nenahradí jen proto, že se soubor pod ním změnil. Než změníte cokoli dalšího, potvrďte, co je skutečně nainstalováno.

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

První příkaz ukazuje, co daemon načetl, druhý ukazuje navázané child SA a třetí politiky, které jádro použije. Pokud soubor říká 0.0.0.0/0 a výpis ukazuje jednu podsíť, vyjednávání zúžilo rozsah a opětovné čtení souboru to nevysvětlí. Ukončete child, znovu jej spusťte a znovu porovnejte všechny tři výstupy. Child, který se vrátí se stejným úzkým rozsahem, zužuje vzdálená strana, ne místní soubor, a to je rozhovor s druhým administrátorem, ne místní úprava.

Čtěte oba směry ve výpisu politik, protože tunel, který instaluje jeden směr a ne druhý, je problém směrování v kostýmu konfigurace. Politiky vpřed a zpět mají pojmenovat stejný pár selektorů v zrcadlovém obraze a chybějící zrcadlo je vada daemonu nebo návrhu, ne textu selektoru.

Zkontrolujte forwarding a zpětnou trasu

Selektor propouští provoz k bráně; nezpůsobuje, že brána tento provoz dál směruje. Forwarding musí být zapnutý, firewall musí tok povolit a odpověď musí najít cestu zpět do fondu klientů. To jsou tři samostatné požadavky a každý selhává s jiným příznakem. Chybějící pravidlo forwardingu se chová jako černá díra, zatímco chybějící zpětná trasa jako jednosměrný tunel.

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

Privátní adresy klientů obvykle vyžadují záměrný překlad zdroje, než mohou opustit veřejné rozhraní, zatímco výslovně směrované přidělení vyžaduje jiný postup. Pokud je ve hře NAT, zachovejte výjimky, které implementace podporuje, aby se provoz, který má bezpečnostní politika prohlédnout, nepřekládal mimo ni. Široké pravidlo masquerade zkopírované z jiné brány mění mnohem více toků, než jeho autor zamýšlel. Napište pravidlo jen pro fond klientů a nechte komentář vysvětlující, proč existuje.

Na klientovi potvrďte trasy, které nainstaloval backend, ne trasy, které jste předpokládali. Správce s vypnutou instalací tras potřebuje ručně udržovaný návrh směrování a ten se musí aktualizovat při každé změně tunelu. Zkontrolujte směrovací tabulku po opětovném připojení, ne jen po čerstvém startu.

Zkontrolujte, co tunel stále nepokrývá

Pár selektorů pokrývá IPv4 a nic jiného. IPv6, DNS a jakákoli politika na úrovni aplikace jsou samostatná rozhodnutí, která široký selektor IPv4 tiše ignoruje. Tunel, který přenáší každý paket IPv4, může stále unikat každé hledání jména.

Výslovně uveďte zamýšlenou cestu DNS, protože plný tunel, který stále překládá jména přes místní resolver, uniká dotazy mimo tunel a rozbíjí privátní jména. Pokud klient dostane adresu IPv6, tato rodina adres potřebuje stejné zacházení, jinak host upřednostní cestu, kterou tunel nechrání. Testujte jménem, na které může odpovědět jen privátní strana, a veřejnou odpověď považujte za únik.

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

Potvrďte řetěz těmito dvěma příkazy plus vyjednanými selektory z výpisu výše. Pokud traceroute ukáže místní router jako první skok, provoz tunel nepoužívá, ať selektory tvrdí cokoli. Přístup k internetu je úplný jen tehdy, když je zvolený provoz přijat, přeposlán a vrácen přes navrženou bránu. Nalézt 0.0.0.0/0 v profilu je začátek tohoto řetězu, ne jeho důkaz.

Související články