WireGuard-profiel voor een IPsec-gateway: waar je in plaats daarvan naar moet vragen

Handshake-time-outs bij een stille gateway betekenen meestal twee protocollen die elkaar nooit ontmoeten. Een WireGuard-peer spreekt Noise terwijl een IPsec-gateway op IKE wacht. Een correct adres en poort veranderen dat niet.

Het hergebruiken van het eindpunt in een profiel overbrugt de twee niet. De volgende stap is een verzoek aan degene die de gateway beheert.

Verzoek één: de protocolversie

IPsec benoemt een familie en niet één enkele werkstroom. IKEv2 en IKEv1 verschillen in hun uitwisselingen, hun authenticatieopties en hun gedrag bij een netwerkwijziging. Een gateway die alleen IKEv1 beëindigt, gedraagt zich heel anders dan een die IKEv2 biedt. De clientconfiguratie verandert mee.

Vraag welke versie de dienst beëindigt en of die een standaardgebaseerde implementatie of een leveranciersvariant met eigen client draait. Menu's van besturingssystemen verbergen dat antwoord vaak achter één label. Het label is niet het protocol.

Verzoek twee: de authenticatiemethode van de client

Authenticatie is waar het grootste deel van het echte werk zit. De dienst verwacht mogelijk een machinecertificaat met een bepaald uitgebreid sleutelgebruik, een gebruikerscertificaat, een EAP-methode over IKEv2 of een vooraf gedeelde sleutel die aan een identiteit is gebonden. Welke geldt, bepaalt wat de client nodig heeft.

Een privésleutel van WireGuard is niets daarvan. Het is een Curve25519-sleutel die in één specifieke handshake wordt gebruikt. Geen enkele conversie maakt er een certificaat of EAP-inloggegevens van. Een hulpmiddel dat het tegendeel beweert, hernoemt het bestand of genereert iets ongerelateerds.

De IKEv2-specificatie in RFC 7296 beschrijft wat een implementatie van die versie moet ondersteunen. Het is een referentie voor een vaag antwoord van de operator, geen gids voor clientconfiguratie.

Verzoek drie: de vertrouwde identiteit en de bestemmingen

Vraag naar de identiteit van de gateway zoals de client die moet zien, plus het vertrouwensanker dat die valideert. Vraag daarna welke privébereiken en resolvers de dienst pusht. Die twee antwoorden bepalen wat de tunnel werkelijk vervoert.

Zonder die twee kan een werkende verbinding de taak alsnog niet uitvoeren. Een tunnel die omhoog staat zonder gepushte resolver laat interne namen onbeantwoord. Een ontbrekende verkeersselector laat de bestemming buiten de tunnel, ook al is de handshake geslaagd.

Een sonde van het eindpunt beantwoordt een andere vraag dan de clientfout. Een bereikbare poort zonder associatie wijst op authenticatie, terwijl een onbereikbare poort op het pad wijst.

# 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

Voer die sonde uit voordat je iets in de client wijzigt. Als de poorten antwoorden en de associatie blijft mislukken, ligt het probleem bij de inloggegevens of het beleid. Antwoorden ze helemaal niet, dan helpt geen profielwijziging.

Wanneer beide protocollen moeten samenleven

Beide netwerken beheren is een legitieme reden om beide protocollen te houden. Het gebruikelijke ontwerp beëindigt WireGuard en IPsec op afzonderlijke interfaces of afzonderlijke gateways. Goedgekeurd verkeer wordt dan tussen beide gerouteerd.

Dat ontwerp introduceert een grens van vertrouwen en autorisatie, en die moet als zodanig worden vastgelegd. Welke peers mogen oversteken, in welke richting en onder wiens beleid is een routing- en firewallbeslissing. Geen van beide protocollen levert die.

Wat het niet is, is een transparante conversie. Verkeer dat via WireGuard binnenkomt, wordt opnieuw in de IPsec-tunnel uitgezet, en elk beleid daartussen geldt ervoor.

Maak eerst de protocol- en authenticatie-eisen van de server duidelijk. Gebruik daarna de client en het registratiepad die de operator ondersteunt, en houd privésleutels uit webconverters terwijl dat gebeurt.