SSH WireGuard-palvelimen julkiseen IP-osoitteeseen epäonnistuu Windowsissa

Tunnelit, jotka nousevat samalla kun SSH palvelimen julkiseen osoitteeseen lakkaa toimimasta, näyttävät palvelimelta, joka hylkää yhteyden. Windowsissa todennäköisempi syy on paikallinen: täystunnelin AllowedIPs arvolla /0 kytkee päälle rajoittavat palomuurisäännöt, jotka sallivat tunnelin oman liikenteen ja hyvin vähän muuta. Salatut paketit, jotka saapuvat tähän osoitteeseen, eivät kerro mitään siitä, saako erillinen TCP-yhteys samaan osoitteeseen lähteä.

Erota päätepisteen julkinen osoite sen sisäisestä tunneliosoitteesta ennen kuin kosket vertaislistaan. Lähes jokainen yritys korjata tämä muokkaamalla AllowedIPs tekee käytännöstä heikomman eikä reitistä oikeaa.

Reitityslupa ja palomuurilupa ovat eri asioita

Reitti päättää, minne paketti lähetettäisiin, ja palomuurisääntö päättää, saako sitä lähettää lainkaan. Siksi reitin lisääminen päätepisteen julkiselle IP:lle tuottaa polun, jonka suodatin voi yhä estää, ja juuri tämän hämmennöksen tämä oire luo. Windowsissa suodatin on osa toteutusta eikä lisäosa, joten mikään reittimerkintä ei muuta sitä. Molemmat päätökset ovat erillisiä muuallakin, vaikka oletusarvot poikkeavat.

Siksi traceroute päätepisteeseen voi onnistua, kun taas SSH-yritys epäonnistuu. Ensimmäistä kuljettaa palvelu, joka omistaa poikkeuksen, toista ei.

Mitä /0 tekee Windowsissa

Kun yhdellä vertaispisteellä sallitut osoitteet kattavat koko IPv4-avaruuden, WireGuard for Windows soveltaa rajoittavaa palomuuriasennetta, joka estää liikennettä, joka muuten lähtisi tunnelin ulkopuolelle. Tunnelin oman palvelun liikenne sallitaan, koska VPN ei muuten voisi toimia. Toinen sovellus samaan julkiseen osoitteeseen ei saa tällaista lupaa, koska poikkeus kuuluu liikenteelle eikä osoitteelle. Windowsin verkkohuomautukset kuvaavat tätä käyttäytymistä ja siihen liittyvää säätöä editorissa.

Nämä säännöt ovat termin kill switch takana oleva mekanismi. Ne aktivoituvat kokoonpanon muodosta, eivät samannimisestä valintaruudusta.

Poikkeukset muuttavat suojamallia

/0:n korvaaminen kahdella puoliolettusarjalla on dokumentoitu tapa pitää laaja reititys ilman rajoittavaa semantiikkaa, ja se on erilainen suojamalli, ei lyhyempi kirjoitusasu. Päätepisteen osoitteen vähentäminen sallituista etuliitteistä on toinen yleinen kiertotie, joka pidentää listaa ja muuttaa myös sitä, mitkä säännöt aktivoituvat. Kumpikaan ei ole paikallinen muutos, jolla on paikallinen vaikutus. Kumpikin siirtää rajaa jokaiselle koneen virtaukselle, ei vain yhteydelle, jota korjasit.

Kun suora julkinen SSH on todella tarpeen, profiilin omistajan on suunniteltava sekä ulkoinen reitti että sen palomuurilupa ja päätettävä, mitä tapahtuu riippumattomalle liikenteelle tunnelin pudotessa. IPv4:n ja IPv6:n erillinen tarkastelu kuuluu siihen, koska säännöt ilmaistaan perheittäin. Yhden hallintasession pelastamiseksi lisätty laaja ohitus paljastaa yleensä enemmän kuin sen session.

Testaa valitsemasi hallintapolku

Päätä ensin, kulkeeko hallinta tunnelin sisällä vai sen ulkopuolella, ja testaa sitten juuri sitä valintaa etkä molempia yhtä aikaa. Alla olevat komennot tarkistavat asiakkaan osoitteet, vertaispisteen tilan ja yhteyden kuhunkin kohteeseen. Suorita ne Windows-asiakkaasta tunnelin ollessa ylhäällä.

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

Onnistunut SSH sisäiseen osoitteeseen todistaa, että tunneli kuljettaa hallintaliikennettä ja että palvelimen oma palomuuri hyväksyy sen vertaispisteiden alueelta. Epäonnistuminen molemmissa kohteissa on palvelin- tai avainongelma, ei Windowsin reititysongelma. Jos sisäinen osoite toimii ja ulkoinen ei, paikallinen palomuuriasenne tekee juuri sen, mihin se on suunniteltu. Lue kolme tulosta siinä järjestyksessä ennen profiilin muokkaamista.

Kirjaa hallintapolku, käytetty osoite ja käyttäytyminen tunnelin ollessa alhaalla. Juuri se muistiinpano estää seuraavaa henkilöä laajentamasta ohitusta viiden minuutin säästämiseksi.