Profil WireGuard pro bránu IPsec: na co se raději ptát

Časové limity handshake u tiché brány obvykle znamenají dva protokoly, které se nikdy nesetkají. Peer WireGuard mluví Noise, zatímco brána IPsec čeká na IKE. Správná adresa a port to nezmění.

Opětovné použití koncového bodu v profilu oba nepřemostí. Dalším krokem je žádost na toho, kdo bránu provozuje.

První žádost: verze protokolu

IPsec označuje rodinu, nikoli jediný pracovní postup. IKEv2 a IKEv1 se liší ve svých výměnách, možnostech ověřování a chování při změně sítě. Brána, která ukončuje pouze IKEv1, se bude chovat zcela jinak než ta, která nabízí IKEv2. Konfigurace klienta se tím liší.

Zeptejte se, kterou verzi služba ukončuje a zda provozuje implementaci založenou na standardech, nebo variantu dodavatele s vlastním klientem. Nabídky operačních systémů tuto odpověď často skrývají za jediným označením. Označení není protokol.

Druhá žádost: metoda ověřování klienta

Ověřování je místo, kde leží většina skutečné práce. Služba může očekávat strojový certifikát s určitým rozšířeným použitím klíče, uživatelský certifikát, metodu EAP přes IKEv2 nebo předem sdílený klíč vázaný na identitu. Která platí, určuje, co klient potřebuje.

Soukromý klíč WireGuard není nic z toho. Je to klíč Curve25519 používaný v jednom konkrétním handshake. Žádná konverze z něj neudělá certifikát ani přihlašovací údaj EAP. Nástroj, který tvrdí opak, soubor přejmenovává nebo generuje něco nesouvisejícího.

Specifikace IKEv2 v RFC 7296 popisuje, co musí implementace této verze podporovat. Je to reference pro neurčitou odpověď operátora, nikoli návod ke konfiguraci klienta.

Třetí žádost: důvěryhodná identita a cíle

Vyžádejte si identitu brány tak, jak ji klient musí vidět, a k tomu kotvu důvěry, která ji ověřuje. Poté se zeptejte, které privátní rozsahy a překladače služba předává. Tyto dvě odpovědi určují, co tunel skutečně přenáší.

Bez nich může funkční spojení v úkolu přesto selhat. Tunel, který je nahoře bez předaného překladače, nechává interní názvy nezodpovězené. Chybějící selektor provozu nechává cíl mimo tunel, i když handshake uspěl.

Sonda koncového bodu odpovídá na jinou otázku než chyba klienta. Dostupný port bez asociace ukazuje na ověřování, zatímco nedostupný port ukazuje na cestu.

# what does the endpoint offer on its IPsec ports?
sudo nmap -sU -p 500,4500 198.51.100.44

# strongSwan: what did the IKE exchange negotiate?
sudo swanctl --list-sas
sudo swanctl --list-conns

Proveďte tuto sondu dřív, než v klientovi cokoli změníte. Pokud porty odpovídají a asociace stále selhává, problém je v přihlašovacích údajích nebo v pravidlech. Pokud neodpovídají vůbec, žádná úprava profilu nepomůže.

Když musí oba protokoly koexistovat

Správa obou sítí je oprávněný důvod oba protokoly zachovat. Obvyklé řešení ukončuje WireGuard a IPsec na samostatných rozhraních nebo samostatných bránách. Schválený provoz se pak směruje mezi nimi.

Toto řešení zavádí hranici důvěry a autorizace a mělo by být takto zaznamenáno. Kteří partneři smějí přejít, kterým směrem a podle čí politiky, je rozhodnutí o směrování a firewallu. Ani jeden z protokolů to nedodává.

Co to není, je průhledná konverze. Provoz přicházející přes WireGuard se znovu vytváří do tunelu IPsec a každé pravidlo mezi tím se na něj vztahuje.

Nejprve si ujasněte požadavky serveru na protokol a ověřování. Pak použijte klienta a cestu registrace, které operátor podporuje, a soukromé klíče přitom držte mimo webové převodníky.