WireGuard-profil til en IPsec-gateway: hvad du i stedet bør spørge om

Handshake-timeouts mod en tavs gateway betyder som regel to protokoller, der aldrig mødes. En WireGuard-peer taler Noise, mens en IPsec-gateway venter på IKE. Korrekt adresse og port ændrer ikke på det.

Genbrug af endepunktet i en profil bygger ikke bro mellem de to. Næste skridt er en anmodning til den, der driver gatewayen.

Anmodning et: protokolversionen

IPsec betegner en familie og ikke et enkelt arbejdsforløb. IKEv2 og IKEv1 adskiller sig i deres udvekslinger, deres godkendelsesmuligheder og deres adfærd ved et netværksskift. En gateway, der kun afslutter IKEv1, vil opføre sig helt anderledes end en, der tilbyder IKEv2. Klientkonfigurationen følger med.

Spørg, hvilken version tjenesten afslutter, og om den kører en standardbaseret implementering eller en leverandørvariant med egen klient. Styresystemmenuer skjuler ofte det svar bag en enkelt etiket. Etiketten er ikke protokollen.

Anmodning to: klientens godkendelsesmetode

Godkendelse er der, hvor det meste af det egentlige arbejde ligger. Tjenesten forventer måske et maskincertifikat med en bestemt udvidet nøgleanvendelse, et brugercertifikat, en EAP-metode over IKEv2 eller en på forhånd delt nøgle bundet til en identitet. Hvilken der gælder, afgør, hvad klienten har brug for.

En privat WireGuard-nøgle er ingen af disse ting. Det er en Curve25519-nøgle, der bruges i ét bestemt handshake. Ingen konvertering gør den til et certifikat eller en EAP-legitimation. Et værktøj, der påstår andet, omdøber filen eller genererer noget urelateret.

IKEv2-specifikationen i RFC 7296 beskriver, hvad en implementering af den version skal understøtte. Det er en reference for et vagt operatørsvar, ikke en guide til klientkonfiguration.

Anmodning tre: den betroede identitet og destinationerne

Bed om gatewayens identitet, som klienten skal se den, plus det tillidsanker, der validerer den. Spørg derefter, hvilke private områder og resolvere tjenesten udsender. De to svar afgør, hvad tunnelen faktisk bærer.

Uden dem kan en fungerende forbindelse stadig fejle opgaven. En tunnel, der er oppe uden en udsendt resolver, lader interne navne ubesvarede. En manglende trafikvælger lader destinationen være uden for tunnelen, selv om handshaket lykkedes.

En sondering af endepunktet svarer på et andet spørgsmål end klientfejlen. En nåbar port uden associering peger på godkendelse, mens en unåelig port peger på vejen.

# 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

Kør den sondering, før du ændrer noget i klienten. Hvis portene svarer, og associeringen stadig fejler, er problemet legitimationsoplysningerne eller politikken. Hvis de slet ikke svarer, hjælper ingen profilændring.

Når begge protokoller skal sameksistere

At administrere begge netværk er en legitim grund til at beholde begge protokoller. Det sædvanlige design afslutter WireGuard og IPsec på adskilte grænseflader eller adskilte gateways. Godkendt trafik routes derefter mellem dem.

Det design indfører en tillids- og autorisationsgrænse, og den bør skrives ned som sådan. Hvilke parter der må krydse, i hvilken retning og under hvis politik er en routing- og firewallbeslutning. Ingen af protokollerne leverer den.

Det, det ikke er, er en transparent konvertering. Trafik, der ankommer over WireGuard, genopstår i IPsec-tunnelen, og enhver politik imellem gælder for den.

Afklar først serverens protokol- og godkendelseskrav. Brug derefter den klient og den tilmeldingsvej, operatøren understøtter, og hold private nøgler væk fra webbaserede konvertere, mens det sker.