Bygg en IKEv2-VPN i PowerShell med ett maskincertifikat

Windows levererar en IKEv2-klient som PowerShell styr från början till slut, så en fungerande tunnel behöver varken GUI eller programvara från tredje part. Nästan varje fel kommer från tre ställen: var certifikatet hamnade, hur routningsprefixen skrevs och vad den valda EAP-metoden förväntar sig. Hantera dem i den ordningen, eftersom var och en går att kontrollera innan nästa börjar och ett senare fel kommer att dölja ett tidigare.

Maskincertifikattunnlar finns för att starta innan någon loggar in, därför måste identiteten normalt ligga i datorns arkiv och inte i en användares.

Certifikatet först, tunneln sedan

Två importer spelar roll. Klientidentiteten hamnar i Cert:\LocalMachine\My via Import-PfxCertificate, och den utfärdande CA:n hamnar i Cert:\LocalMachine\Root via Import-Certificate. Ett lövcertifikat ensamt bevisar ingen kedja, så hoppar man över den andra importen står verifieringen utan något att bygga på. Utöver närvaro måste den privata nyckeln vara kopplad och datorkontot måste ha rätt att läsa den. Get-ChildItem Cert:\LocalMachine\My listar vad som anlänt; jämför tumavtryck snarare än subjekt, eftersom nästan identiska subjekt är vanliga.

Kontrollera den utökade nyckelanvändningen innan du distribuerar. Klientautentisering är det vanliga kravet för en IKEv2-maskinidentitet, och andra sidan måste lita på den CA som signerade den. En identitet i en användares arkiv existerar inte för en anslutning i datorkontext.

Skapa profilen och dess rutter

Add-VpnConnection -Name "Office IKEv2" -ServerAddress vpn.example.com -TunnelType Ikev2 -EncryptionLevel Required -AuthenticationMethod MachineCertificate -AllUserConnection skriver profilen. Växeln -AllUserConnection publicerar den i den globala telefonboken, lämpligt för en delad eller tjänsteadministrerad maskin; utelämna den för en enskild användare. Vilken adress du än skickar måste den matcha DNS-namnet i serverns certifikat, annars visas felet efter att tunneln redan är uppe. Därefter läggs prefix till ett i taget med Add-VpnConnectionRoute, och bara de som designen faktiskt behöver.

IPv6 har en egenhet: Windows vägrar ::/0 som VPN-rutt, så ::/1 och 8000::/1 täcker tillsammans samma adressrymd. Att routa ett prefix ger inte heller något i den externa brandväggen, så prefixlistan och brandväggspolicyn förblir separata dokument.

Uppgifterna hör till autentiseringsmetoden

En profil med maskincertifikat behöver ingen användarhemlighet alls, medan en EAP-MSCHAPv2-profil gör det. I det andra fallet tillhandahåller modulen VPNCredentialsHelper Set-VpnConnectionUsernamePassword, och den vill ha vanlig text: $cred.Password är en SecureString, så packa upp den först med GetNetworkCredential().Password. Installera modulen överallt där kommandot körs, inte bara på arbetsstationen där det skrevs. EAP-TLS eller en anpassad metod använder inte denna cmdlet alls; de tar i stället en EAP-konfigurations-XML.

rasdial "Office IKEv2" reser anslutningen från ett skal, vilket är det snabbaste sättet att se resultatet i förgrunden i stället för i en händelselogg.

Vad en ansluten tunnel inte bevisar

Ansluten-status täcker IKE-utbytet och autentiseringssteget, och inget därutöver. DNS-beteende, vägen till en privat värd och den externa brandväggen är alla fortfarande obevisade. Arbeta utåt: tunneladaptern, sedan en routningssökning för en privat adress, sedan en tjänst du har tillstånd att använda. Den första observation som misslyckas pekar ut lagret som ska undersökas.

När du ändrar en profil, ta bort den föregående med Remove-VpnConnection -Name "Office IKEv2" -Force innan du återskapar den; annars består inaktuella inställningar och rutter genom redigeringen. Om den fortfarande inte ansluter, jämför tumavtrycket som registrerats i profilen med det som finns i arkivet, eftersom Windows kan hålla en referens till en identitet som sedan dess ersatts under ett oförändrat subjekt.

Håll tumavtrycket, EAP-metoden och ruttlistan bredvid profilen. Tillsammans förklarar de det mesta av det som går fel senare.