SSH till WireGuard-serverns offentliga IP misslyckas på Windows

Tunnlar som kommer upp medan SSH till serverns offentliga adress slutar fungera ser ut som en server som avvisar anslutningen. På Windows är den mer sannolika orsaken lokal: AllowedIPs för en full tunnel med /0 slår på restriktiva brandväggsregler som tillåter tunnelns egen transport och väldigt lite annat. Krypterade paket som når den adressen säger ingenting om huruvida en separat TCP-anslutning till samma adress får gå ut.

Separera slutpunktens offentliga adress från dess inre tunneladress innan du rör peer-listan. Nästan varje försök att åtgärda detta genom att redigera AllowedIPs gör policyn svagare i stället för rutten korrekt.

Routingtillstånd och brandväggstillstånd är olika

En rutt avgör vart ett paket skulle skickas, och en brandväggsregel avgör om det får skickas alls. Att lägga till en rutt för slutpunktens offentliga IP ger därför en väg som filtret fortfarande kan blockera, och det är precis den förvirring som symptomet skapar. På Windows är filtret en del av implementationen och inte ett tillägg, så ingen ruttpost ändrar det. De två besluten är också åtskilda på andra håll, även om standardvärdena skiljer sig.

Därför kan en traceroute till slutpunkten lyckas medan ett SSH-försök misslyckas. Den första bärs av tjänsten som äger undantaget, den andra inte.

Vad /0 gör på Windows

Med en enda peer vars tillåtna adresser täcker hela IPv4-rymden tillämpar WireGuard for Windows en restriktiv brandväggshållning som blockerar trafik som annars skulle lämna tunneln. Tunnelns egen transport är tillåten, eftersom VPN:t annars inte skulle fungera. En annan applikation till samma offentliga adress får inget sådant tillstånd, eftersom undantaget hör till transporten och inte till adressen. Windows-nätverksanteckningar beskriver detta beteende och den tillhörande kontrollen i editorn.

Dessa regler är mekanismen bakom uttrycket kill switch. De aktiveras av konfigurationens form och inte av en kryssruta med det namnet.

Undantag ändrar skyddsmodellen

Att ersätta /0 med två halvstandardprefix är det dokumenterade sättet att behålla bred routing utan den restriktiva semantiken, och det är en annan skyddsmodell, inte en kortare stavning. Att dra av slutpunktens adress från de tillåtna prefixen är den andra vanliga lösningen, som förlänger listan och även ändrar vilka regler som aktiveras. Ingen av dem är en lokal ändring med lokal effekt. Var och en flyttar gränsen för varje flöde på maskinen, inte bara för anslutningen du reparerade.

Där direkt offentlig SSH verkligen behövs måste profilägaren utforma både den yttre rutten och dess brandväggstillstånd, och bestämma vad som händer med orelaterad trafik när tunneln faller. Att granska IPv4 och IPv6 var för sig hör också dit, eftersom reglerna uttrycks per familj. En bred kringgång som läggs till för att rädda en enda administrationssession exponerar oftast mer än sessionen.

Testa den administrationsväg du valde

Bestäm först om administration ska gå inuti tunneln eller utanför den, och testa sedan det valet i stället för båda samtidigt. Kommandona nedan kontrollerar klientens adresser, peer-status och en anslutning till varje mål. Kör dem från Windows-klienten medan tunneln är uppe.

ipconfig | findstr /i "WireGuard IPv4"
wg show
ssh -v [email protected]
Test-NetConnection 203.0.113.9 -Port 22

En lyckad SSH till den inre adressen bevisar att tunneln bär administrationstrafik och att serverns egen brandvägg accepterar den från peer-intervallet. Ett fel på båda målen är ett server- eller nyckelproblem och inte ett Windows-routingproblem. Om den inre adressen fungerar och den yttre inte, den lokala brandväggshållningen gör precis det den konstruerades för. Läs de tre resultaten i den ordningen innan du redigerar en profil.

Notera administrationsvägen, adressen som användes och beteendet när tunneln är nere. Den anteckningen är det som hindrar nästa person från att bredda kringgången för att spara fem minuter.