SSH til WireGuard-serverens offentlige IP mislykkes på Windows

Tunneler som kommer opp mens SSH til serverens offentlige adresse slutter å virke ser ut som en server som avviser tilkoblingen. På Windows er den mer sannsynlige årsaken lokal: AllowedIPs for en full tunnel på /0 slår på restriktive brannmurregler som tillater tunnelens egen transport og svært lite annet. Krypterte pakker som når den adressen sier ingenting om hvorvidt en separat TCP-tilkobling til samme adresse får gå ut.

Skill endepunktets offentlige adresse fra dens indre tunneladresse før du rører peer-listen. Nesten ethvert forsøk på å rette dette ved å redigere AllowedIPs gjør policyen svakere i stedet for ruten riktig.

Rutingtillatelse og brannmurtillatelse er forskjellige

En rute avgjør hvor en pakke ville bli sendt, og en brannmurregel avgjør om den får sendes i det hele tatt. Å legge til en rute for endepunktets offentlige IP gir derfor en vei som filteret fortsatt kan blokkere, og det er nøyaktig forvirringen dette symptomet skaper. På Windows er filteret en del av implementasjonen og ikke et tillegg, så ingen ruteoppføring endrer det. De to beslutningene er også atskilt andre steder, selv om standardverdiene er forskjellige.

Derfor kan en traceroute til endepunktet lykkes mens et SSH-forsøk mislykkes. Den første bæres av tjenesten som eier unntaket, den andre ikke.

Hva /0 gjør på Windows

Med en enkelt peer der de tillatte adressene dekker hele IPv4-rommet, bruker WireGuard for Windows en restriktiv brannmurholdning som blokkerer trafikk som ellers ville gått utenfor tunnelen. Tunnelens egen transport er tillatt, fordi VPN-en ellers ikke kunne fungere. En annen applikasjon til samme offentlige adresse får ingen slik tillatelse, siden unntaket tilhører transporten og ikke adressen. Windows-nettverksnotater beskriver denne oppførselen og den tilhørende kontrollen i editoren.

Disse reglene er mekanismen bak uttrykket kill switch. De aktiveres av formen på konfigurasjonen og ikke av en avkrysningsboks med det navnet.

Unntak endrer beskyttelsesmodellen

Å erstatte /0 med to halvstandardprefiks er den dokumenterte måten å beholde bred ruting uten den restriktive semantikken, og det er en annen beskyttelsesmodell, ikke en kortere skrivemåte. Å trekke endepunktadressen fra de tillatte prefiksene er den andre vanlige omveien, som forlenger listen og også endrer hvilke regler som aktiveres. Ingen av dem er en lokal endring med lokal effekt. Hver av dem flytter grensen for hver strøm på maskinen, ikke bare for tilkoblingen du reparerte.

Der direkte offentlig SSH virkelig er nødvendig, må profileieren designe både den ytre ruten og dens brannmurtillatelse, og bestemme hva som skjer med urelatert trafikk når tunnelen faller. Å gjennomgå IPv4 og IPv6 hver for seg hører også med, siden reglene uttrykkes per familie. En bred omvei lagt til for å redde én administrasjonsøkt avslører vanligvis mer enn økten.

Test administrasjonsveien du valgte

Bestem først om administrasjon skal reise inne i tunnelen eller utenfor den, og test deretter det valget i stedet for begge samtidig. Kommandoene nedenfor kontrollerer klientens adresser, peer-tilstanden og en tilkobling til hvert mål. Kjø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 adressen beviser at tunnelen bærer administrasjonstrafikk og at serverens egen brannmur godtar den fra peer-området. En feil på begge målene er et server- eller nøkkelproblem og ikke et Windows-rutingproblem. Hvis den indre adressen virker og den ytre ikke, den lokale brannmurholdningen gjør nøyaktig det den ble laget for. Les de tre resultatene i den rekkefølgen før du redigerer en profil.

Noter administrasjonsveien, adressen som ble brukt og oppførselen når tunnelen er nede. Den noten er det som hindrer neste person i å utvide omveien for å spare fem minutter.