WireGuard profils IPsec vārtejai: ko tā vietā prasīt

Rokasspiediena taimauti ar klusu vārteju parasti nozīmē divus protokolus, kas nekad nesatiekas. WireGuard vienaudzis runā Noise, kamēr IPsec vārteja gaida IKE. Pareiza adrese un ports to nemaina.

Galapunkta atkārtota izmantošana profilā abus nesavieno. Nākamais solis ir lūgums tam, kas pārvalda vārteju.

Pirmais lūgums: protokola versija

IPsec nosauc saimi, nevis vienu darbplūsmu. IKEv2 un IKEv1 atšķiras ar savām apmaiņām, autentifikācijas iespējām un uzvedību tīkla maiņas laikā. Vārteja, kas izbeidz tikai IKEv1, uzvedīsies pavisam citādi nekā tā, kas piedāvā IKEv2. Arī klienta konfigurācija mainās līdzi.

Pajautājiet, kuru versiju pakalpojums izbeidz un vai tas izmanto standartos balstītu ieviešanu vai piegādātāja variantu ar savu klientu. Operētājsistēmu izvēlnes bieži slēpj šo atbildi aiz vienas etiķetes. Etiķete nav protokols.

Otrais lūgums: klienta autentifikācijas metode

Autentifikācija ir vieta, kur atrodas lielākā daļa īstā darba. Pakalpojums var gaidīt mašīnas sertifikātu ar noteiktu paplašinātu atslēgas lietojumu, lietotāja sertifikātu, EAP metodi virs IKEv2 vai iepriekš koplietotu atslēgu, kas piesaistīta identitātei. Kura attiecas, nosaka, kas klientam vajadzīgs.

WireGuard privātā atslēga nav neviens no tiem. Tā ir Curve25519 atslēga, ko izmanto vienā konkrētā rokasspiedienā. Nekāda pārveide to nepadara par sertifikātu vai EAP akreditāciju. Rīks, kas apgalvo pretējo, pārdēvē failu vai ģenerē kaut ko nesaistītu.

IKEv2 specifikācija RFC 7296 apraksta, kas šīs versijas ieviešanai ir jāatbalsta. Tā ir atsauce neskaidrai operatora atbildei, nevis klienta konfigurācijas rokasgrāmata.

Trešais lūgums: uzticamā identitāte un galamērķi

Prasiet vārtejas identitāti tādu, kā to redzēs klients, kopā ar uzticības enkuru, kas to validē. Pēc tam pajautājiet, kādus privātos diapazonus un atrisinātājus pakalpojums nosūta. Šīs divas atbildes nosaka, ko tunelis faktiski pārvadā.

Bez tiem strādājošs savienojums joprojām var neizpildīt uzdevumu. Tunelis, kas pacelts bez nosūtīta atrisinātāja, atstāj iekšējos nosaukumus neatbildētus. Trūkstošs datplūsmas atlasītājs atstāj galamērķi ārpus tuneļa, lai gan rokasspiediens izdevās.

Galapunkta pārbaude atbild uz citu jautājumu nekā klienta kļūda. Sasniedzams ports bez asociācijas norāda uz autentifikāciju, bet nesasniedzams ports norāda uz ceļu.

# 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

Veiciet šo pārbaudi pirms jebko mainīt klientā. Ja porti atbild un asociācija joprojām neizdodas, problēma ir akreditācijās vai politikā. Ja tie neatbild vispār, nekāda profila labošana nepalīdzēs.

Kad abiem protokoliem jāsadzīvo kopā

Abu tīklu administrēšana ir pamatots iemesls paturēt abus protokolus. Ierastais dizains izbeidz WireGuard un IPsec atsevišķos saskarnēs vai atsevišķās vārtejās. Apstiprinātā datplūsma pēc tam tiek maršrutēta starp tām.

Šis dizains ievieš uzticības un autorizācijas robežu, un tā arī jāpieraksta. Kuras puses drīkst šķērsot, kādā virzienā un saskaņā ar kā politiku, ir maršrutēšanas un ugunsmūra lēmums. Neviens no abiem protokoliem to nenodrošina.

Tas, kas tas nav, ir caurspīdīga pārveide. Datplūsma, kas ierodas pa WireGuard, tiek no jauna izveidota IPsec tunelī, un katra politika starpā uz to attiecas.

Vispirms noskaidrojiet servera protokola un autentifikācijas prasības. Pēc tam izmantojiet to klientu un reģistrācijas ceļu, ko atbalsta operators, un šajā laikā turiet privātās atslēgas prom no tīmekļa pārveidotājiem.