Profil WireGuard për një portë IPsec: çfarë të kërkosh në vend të kësaj

Skadimet e handshake-ut me një portë të heshtur zakonisht nënkuptojnë dy protokolle që nuk takohen kurrë. Një peer WireGuard flet Noise ndërsa një portë IPsec pret IKE. Adresa dhe porta e saktë nuk e ndryshojnë këtë.

Ripërdorimi i pikës fundore në një profil nuk i lidh të dyja. Hapi tjetër është një kërkesë drejtuar atij që administron portën.

Kërkesa e parë: versioni i protokollit

IPsec emërton një familje dhe jo një rrjedhë të vetme pune. IKEv2 dhe IKEv1 ndryshojnë në shkëmbimet, opsionet e vërtetimit dhe sjelljen gjatë një ndryshimi rrjeti. Një portë që përfundon vetëm IKEv1 do të sillet krejt ndryshe nga një që ofron IKEv2. Konfigurimi i klientit ndryshon bashkë me të.

Pyetni cilin version përfundon shërbimi dhe nëse ekzekuton një implementim të bazuar në standarde apo një variant furnizuesi me klient të vetin. Menutë e sistemeve operative shpesh e fshehin atë përgjigje pas një etikete të vetme. Etiketa nuk është protokolli.

Kërkesa e dytë: metoda e vërtetimit të klientit

Vërtetimi është vendi ku qëndron pjesa më e madhe e punës reale. Shërbimi mund të presë një certifikatë makine me një përdorim të caktuar të zgjeruar çelësi, një certifikatë përdoruesi, një metodë EAP mbi IKEv2 ose një çelës të ndarë paraprakisht të lidhur me një identitet. Cila zbatohet vendos çfarë i duhet klientit.

Një çelës privat WireGuard nuk është asnjë prej tyre. Është një çelës Curve25519 i përdorur në një handshake të caktuar. Asnjë konvertim nuk e bën certifikatë ose kredencial EAP. Një mjet që pretendon të kundërtën po e riemërton skedarin ose po gjeneron diçka të palidhur.

Specifikimi i IKEv2 në RFC 7296 përshkruan çfarë duhet të mbështesë një implementim i atij versioni. Është një referencë për një përgjigje të paqartë të operatorit, jo një udhëzues konfigurimi klienti.

Kërkesa e tretë: identiteti i besuar dhe destinacionet

Kërkoni identitetin e portës ashtu si klienti duhet ta shohë, plus ankorën e besimit që e vërteton. Pastaj pyetni cilat intervale private dhe zgjidhës shërbimi shtyn. Këto dy përgjigje vendosin çfarë transporton tuneli në të vërtetë.

Pa to, një lidhje që funksionon mund të dështojë gjithsesi në detyrë. Një tunel i ngritur pa një zgjidhës të shtyrë i lë emrat e brendshëm pa përgjigje. Një përzgjedhës trafiku që mungon e lë destinacionin jashtë tunelit, edhe pse handshake-u pati sukses.

Një sondë e pikës fundore përgjigjet një pyetjeje tjetër nga gabimi i klientit. Një portë e arritshme pa shoqërim tregon vërtetimin, ndërsa një portë e paarritshme tregon rrugën.

# 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

Kryeni atë sondë përpara se të ndryshoni diçka te klienti. Nëse portat përgjigjen dhe shoqërimi vazhdon të dështojë, problemi është kredencialet ose politika. Nëse nuk përgjigjen fare, asnjë redaktim i profilit nuk do të ndihmojë.

Kur të dy protokollet duhet të bashkëjetojnë

Administrimi i të dy rrjetave është një arsye legjitime për të mbajtur të dy protokollet. Dizajni i zakonshëm përfundon WireGuard dhe IPsec në ndërfaqe të veçanta ose porta të veçanta. Trafiku i miratuar më pas rrugëtohet mes tyre.

Ai dizajn prezanton një kufi besimi dhe autorizimi, dhe ai duhet të shënohet si i tillë. Cilët peer mund të kalojnë, në cilin drejtim dhe nën politikën e kujt është një vendim rrugëtimi dhe muri të zjarrit. Asnjëri prej dy protokolleve nuk e ofron atë.

Ajo që nuk është është një konvertim transparent. Trafiku që mbërrin përmes WireGuard riorigjinohet në tunelin IPsec, dhe çdo politikë në mes zbatohet ndaj tij.

Së pari sqaroni kërkesat e serverit për protokollin dhe vërtetimin. Pastaj përdorni klientin dhe rrugën e regjistrimit që mbështet operatori, dhe mbani çelësat privatë larg konvertuesve të uebit ndërsa kjo ndodh.