WireGuard-profil för en IPsec-gateway: vad du bör fråga om i stället

Handshake-timeouts mot en tyst gateway betyder vanligtvis två protokoll som aldrig möts. En WireGuard-peer talar Noise medan en IPsec-gateway väntar på IKE. Rätt adress och port ändrar inte det.

Återanvändning av slutpunkten i en profil överbryggar inte de två. Nästa steg är en förfrågan till den som driver gatewayen.

Förfrågan ett: protokollversionen

IPsec betecknar en familj och inte ett enda arbetsflöde. IKEv2 och IKEv1 skiljer sig i sina utbyten, sina autentiseringsalternativ och sitt beteende vid ett nätverksbyte. En gateway som bara avslutar IKEv1 kommer att bete sig helt annorlunda än en som erbjuder IKEv2. Klientkonfigurationen ändras med det.

Fråga vilken version tjänsten avslutar och om den kör en standardbaserad implementering eller en leverantörsvariant med egen klient. Operativsystemens menyer döljer ofta det svaret bakom en enda etikett. Etiketten är inte protokollet.

Förfrågan två: klientens autentiseringsmetod

Autentisering är där större delen av det egentliga arbetet ligger. Tjänsten kan förvänta sig ett maskincertifikat med en viss utökad nyckelanvändning, ett användarcertifikat, en EAP-metod över IKEv2 eller en i förväg delad nyckel bunden till en identitet. Vilken som gäller avgör vad klienten behöver.

En privat WireGuard-nyckel är inget av detta. Det är en Curve25519-nyckel som används i en enda bestämd handshake. Ingen konvertering gör den till ett certifikat eller en EAP-legitimation. Ett verktyg som påstår något annat byter namn på filen eller genererar något orelaterat.

IKEv2-specifikationen i RFC 7296 beskriver vad en implementering av den versionen måste stödja. Det är en referens för ett vagt operatörssvar, inte en guide till klientkonfiguration.

Förfrågan tre: den betrodda identiteten och destinationerna

Be om gatewayens identitet så som klienten måste se den, plus det förtroendeankare som validerar den. Fråga sedan vilka privata intervall och resolvers tjänsten skickar. De två svaren avgör vad tunneln faktiskt bär.

Utan dem kan en fungerande anslutning ändå misslyckas med uppgiften. En tunnel som är uppe utan en skickad resolver lämnar interna namn obesvarade. En saknad trafikväljare lämnar destinationen utanför tunneln trots att handshaken lyckades.

En sondering av slutpunkten svarar på en annan fråga än klientfelet. En nåbar port utan associering pekar mot autentisering, medan en onåbar port pekar mot vägen.

# 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 sonderingen innan du ändrar något i klienten. Om portarna svarar och associeringen fortfarande misslyckas är problemet legitimationen eller policyn. Om de inte svarar alls hjälper ingen profiländring.

När båda protokollen måste samexistera

Att administrera båda näten är ett legitimt skäl att behålla båda protokollen. Den vanliga designen avslutar WireGuard och IPsec på separata gränssnitt eller separata gatewayer. Godkänd trafik routas sedan mellan dem.

Den designen inför en gräns för förtroende och auktorisation, och den bör skrivas ned som sådan. Vilka parter som får korsa, i vilken riktning och under vems policy är ett routing- och brandväggsbeslut. Ingen av protokollen levererar den.

Det det inte är, är en transparent konvertering. Trafik som kommer över WireGuard återskapas i IPsec-tunneln, och varje policy däremellan gäller för den.

Klargör först serverns protokoll- och autentiseringskrav. Använd sedan klienten och registreringsvägen som operatören stöder, och håll privata nycklar borta från webbkonverterare medan det pågår.