Miksi VPN-sovittimesi jää julkiseen palomuuriprofiiliin

Tunneli on pystyssä, tili on todennettu toimialueelta, ja Windows merkitsee yhteyden silti julkiseksi. Siksi toimialueen profiilille kirjoitettu palomuurisääntö ei tule voimaan, ja tiedostojako jää tavoittamattomaksi. Tavallinen korjausyritys on asettaa sovitin yksityiseksi, mikä muuttaa sitä, mitkä säännöt ovat voimassa, muuttamatta mitään todennuksessa. Sekä merkintä että korjaus ymmärretään laajalti väärin, ja niiden erottaminen vaatii kolme komentoa.

Kirjautunut tili ei ole verkon luokka

VPN-yhteyden aikana tehdään kaksi erilaista päätöstä, ja ne on helppo sekoittaa. Yhdyskäytävä päättää, saako tili muodostaa yhteyden. Windows päättää, miten syntyvä verkko luokitellaan, ja tämä luokittelu määrää, mitkä palomuurisäännöt kohdistuvat liitäntään.

Onnistunut toimialueen todennus yhdyskäytävässä on todiste tilistä. Se ei ole todiste siitä, että päätepiste on todentanut verkon toimialueen ohjainta vastaan, ja juuri sitä toimialueen luokka edustaa.

Siksi kone voi olla liitetty toimialueeseen, yhdistää toimialueen tilillä ja näyttää silti julkista. Luokittelu on paikallinen päätös verkosta, ei lausuma tunnelin avanneista tunnistetiedoista. Tili voi olla täysin kelvollinen, kun merkintä pysyy siinä, mihin se alun perin asetettiin.

Kolme luokkaa, joista yhtä et voi asettaa

Windows tarjoaa kolme luokkaa, ja järjestelmänvalvoja voi määrittää niistä vain kaksi. Kolmannen päättää käyttöjärjestelmä sen jälkeen, kun se on todennut verkon toimialueen ohjainta vastaan.

Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory,IPv4Connectivity
Set-NetConnectionProfile -InterfaceAlias 'Corp VPN' -NetworkCategory Private
Set-NetConnectionProfile -InterfaceAlias 'Corp VPN' -NetworkCategory DomainAuthenticated

Kolmas komento epäonnistuu, ja se on dokumentoitu toimintatapa, ei käyttöoikeusongelma. Komennon oma viite toteaa, että toimialueen luokkaa ei voi määrittää tällä tavalla, koska Windows johtaa sen toimialueen todennuksesta. Virheen näkeminen on hyödyllinen vahvistus siitä, että luokka on seuraus eikä asetus.

Lue ensimmäinen komento siltä päätepisteeltä, jonka liikennettä estetään. Yhdyskäytävän oman liitännän luokittelu ei kerro mitään siitä, miten kukin yhdistyvä työasema luokitteli tunnelinsa.

Säännöt noudattavat profiilia, jolle ne kirjoitettiin

Kun luokka on tiedossa, puuttuva käyttöoikeus yleensä selittää itsensä. Jokaisella Windows Firewall -säännöllä on profiililaajuus, eikä toimialueeseen rajattu sääntö tule voimaan, kun liitäntä on julkinen. Kolme komentoa tekee siitä vastauksen eikä teorian, ja kolmas nappaa tapauksen, jossa profiili ei koskaan ollut ongelma:

(Get-NetFirewallRule -DisplayName 'Allow File Share').Profile
Get-NetFirewallRule -DisplayName 'Allow File Share' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

Toinen komento on se, joka muuttaa epämääräisen raportin korjaukseksi. Jos sääntö on rajattu etäosoitealueeseen, joka ei sisällä VPN-poolia, profiilin vaihtaminenkaan ei auta.

Tarkista myös saapuvan liikenteen oletustoiminto. Koneella, jolla saapuva liikenne on oletuksena estetty, puuttuva sallintasääntö tuottaa hiljaisuutta hylkäyksen sijaan. Asiakkaan puolelta se näyttää täsmälleen samalta kuin reititysvirhe, ja siksi niin monet näistä tiketeistä alkavat väärällä oletuksella.

Selvitä, mikä kone valvoo sääntöä

Ennen kuin muutat luokkaa, selvitä, missä esto tapahtuu. Jakoa isännöivällä palvelimella voi olla oma palomuuri, ja sen säännöt kohdistuvat VPN-poolista saapuvaan liikenteeseen riippumatta siitä, miten asiakas nimesi sovittimensa. Hylkäys siellä on näkymätön kaikille paikallisille komennoille, joita ajat, ja asiakaspuoli vain ilmoittaa, ettei resurssi ole käytettävissä. Testaa kohteen omat säännöt ennen kuin kosket asiakkaan luokitteluun.

Testaa asiakkaalta tietylle portille ja vertaa sitten testiin toiselta isännältä samassa VPN:ssä. Jos molemmat epäonnistuvat, ongelma on kohteessa tai reitillä. Jos vain toinen epäonnistuu, ero on paikallinen sille koneelle, ja profiilin luokasta tulee uskottava syy.

Pidä mielessä myös suunta. Sääntö, joka sallii saapuvan SMB:n, ei tee mitään asiakkaalle, jonka oma lähtevä sääntö estää saman liikenteen. Tiedostoselaimen ikkunasta kaksi epäonnistumista eivät ole erotettavissa, joten testaa kumpikin suunta erikseen ennen kuin muokkaat mitään.

Mitä tehdä sen sijaan, että nimeäisit kaiken uudelleen

Tunnistamattoman verkon muuttaminen yksityiseksi laajan säännön vuoksi on todellinen muutos, jolla on todellisia seurauksia. Yksityinen profiili sallii yleensä enemmän löytämistä ja enemmän saapuvaa liikennettä kuin julkinen.

Jos tavoitteena on päästää tietty palvelu VPN-asiakkaisiin, rajaa sääntö etäosoitteen eikä profiilin mukaan. Se ilmaisee aikomuksen täsmällisesti, toimii luokituksesta riippumatta eikä riipu siitä, arvaako Windows virtuaalisen sovittimen oikein. Se kestää myös asiakaspäivityksen, joka luokittelee liitännän uudelleen. Kirjoita pooli sääntöön, niin seuraava henkilö voi lukea aikomuksen kysymättä.

Jos toimialueen luokkaa todella odotetaan eikä se koskaan ilmesty, se on erillinen tutkinta. Tarkista, että kone on liitetty toimialueeseen, että se tavoittaa toimialueen ohjaimen tunnelin kautta ja että suojattu kanava on kunnossa. Nämä kolme komentoa vastaavat siihen ilman yhtään rekisterimuutosta:

Get-CimInstance Win32_ComputerSystem | Select-Object PartOfDomain,Domain
Test-ComputerSecureChannel -Verbose
nltest /dsgetdc:corp.example.com

Nämä kolme vastaavat, olisiko päätepiste voinut ylipäätään todentaa verkon. Jos se ei tavoita ohjainta, toimialueen luokkaa ei koskaan määritetä, riippumatta siitä, kuinka monta kertaa sovitin nollataan. Palomuurisääntö, jota jäljitit, ei ollut koskaan varsinainen ongelma, ja merkintä oli rikkoutuneen reitin oire, ei syy.