WireGuard-profil for ein IPsec-gateway: kva du bør spørje om i staden

Handshake-tidsavbrot mot ein stille gateway tyder vanlegvis to protokollar som aldri møtest. Ein WireGuard-peer snakkar Noise medan ein IPsec-gateway ventar på IKE. Rett adresse og port endrar ikkje det.

Gjenbruk av endepunktet i ein profil byggjer ikkje bru mellom dei to. Neste steg er ein førespurnad til den som driv gatewayen.

Førespurnad ein: protokollversjonen

IPsec nemner ein familie og ikkje éin enkelt arbeidsflyt. IKEv2 og IKEv1 skil seg i utvekslingane, autentiseringsvala og åtferda ved eit nettverksbyte. Ein gateway som berre avsluttar IKEv1, vil oppføre seg heilt annleis enn ein som tilbyr IKEv2. Klientkonfigurasjonen endrar seg med det.

Spør kva versjon tenesta avsluttar, og om ho køyrer ein standardbasert implementasjon eller ein leverandørvariant med eigen klient. Operativsystemmenyar skjuler ofte svaret bak éi enkel etikett. Etiketten er ikkje protokollen.

Førespurnad to: autentiseringsmetoden til klienten

Autentisering er der mesteparten av det eigentlege arbeidet ligg. Tenesta kan vente eit maskinseritfikat med ein bestemt utvida nøkkelbruk, eit brukarsertifikat, ein EAP-metode over IKEv2 eller ein på førehand delt nøkkel bunden til ein identitet. Kva som gjeld, avgjer kva klienten treng.

Ein privat WireGuard-nøkkel er ingen av desse. Han er ein Curve25519-nøkkel som blir brukt i éin bestemt handshake. Ingen konvertering gjer han til eit sertifikat eller ein EAP-legitimasjon. Eit verktøy som påstår noko anna, gir fila nytt namn eller genererer noko urelatert.

IKEv2-spesifikasjonen i RFC 7296 skildrar kva ein implementasjon av den versjonen må støtte. Det er ei referanse for eit vagt operatørsvar, ikkje ein guide til klientkonfigurasjon.

Førespurnad tre: den betrodde identiteten og destinasjonane

Be om identiteten til gatewayen slik klienten må sjå han, i tillegg til tillitsankeret som validerer han. Spør deretter kva private område og resolvarar tenesta sender. Dei to svara avgjer kva tunnelen faktisk ber.

Utan dei kan ei fungerande tilkopling framleis feile oppgåva. Ein tunnel som er oppe utan ein send resolvar, let interne namn stå ubesvara. Ein manglande trafikkveljar let destinasjonen bli ståande utanfor tunnelen sjølv om handshaken lukkast.

Ei sondering av endepunktet svarer på eit anna spørsmål enn klientfeilen. Ein nåbar port utan assosiasjon peikar mot autentisering, medan ein unåeleg port peikar mot vegen.

# 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øyr den sonderinga før du endrar noko i klienten. Viss portane svarer og assosiasjonen framleis feilar, er problemet legitimasjonen eller policyen. Viss dei ikkje svarer i det heile, hjelper ingen profilendring.

Når begge protokollane må sameksistere

Å administrere begge netverka er ein legitim grunn til å halde på begge protokollane. Det vanlege designet avsluttar WireGuard og IPsec på separate grensesnitt eller separate gatewayar. Godkjend trafikk blir deretter rutra mellom dei.

Det designet innfører ei tillits- og autorisasjonsgrense, og ho bør skrivast ned som slik. Kva partar som kan krysse, i kva retning og under kven sin policy, er ei ruting- og brannmur-avgjerd. Ingen av protokollane leverer ho.

Det det ikkje er, er ein gjennomsiktig konvertering. Trafikk som kjem over WireGuard, blir attoppretta i IPsec-tunnelen, og kvar policy imellom gjeld for han.

Avklar først protokoll- og autentiseringskrava til serveren. Bruk deretter klienten og registreringsvegen som operatøren støttar, og hald private nøklar unna nettbaserte konverterar medan det skjer.