SSH til den offentlege IP-adressa til WireGuard-tenaren mislukkast på Windows

Tunnelar som kjem opp medan SSH til den offentlege adressa til tenaren sluttar å verke ser ut som ein tenar som avviser tilkoblinga. På Windows er den meir sannsynlege årsaka lokal: AllowedIPs for ein full tunnel på /0 slår på restriktive brannmurreglar som tillèt den eigen transporten til tunnelen og svært lite anna. Krypterte pakkar som når den adressa seier ingenting om ein separat TCP-tilkobling til same adresse får gå ut.

Skil den offentlege adressa til endepunktet frå den indre tunneladressa før du rører peer-lista. Nesten kvart forsøk på å rette dette ved å redigere AllowedIPs gjer policyen svakare i staden for ruta riktig.

Rutetillating og brannmurtillating er ulike

Ei rute avgjer kvar ein pakke ville bli send, og ein brannmurregel avgjer om han får bli send i det heile. Å leggje til ei rute for den offentlege IP-adressa til endepunktet gjev difor ein veg som filteret framleis kan blokkere, og det er nøyaktig den forvirringa dette symptomet skapar. På Windows er filteret ein del av implementasjonen og ikkje eit tillegg, så ingen ruteoppføring endrar det. Dei to avgjerdene er også skilde andre stader, sjølv om standardverdiane er ulike.

Difor kan ein traceroute til endepunktet lukkast medan eit SSH-forsøk mislukkast. Den første blir boren av tenesta som eig unntaket, den andre ikkje.

Kva /0 gjer på Windows

Med ein einaste peer der dei tillatne adressene dekkjer heile IPv4-rommet, brukar WireGuard for Windows ei restriktiv brannmurhaldning som blokkerer trafikk som elles ville gått utanfor tunnelen. Den eigen transporten til tunnelen er tillaten, fordi VPN-en elles ikkje kunne fungere. Ein annan applikasjon til same offentlege adresse får inga slik tillating, sidan unntaket høyrer til transporten og ikkje til adressa. Windows-nettverksnotat skildrar denne åtferda og den tilhøyrande kontrollen i editoren.

Desse reglane er mekanismen bak uttrykket kill switch. Dei blir aktiverte av forma på konfigurasjonen og ikkje av ein avkryssingsboks med det namnet.

Unntak endrar vernemodellen

Å erstatte /0 med to halvstandardprefiks er den dokumenterte måten å halde brei ruting utan den restriktive semantikken, og det er ein annan vernemodell, ikkje ein kortare skrivemåte. Å trekkje endepunktadressa frå dei tillatne prefiksa er den andre vanlege omvegen, som forlengjer lista og også endrar kva reglar som blir aktiverte. Ingen av dei er ei lokal endring med lokal effekt. Kvar av dei flyttar grensa for kvar straum på maskinen, ikkje berre for tilkoblinga du reparerte.

Der direkte offentleg SSH verkeleg er naudsynt, må profileigaren utforme både den ytre ruta og brannmurtillatinga hennar, og avgjere kva som skjer med urelatert trafikk når tunnelen fell. Å gjennomgå IPv4 og IPv6 kvar for seg høyrer også med, sidan reglane blir uttrykte per familie. Ein brei omveg lagd til for å redde éi administrasjonsøkt avdekkjer vanlegvis meir enn økta.

Test administrasjonsvegen du valde

Avgjer først om administrasjon skal reise inne i tunnelen eller utanfor han, og test deretter det valet i staden for begge samtidig. Kommandoane nedanfor kontrollerer adressene til klienten, tilstanden til peeren og ei tilkobling til kvart mål. Køyr dei frå Windows-klienten medan tunnelen er oppe.

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

Ein vellukka SSH til den indre adressa provar at tunnelen ber administrasjonstrafikk og at brannmuren til tenaren sjølv godtek han frå peer-området. Ein feil på begge måla er eit tenar- eller nøkkelproblem og ikkje eit Windows-rutingproblem. Viss den indre adressa verkar og den ytre ikkje, den lokale brannmurhaldninga gjer nøyaktig det han var laga for. Les dei tre resultata i den rekkjefølgja før du redigerer ein profil.

Noter administrasjonsvegen, adressa som vart brukt og åtferda når tunnelen er nede. Den notata er det som hindrar neste person i å utvide omvegen for å spare fem minutt.