WireGuard-snið fyrir IPsec-gátt: hvað á að biðja um í staðinn
WireGuard-biðlari getur ekki talað IKE. Biddu um samskiptaregluútgáfuna, auðkenningaraðferðina og trausta sjálfsmynd gáttarinnar.
Tímamörk handabands við þegjandi gátt þýða venjulega tvö samskiptareglur sem hittast aldrei. WireGuard-jafningi talar Noise á meðan IPsec-gátt bíður IKE. Rétt vistfang og port breyta því ekki.
Endurnotkun endapunkts í sniði brýr ekki þessi tvö. Næsta skref er beiðni til þess sem rekur gáttina.
Fyrsta beiðnin: samskiptaregluútgáfan
IPsec nefnir fjölskyldu en ekki eitt vinnuferli. IKEv2 og IKEv1 eru ólík í skiptum sínum, auðkenningarmöguleikum og hegðun við netbreytingu. Gátt sem lýkur aðeins IKEv1 mun hegða sér allt öðruvísi en sú sem býður IKEv2. Biðlarastillingin breytist með því.
Spurðu hvaða útgáfu þjónustan lýkur og hvort hún keyri staðlabyggða útfærslu eða afbrigði framleiðanda með eigin biðlara. Stýrikerfisvalmyndir fela þetta svar oft bak við eitt merki. Merkið er ekki samskiptareglan.
Önnur beiðnin: auðkenningaraðferð biðlarans
Auðkenning er þar sem mest af raunverulegu verkinu liggur. Þjónustan kann að ætlast til vélasannvættingar með tiltekinni útvíkkaðri lyklanotkun, notandasannvættingar, EAP-aðferðar yfir IKEv2 eða fyrirfram deilds lykils sem er bundinn við sjálfsmynd. Hvort á við ræður því hvað biðlarinn þarf.
Einkalykill WireGuard er ekkert af þessu. Hann er Curve25519-lykill sem notaður er í einu tilteknu handabandi. Engin umbreyting gerir hann að sannvættingu eða EAP-vottorði. Verkfæri sem fullyrðir annað er að endurnefna skrána eða búa til eitthvað ótengt.
Forskrift IKEv2 í RFC 7296 lýsir því sem útfærsla þeirrar útgáfu verður að styðja. Það er tilvísun fyrir óljóst svar rekstraraðila, ekki leiðarvísir um biðlarastillingu.
Þriðja beiðnin: trausta sjálfsmyndin og áfangastaðirnir
Biddu um sjálfsmynd gáttarinnar eins og biðlarinn verður að sjá hana, ásamt traustsakkerinu sem sannreynir hana. Spurðu síðan hvaða einkanet og leysarar þjónustan sendir. Þessi tvö svör ráða því hvað göngin flytja í raun.
Án þeirra getur virk tenging samt mistekist verkefnið. Göng sem eru uppi án sendra leysara láta innri nöfn vera ósvarað. Vantar val á umferð og er áfangastaðurinn utan ganganna þótt handabandið hafi tekist.
Rannsókn á endapunkti svarar annarri spurningu en biðlaravilla. Aðgengilegt port án tengingar bendir til auðkenningar, en óaðgengilegt port bendir til leiðarinnar.
# 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
Keyrðu þá rannsókn áður en þú breytir nokkru í biðlaranum. Ef portin svara og tengingin mistekst enn er vandamálið í skírteinunum eða stefnunni. Ef þau svara alls ekki mun engin sniðbreyting hjálpa.
Þegar báðar samskiptareglur verða að vera til saman
Stjórnun beggja neta er lögmæt ástæða til að halda báðum samskiptareglum. Venjuleg hönnun lýkur WireGuard og IPsec á aðskildum viðmótum eða aðskildum gáttum. Samþykkt umferð er þá beint á milli þeirra.
Sú hönnun kynnir mörk trausts og heimildar, og þau ætti að skrifa niður sem slík. Hvaða jafningar mega fara yfir, í hvaða átt og undir stefnu hvers er ákvörðun um leiðarval og eldvegg. Hvorug samskiptareglan veitir það.
Það sem þetta er ekki er gagnsæ umbreyting. Umferð sem kemur um WireGuard er endurskapið inn í IPsec-göngin, og öll stefna þar á milli gildir um hana.
Skýrðu fyrst kröfur þjónsins um samskiptareglur og auðkenningu. Notaðu síðan biðlarann og skráningaleiðina sem rekstraraðilinn styður, og haltu einkalyklum fjarri vefbreytum á meðan það gerist.