WireGuard-profilo por IPsec-enirejo: kion demandi anstataŭe

Mankoj de kunfrapo ĉe silenta enirejo kutime signifas du protokolojn, kiuj neniam renkontiĝas. WireGuard-samulo parolas Noise, dum IPsec-enirejo atendas IKE. Ĝusta adreso kaj pordo tion ne ŝanĝas.

Reuzi la finpunkton en profilo ne pontas la du. La sekva paŝo estas peto al tiu, kiu administras la enirejon.

Unua peto: la protokola versio

IPsec nomas familion, ne unu solan laborfluon. IKEv2 kaj IKEv1 diferencas laŭ siaj interŝanĝoj, siaj aŭtentikigaj elektoj kaj sia konduto dum retŝanĝo. Enirejo, kiu finas nur IKEv1, kondutos tute alie ol tiu, kiu proponas IKEv2. La klienta agordo diferencas kun ĝi.

Demandu, kiun version la servo finas kaj ĉu ĝi uzas norman efektivigon aŭ vendistan varianton kun propra kliento. Menuoj de operaciumoj ofte kaŝas tiun respondon malantaŭ unu etikedo. La etikedo ne estas la protokolo.

Dua peto: la aŭtentikiga metodo de la kliento

Aŭtentikigo estas tie, kie kuŝas la plej granda parto de la reala laboro. La servo eble atendas maŝinan atestilon kun aparta etendita ŝlosiluzo, uzantan atestilon, EAP-metodon super IKEv2 aŭ antaŭe dividitan ŝlosilon ligitan al identeco. Kiu validas, decidas, kion la kliento bezonas.

Privata WireGuard-ŝlosilo estas neniu el tiuj. Ĝi estas Curve25519-ŝlosilo uzata en unu specifa kunfrapo. Neniu konverto faras ĝin atestilo aŭ EAP-legitimo. Ilo, kiu asertas la malon, renomas la dosieron aŭ generas ion ne rilatan.

La specifo de IKEv2 en RFC 7296 priskribas, kion efektivigo de tiu versio devas subteni. Ĝi estas referenco por malpreciza respondo de la administranto, ne gvidilo pri klienta agordo.

Tria peto: la fidinda identeco kaj la celoj

Petu la identecon de la enirejo tiel, kiel la kliento devas vidi ĝin, kune kun la fido-ankro, kiu validigas ĝin. Poste demandu, kiujn privatajn gamojn kaj teleregistrilojn la servo puŝas. Tiuj du respondoj decidas, kion la tunelo fakte portas.

Sen ili funkcianta konekto ankoraŭ povas malsukcesi la taskon. Tunelo starigita sen puŝita teleregistrilo lasas internajn nomojn senrespondaj. Mankanta trafika selektilo lasas la celon ekster la tunelo, kvankam la kunfrapo sukcesis.

Sondado de la finpunkto respondas al alia demando ol la klienta eraro. Atingebla pordo sen asociiĝo indikas aŭtentikigon, dum neatingebla pordo indikas la vojon.

# 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

Plenumu tiun sondadon antaŭ ol ŝanĝi ion en la kliento. Se la pordoj respondas kaj la asociiĝo daŭre malsukcesas, la problemo estas la legitimoj aŭ la politiko. Se ili tute ne respondas, neniu profila ŝanĝo helpos.

Kiam ambaŭ protokoloj devas kunekzisti

Administri ambaŭ retojn estas legitima kialo teni ambaŭ protokolojn. La kutima dezajno finas WireGuard kaj IPsec sur apartaj interfacoj aŭ apartaj enirejoj. Aprobita trafiko tiam estas enkursigita inter ili.

Tiu dezajno enkondukas limon de fido kaj rajtigo, kaj ĝi devas esti tiel notita. Kiuj samuloj rajtas transiri, en kiu direkto kaj sub kies politiko estas decido pri enkursigado kaj fajroŝirmilo. Neniu el la du protokoloj provizas ĝin.

Kio ĝi ne estas, estas travidebla konverto. Trafiko alvenanta per WireGuard estas reorigita en la IPsec-tunelon, kaj ĉiu politiko intere aplikas al ĝi.

Unue klarigu la protokolajn kaj aŭtentikigajn postulojn de la servilo. Poste uzu la klienton kaj la aliĝvojon, kiujn la administranto subtenas, kaj tenu privatajn ŝlosilojn for de retaj konvertiloj dum tio okazas.