WireGuard-profil for en IPsec-gateway: hva du bør spørre om i stedet

Handshake-tidsavbrudd mot en stille gateway betyr vanligvis to protokoller som aldri møtes. En WireGuard-peer snakker Noise mens en IPsec-gateway venter på IKE. Riktig adresse og port endrer ikke det.

Gjenbruk av endepunktet i en profil bygger ikke bro mellom de to. Neste steg er en forespørsel til den som driver gatewayen.

Forespørsel én: protokollversjonen

IPsec betegner en familie og ikke én enkelt arbeidsflyt. IKEv2 og IKEv1 skiller seg i utvekslingene, autentiseringsvalgene og oppførselen ved et nettverksbytte. En gateway som bare avslutter IKEv1, vil oppføre seg helt annerledes enn en som tilbyr IKEv2. Klientkonfigurasjonen endres med det.

Spør hvilken versjon tjenesten avslutter, og om den kjører en standardbasert implementasjon eller en leverandørvariant med egen klient. Operativsystemmenyer skjuler ofte svaret bak én enkelt etikett. Etiketten er ikke protokollen.

Forespørsel to: klientens autentiseringsmetode

Autentisering er der mesteparten av det egentlige arbeidet ligger. Tjenesten kan forvente et maskinsertifikat med en bestemt utvidet nøkkelbruk, et brukersertifikat, en EAP-metode over IKEv2 eller en på forhånd delt nøkkel bundet til en identitet. Hvilken som gjelder, avgjør hva klienten trenger.

En privat WireGuard-nøkkel er ingen av disse. Den er en Curve25519-nøkkel som brukes i én bestemt handshake. Ingen konvertering gjør den til et sertifikat eller en EAP-legitimasjon. Et verktøy som påstår noe annet, gir filen nytt navn eller genererer noe urelatert.

IKEv2-spesifikasjonen i RFC 7296 beskriver hva en implementasjon av den versjonen må støtte. Det er en referanse for et vagt operatørsvar, ikke en guide til klientkonfigurasjon.

Forespørsel tre: den betrodde identiteten og destinasjonene

Be om gatewayens identitet slik klienten må se den, i tillegg til tillitsankeret som validerer den. Spør deretter hvilke private områder og resolvere tjenesten sender. De to svarene avgjør hva tunnelen faktisk bærer.

Uten dem kan en fungerende forbindelse fortsatt feile oppgaven. En tunnel som er oppe uten en sendt resolver, lar interne navn stå ubesvart. En manglende trafikkvelger lar destinasjonen bli stående utenfor tunnelen selv om handshaken lyktes.

En sondering av endepunktet svarer på et annet spørsmål enn klientfeilen. En nåbar port uten assosiasjon peker mot autentisering, mens en unåelig port peker mot veien.

# 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

Kjør den sonderingen før du endrer noe i klienten. Hvis portene svarer og assosiasjonen fortsatt feiler, er problemet legitimasjonen eller policyen. Hvis de ikke svarer i det hele tatt, hjelper ingen profilendring.

Når begge protokollene må sameksistere

Å administrere begge nettverkene er en legitim grunn til å beholde begge protokollene. Det vanlige designet avslutter WireGuard og IPsec på separate grensesnitt eller separate gatewayer. Godkjent trafikk rutes deretter mellom dem.

Det designet innfører en tillits- og autorisasjonsgrense, og den bør skrives ned som sådan. Hvilke parter som kan krysse, i hvilken retning og under hvis policy, er en ruting- og brannmur-beslutning. Ingen av protokollene leverer den.

Det det ikke er, er en transparent konvertering. Trafikk som kommer over WireGuard, gjenopprettes i IPsec-tunnelen, og enhver policy imellom gjelder for den.

Avklar først serverens protokoll- og autentiseringskrav. Bruk deretter klienten og registreringsveien operatøren støtter, og hold private nøkler unna nettbaserte konverterere mens det skjer.