WireGuard-profiil IPsec-lüüsile: mida selle asemel küsida

Käepigistuse ajalõpp vaikse lüüsiga tähendab tavaliselt kahte protokolli, mis kunagi ei kohtu. WireGuardi peer räägib Noise'i, samal ajal kui IPsec-lüüs ootab IKE-t. Õige aadress ja port ei muuda seda.

Lõpp-punkti profiilis uuesti kasutamine ei silla neid kahte. Järgmine samm on taotlus sellele, kes lüüsi haldab.

Esimene taotlus: protokolli versioon

IPsec nimetab perekonda, mitte ühtset töövoogu. IKEv2 ja IKEv1 erinevad oma vahetuste, autentimisvalikute ja võrgu muutumisel käitumise poolest. Lüüs, mis lõpetab ainult IKEv1, käitub hoopis teisiti kui see, mis pakub IKEv2. Kliendi konfiguratsioon erineb koos sellega.

Küsige, millise versiooni teenus lõpetab ja kas see kasutab standarditel põhinevat teostust või tarnija varianti oma kliendiga. Operatsioonisüsteemide menüüd peidavad selle vastuse sageli ühe sildi taha. Silt ei ole protokoll.

Teine taotlus: kliendi autentimismeetod

Autentimine on koht, kus asub suurem osa tegelikust tööst. Teenus võib oodata masinasertifikaati kindla laiendatud võtmekasutusega, kasutajasertifikaati, EAP-meetodit üle IKEv2 või identiteediga seotud eeljagatud võtit. Milline neist kehtib, määrab, mida klient vajab.

WireGuardi privaatvõti ei ole ükski neist. See on Curve25519 võti, mida kasutatakse ühes kindlas käepigistuses. Ükski teisendus ei tee sellest sertifikaati ega EAP-mandaati. Tööriist, mis väidab vastupidist, nimetab faili ümber või genereerib midagi mitteseotut.

IKEv2 spetsifikatsioon RFC 7296-s kirjeldab, mida selle versiooni teostus peab toetama. See on viide ebamäärasele operaatori vastusele, mitte kliendi konfiguratsiooni juhend.

Kolmas taotlus: usaldusväärne identiteet ja sihtkohad

Küsige lüüsi identiteeti nii, nagu klient seda nägema peab, pluss seda valideeriv usaldusankur. Seejärel küsige, milliseid privaatseid vahemikke ja resolvereid teenus saadab. Need kaks vastust määravad, mida tunnel tegelikult kannab.

Ilma nendeta võib töötav ühendus ülesande siiski läbi kukkuda. Tunnel, mis on püsti ilma saadetud resolverita, jätab sisemised nimed vastuseta. Puuduv liiklusvalija jätab sihtkoha tunnelist välja, kuigi käepigistus õnnestus.

Lõpp-punkti sond vastab teistsugusele küsimusele kui kliendi viga. Kättesaadav port ilma seostumiseta viitab autentimisele, samas kui kättesaamatu port viitab teekonnale.

# 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

Tehke see sond enne, kui kliendis midagi muudate. Kui pordid vastavad ja seostumine ikka ebaõnnestub, on probleem mandaatides või poliitikas. Kui need üldse ei vasta, ei aita ükski profiilimuudatus.

Kui mõlemad protokollid peavad koos eksisteerima

Mõlema võrgu haldamine on õigustatud põhjus hoida mõlemat protokolli. Tavaline lahendus lõpetab WireGuardi ja IPseci eraldi liidestel või eraldi lüüsidel. Kinnitatud liiklus suunatakse seejärel nende vahel.

See lahendus toob sisse usalduse ja volitamise piiri ning see tuleks sellisena kirja panna. Millised peerid tohivad üle tulla, mis suunas ja kelle poliitika all, on marsruutimise ja tulemüüri otsus. Kumbki protokoll seda ei anna.

Mida see ei ole, on läbipaistev teisendus. WireGuardi kaudu saabuv liiklus luuakse uuesti IPsec-tunnelisse ja iga vahepealne poliitika kehtib sellele.

Selgitage esmalt serveri protokolli- ja autentimisnõuded. Seejärel kasutage klienti ja registreerimisteed, mida operaator toetab, ning hoidke privaatvõtmed sel ajal veebipõhistest teisendajatest eemal.