Profil WireGuard za prehod IPsec: kaj raje zahtevati

Časovne omejitve rokovanja s tihim prehodom običajno pomenijo dva protokola, ki se nikoli ne srečata. Vrstnik WireGuard govori Noise, medtem ko prehod IPsec čaka na IKE. Pravilen naslov in vrata tega ne spremenita.

Ponovna uporaba končne točke v profilu obeh ne poveže. Naslednji korak je zahteva tistemu, ki upravlja prehod.

Prva zahteva: različica protokola

IPsec označuje družino in ne enotnega delovnega toka. IKEv2 in IKEv1 se razlikujeta v izmenjavah, možnostih preverjanja pristnosti in vedenju ob spremembi omrežja. Prehod, ki zaključi samo IKEv1, se bo obnašal povsem drugače kot tisti, ki ponuja IKEv2. Konfiguracija odjemalca se spremeni z njim.

Vprašajte, katero različico zaključi storitev in ali izvaja standardno utemeljeno izvedbo ali ponudnikovo različico z lastnim odjemalcem. Meniji operacijskih sistemov pogosto skrijejo ta odgovor za eno samo oznako. Oznaka ni protokol.

Druga zahteva: metoda preverjanja pristnosti odjemalca

Preverjanje pristnosti je mesto, kjer je večina resničnega dela. Storitev lahko pričakuje strojno potrdilo z določeno razširjeno uporabo ključa, uporabniško potrdilo, metodo EAP prek IKEv2 ali vnaprej deljen ključ, vezan na identiteto. Katera velja, odloča, kaj odjemalec potrebuje.

Zasebni ključ WireGuard ni nič od tega. To je ključ Curve25519, ki se uporablja v enem določenem rokovanju. Nobena pretvorba ga ne spremeni v potrdilo ali poverilnico EAP. Orodje, ki trdi nasprotno, preimenuje datoteko ali ustvari nekaj nepovezanega.

Specifikacija IKEv2 v RFC 7296 opisuje, kaj mora izvedba te različice podpirati. To je referenca za nejasen odgovor operaterja, ne vodnik za konfiguracijo odjemalca.

Tretja zahteva: zaupanja vredna identiteta in cilji

Zahtevajte identiteto prehoda, kot jo mora videti odjemalec, skupaj z sidrom zaupanja, ki jo potrjuje. Nato vprašajte, katere zasebne razpone in razreševalnike storitev pošilja. Ta dva odgovora odločata, kaj tunel dejansko prenaša.

Brez njiju lahko delujoča povezava vseeno ne opravi naloge. Tunel, ki je vzpostavljen brez poslanega razreševalnika, pusti notranja imena brez odgovora. Manjkajoči izbirnik prometa pusti cilj zunaj tunela, čeprav je rokovanje uspelo.

Pregled končne točke odgovarja na drugo vprašanje kot napaka odjemalca. Dosegljiva vrata brez povezave kažejo na preverjanje pristnosti, medtem ko nedosegljiva vrata kažejo na pot.

# 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

Izvedite ta pregled, preden karkoli spremenite v odjemalcu. Če se vrata odzivajo in povezava še vedno ne uspe, je težava v poverilnicah ali politiki. Če se sploh ne odzivajo, nobena sprememba profila ne bo pomagala.

Ko morata oba protokola sobivati

Upravljanje obeh omrežij je legitimen razlog za ohranitev obeh protokolov. Običajna zasnova zaključi WireGuard in IPsec na ločenih vmesnikih ali ločenih prehodih. Odobren promet se nato usmerja med njima.

Ta zasnova uvaja mejo zaupanja in pooblastil, zato jo je treba tako tudi zapisati. Kateri partnerji lahko prečkajo, v katero smer in po čigavi politiki, je odločitev o usmerjanju in požarnem zidu. Noben od protokolov tega ne zagotavlja.

Česar to ni, je pregledna pretvorba. Promet, ki prihaja prek WireGuarda, se znova ustvari v tunelu IPsec in vsako pravilo vmes velja zanj.

Najprej razjasnite zahteve strežnika glede protokola in preverjanja pristnosti. Nato uporabite odjemalca in pot registracije, ki ju podpira operater, ter zasebne ključe medtem hranite stran od spletnih pretvornikov.