Profil WireGuard pre bránu IPsec: na čo sa radšej opýtať

Časové limity handshake pri tichej bráne zvyčajne znamenajú dva protokoly, ktoré sa nikdy nestretnú. Peer WireGuard hovorí Noise, zatiaľ čo brána IPsec čaká na IKE. Správna adresa a port to nezmenia.

Opätovné použitie koncového bodu v profile oba nepremostí. Ďalším krokom je žiadosť na toho, kto bránu prevádzkuje.

Prvá žiadosť: verzia protokolu

IPsec označuje rodinu, nie jediný pracovný postup. IKEv2 a IKEv1 sa líšia vo svojich výmenách, možnostiach overovania a správaní pri zmene siete. Brána, ktorá ukončuje iba IKEv1, sa bude správať úplne inak ako tá, ktorá ponúka IKEv2. Konfigurácia klienta sa tým líši.

Opýtajte sa, ktorú verziu služba ukončuje a či prevádzkuje implementáciu založenú na štandardoch alebo variant dodávateľa s vlastným klientom. Ponuky operačných systémov túto odpoveď často skrývajú za jediným označením. Označenie nie je protokol.

Druhá žiadosť: metóda overovania klienta

Overovanie je miesto, kde leží väčšina skutočnej práce. Služba môže očakávať strojový certifikát s určitým rozšíreným použitím kľúča, používateľský certifikát, metódu EAP cez IKEv2 alebo vopred zdieľaný kľúč viazaný na identitu. Ktorá platí, určuje, čo klient potrebuje.

Súkromný kľúč WireGuard nie je nič z toho. Je to kľúč Curve25519 používaný v jednom konkrétnom handshake. Žiadna konverzia z neho neurobí certifikát ani prihlasovací údaj EAP. Nástroj, ktorý tvrdí opak, premenúva súbor alebo generuje niečo nesúvisiace.

Špecifikácia IKEv2 v RFC 7296 opisuje, čo musí implementácia tejto verzie podporovať. Je to referencia pre neurčitú odpoveď operátora, nie návod na konfiguráciu klienta.

Tretia žiadosť: dôveryhodná identita a ciele

Vyžiadajte si identitu brány tak, ako ju klient musí vidieť, a k tomu kotvu dôvery, ktorá ju overuje. Potom sa opýtajte, ktoré súkromné rozsahy a prekladače služba posiela. Tie dve odpovede určujú, čo tunel skutočne prenáša.

Bez nich môže funkčné spojenie v úlohe napriek tomu zlyhať. Tunel, ktorý je hore bez odoslaného prekladača, necháva interné názvy nezodpovedané. Chýbajúci selektor prevádzky necháva cieľ mimo tunela, aj keď handshake uspel.

Sonda koncového bodu odpovedá na inú otázku ako chyba klienta. Dostupný port bez asociácie ukazuje na overovanie, zatiaľ čo 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

Vykonajte túto sondu skôr, než v klientovi čokoľvek zmeníte. Ak porty odpovedajú a asociácia stále zlyháva, problém je v prihlasovacích údajoch alebo v pravidlách. Ak neodpovedajú vôbec, žiadna úprava profilu nepomôže.

Keď musia oba protokoly koexistovať

Správa oboch sietí je oprávnený dôvod oba protokoly zachovať. Zvyčajné riešenie ukončuje WireGuard a IPsec na samostatných rozhraniach alebo samostatných bránach. Schválená prevádzka sa potom smeruje medzi nimi.

Toto riešenie zavádza hranicu dôvery a autorizácie a malo by byť takto zaznamenané. Ktorí partneri smú prejsť, ktorým smerom a podľa čej politiky, je rozhodnutie o smerovaní a firewalle. Ani jeden z protokolov to nedodáva.

Čo to nie je, je priehľadná konverzia. Prevádzka prichádzajúca cez WireGuard sa znovu vytvára do tunela IPsec a každé pravidlo medzi tým sa na ňu vzťahuje.

Najprv si ujasnite požiadavky servera na protokol a overovanie. Potom použite klienta a cestu registrácie, ktoré operátor podporuje, a súkromné kľúče pritom držte mimo webových prevodníkov.