SSH til WireGuard-serverens offentlige IP fejler på Windows

Tunneler, der kommer op, mens SSH til serverens offentlige adresse holder op med at virke, ligner en server, der afviser forbindelsen. På Windows er den mere sandsynlige årsag lokal: AllowedIPs for en fuld tunnel på /0 slår restriktive firewallregler til, som tillader tunnelens egen transport og meget lidt andet. Krypterede pakker, der når den adresse, siger intet om, hvorvidt en separat TCP-forbindelse til samme adresse må forlade maskinen.

Adskil endepunktets offentlige adresse fra dets indre tunneladresse, før du rører peer-listen. Næsten ethvert forsøg på at rette dette ved at redigere AllowedIPs gør politikken svagere i stedet for ruten korrekt.

Routingtilladelse og firewalltilladelse er forskellige

En rute afgør, hvor en pakke ville blive sendt, og en firewallregel afgør, om den må sendes overhovedet. At tilføje en rute til endepunktets offentlige IP giver derfor en vej, som filteret stadig kan blokere, og det er præcis den forvirring, dette symptom skaber. På Windows er filteret en del af implementeringen og ikke et tilføjelsesmodul, så ingen ruteindgang ændrer det. De to beslutninger er også adskilte andre steder, selv om standardværdierne er forskellige.

Derfor kan en traceroute til endepunktet lykkes, mens et SSH-forsøg fejler. Den første bæres af den tjeneste, der ejer undtagelsen, og den anden ikke.

Hvad /0 gør på Windows

Med en enkelt peer, hvis tilladte adresser dækker hele IPv4-rummet, anvender WireGuard for Windows en restriktiv firewallholding, der blokerer trafik, som ellers ville gå uden for tunnelen. Tunnelens egen transport er tilladt, fordi VPN’en ellers ikke kunne fungere. En anden applikation til samme offentlige adresse får ingen sådan tilladelse, da undtagelsen tilhører transporten og ikke adressen. Windows-netværksnotater beskriver denne adfærd og den relaterede kontrol i editoren.

Disse regler er mekanismen bag udtrykket kill switch. De aktiveres af konfigurationens form og ikke af et afkrydsningsfelt med det navn.

Undtagelser ændrer beskyttelsesmodellen

At erstatte /0 med to halvstandardpræfikser er den dokumenterede måde at beholde bred routing uden den restriktive semantik, og det er en anden beskyttelsesmodel, ikke en kortere stavemåde. At trække endepunktets adresse fra de tilladte præfikser er den anden almindelige omvej, som forlænger listen og også ændrer, hvilke regler der aktiveres. Ingen af dem er en lokal ændring med lokal effekt. Hver af dem flytter grænsen for hver strøm på maskinen, ikke kun for den forbindelse, du reparerede.

Hvor direkte offentlig SSH virkelig er påkrævet, skal profilens ejer designe både den ydre rute og dens firewalltilladelse og beslutte, hvad der sker med urelateret trafik, når tunnelen falder. At gennemgå IPv4 og IPv6 hver for sig hører også med, da reglerne udtrykkes pr. familie. En bred omvej, der tilføjes for at redde én administrationssession, afslører normalt mere end sessionen.

Test den administrationsvej, du valgte

Beslut først, om administration skal rejse inde i tunnelen eller uden for den, og test derefter det valg i stedet for begge på én gang. Kommandoerne nedenfor kontrollerer klientens adresser, peer-tilstanden og en forbindelse til hvert mål. Kør dem fra Windows-klienten, mens tunnelen er oppe.

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

En vellykket SSH til den indre adresse beviser, at tunnelen bærer administrationstrafik, og at serverens egen firewall accepterer det fra peer-intervallet. En fejl på begge mål er et server- eller nøgleproblem og ikke et Windows-routingproblem. Hvis den indre adresse virker, og den ydre ikke gør, den lokale firewallholding gør præcis det, den blev designet til. Læs de tre resultater i den rækkefølge, før du redigerer en profil.

Notér administrationsvejen, den anvendte adresse og adfærden, når tunnelen er nede. Den note er det, der forhindrer den næste person i at udvide omvejen for at spare fem minutter.