VPN-asiakkaat estetään Windowsin julkisen palomuuriprofiilin toimesta

Tunnelisi on pystyssä, yhdyskäytävä vastaa pingiin ja tiedostojako päättyy silti aikakatkaisuun. Tämä yhdistelmä on harvoin reititysongelma: Windows on laittanut VPN-sovittimen aliverkon julkiseen profiiliin, eikä yhtään private- tai domain-profiilille kirjoitettua sallintasääntöä ole koskaan sovellettu. Olen törmännyt tähän sekä kannettavissa, jotka tavoittavat toimiston ongelmitta, että RRAS-palvelimissa, jotka palvelevat kaikkia muita asiakkaita, ja korjaus on lyhyt, kunhan nimeät kyseessä olevan profiilin. Tässä on työjärjestykseni, sekä tarkistus, joka kertoo milloin pysähtyä ennen seuraavaa vaihetta.

Selvitä, millä profiililla liikenne todella saapuu

Windowsin palomuurilla ei ole yhtä globaalia tilaa. Jokaisella liitetyllä rajapinnalla on luokka, ja saapuvat paketit suodatetaan sen rajapinnan luokan mukaan, jolta ne saapuvat, joten VPN-sovittimen profiili ratkaisee, mitä tunnelissa oleva asiakas voi tavoittaa, ei vieressä oleva Wi-Fi- tai Ethernet-sovitin. Lue molemmat tosiasiat ennen kuin muutat mitään:

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory, IPv4Connectivity
Get-NetFirewallProfile -Name Public | Select-Object Name, Enabled, DefaultInboundAction

Tavallisessa OpenVPN- tai WireGuard-asennuksessa VPN-sovitin näkyy tunnistamattomana verkkona ja päätyy julkiseen profiiliin, joka on oletus jokaiselle verkolle, jota Windows ei pysty luokittelemaan: yksikään toimialueen ohjauskone ei vastannut sen kautta eikä mikään yhdyskäytäväprofiili täsmännyt. Rajapinnan nimellä ei ole tässä merkitystä, joten sovittimen kutsuminen "VPN:ksi" tai "Corp:ksi" ei muuta mitään. DomainAuthenticated edellyttää toimialueeseen liitettyä konetta joka voi todella tavoittaa toimialueen ohjauskoneen kyseisen rajapinnan kautta; jaettu tunneli, joka kuljettaa vain yhtä aliverkkoa, ei täytä vaatimusta.

Jos tarvitsemasi sääntö on jo rajattu VPN-altaaseen ja koskee jo luokkaa, jonka juuri luit, pysähdy tähän: suodatus ei ole sinun kerroksesi, ja seuraava paikka katsoa on palvelun kokoonpano. Tämä tarkistus kestää kymmenen sekuntia ja säästää tunnin sääntöjen muokkausta. Luokkien nimet ja se, mitä kukin kattaa, on dokumentoitu Get-NetConnectionProfile-viitedokumentaatiossa.

Vahvista suodatus, ei reititys, ennen kuin muokkaat sääntöjä

Ping on heikko testi. ICMP voi mennä läpi, vaikka palvelun portti hylätään, ja isäntä voi vastata LANista samalla kun se hylkää saman pyynnön tunnelin kautta. Testaa portti, jonka asiakas tarvitsee, asiakkaalta:

Test-NetConnection 10.8.0.1 -Port 445
Test-NetConnection 10.8.0.1 -Port 3389 -InformationLevel Detailed

Jos porttitesti epäonnistuu, erota kaksi kerrosta. Tunnelin tai reitin vika näkyy yleensä niin, ettei yhdyskäytävän osoitteesta tule vastausta lainkaan, kun taas palomuurin hylkäys näyttää vastaavan yhdyskäytävän ja vastaamattoman palvelun portin. Windows-palvelimella, joka julkaisee altaan RRAS:n kautta, suorita sama testi asiakkaalta ja lue palvelimen oma profiili: RAS-rajapinta voi olla luokassa, jonka saapuvat säännöt eivät koskaan mainitse asiakasaluetta, ja siksi kone palvelee omaa LANiaan ja hylkää jokaisen tunnelin asiakkaan.

Kun tulos on edelleen epäselvä, kirjaa kyseessä olevan profiilin hylkäykset lokiin ja lue ne:

Set-NetFirewallProfile -Name Public -LogBlocked True `
  -LogFileName "$env:systemroot\system32\LogFiles\Firewall\pfirewall.log"

Merkinnät, jotka nimeävät asiakkaan osoitteen ja portin DROPin kanssa, ovat ratkaisevia, ja ne kertovat myös, mikä sääntö puuttui. Loki, jossa ei ole mitään, kun asiakkaan SYN ei koskaan ilmesty, viittaa isäntää ylemmäs, joten palaa tunneliin, NAT-sääntöön tai altaan reittiin ennen kuin kosket toiseen palomuuriolioon.

Rajaa yksi saapuva sääntö asiakasaltaaseen

Korjaus on yksi saapuva sallintasääntö, jonka etäosoite on allas, ei koko maailma. Korotetusta istunnosta:

New-NetFirewallRule -DisplayName "VPN clients - SMB 445" `
  -Direction Inbound -Action Allow -Protocol TCP -LocalPort 445 `
  -RemoteAddress 10.8.0.0/24 -Profile Public

Kun palvelu on yksi binääritiedosto, suosi porttiluettelon sijaan ohjelmakohtaista sääntöä -Program -valitsimella; se rajaa poikkeuksen sekä prosessiin että lähdealueeseen.

Profiilin valinta on kohta, jossa sama virhe tehdään vastakkaiseen suuntaan. -Profile Public riittää, kun sovitin on julkinen ja pysyy julkisena. -Profile Any on perusteltua, kun palvelun on toimittava riippumatta siitä, miten Windows luokittelee sovittimen, mutta vain niin kauan kuin etäalue pysyy. Sitä ei voi koskaan perustella, että -RemoteAddress Any julkisessa profiilissa: se sääntö seuraa kannettavaa jokaiseen kahvila- ja hotelliverkkoon, johon se liittyy, ja avaa portin kaikille, jotka jakavat kyseisen aliverkon.

Kirjaa allas säännön viereen. -RemoteAddress 10.8.0.0/24 lakkaa hiljaa täsmäämästä sinä päivänä, jolloin VPN-allas numeroidaan uudelleen, ja vika näyttää täsmälleen alkuperäiseltä bugilta, minkä vuoksi se maksaa toisen iltapäivän. Nimeä säännöt palvelun ja lähdealueen mukaan, pidä ne yhdessä -Group -valitsimella ja lue ne uudelleen aina, kun altaan määritelmä muuttuu. Sääntöluettelo, jonka voit tarkastaa yhdellä näytöllä, voittaa oikean säännön, jota kukaan ei löydä.

Muuta luokkaa vain silloin, kun luokka on päätös

Rajapinnan vaihtaminen yksityiseksi toimii myös, ja se on väärä oletus. Yksityinen profiili sisältää pitkän luettelon sisäänrakennettuja sallintasääntöjä, jotka kattavat tiedosto- ja tulostinjaon, verkon löytämisen, etätyöpöydän ja perusviivasta riippuen enemmän, joten VPN-sovittimen uudelleenluokittelu ottaa ne kaikki käyttöön kerralla jokaiselle tunnelin asiakkaalle. Yksi rajattu sääntö antaa yhden palvelun yhdelle alueelle. Kannettavassa, joka liittyy myös epäluotettuihin verkkoihin, tuo ero ei ole kosmeettinen.

On tapauksia, joissa luokittelu on todella väärä: aina päällä oleva tai toimipaikkojen välinen tunneli, joka kuljettaa toimiston aliverkkoa, on luotettua infrastruktuuria, ja kyseisen sovittimen merkitseminen yksityiseksi on laillinen suunnitteluvalinta, joka tehdään kerran käytännöllä, ei tiketti kerrallaan. Kun teet sen, tee se nimenomaisesti:

Set-NetConnectionProfile -InterfaceAlias "OpenVPN TAP-Windows6" -NetworkCategory Private

Hallitussa laitteessa tarkista ensin, omistaako asetuksen ryhmäkäytäntö vai MDM-perusviiva. Jos omistaa, paikallinen muutos peruutetaan seuraavassa päivityksessä, ja gpresult /h nimeää käytännön, joka sen omistaa; korjaa se siellä, ei päätepisteessä.

Vahvista molemmista päistä ja jätä jälki

Vahvista käyttäjän raportoima virta asiakkaalta muutoksen jälkeen:

Test-NetConnection 10.8.0.1 -Port 445
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallAddressFilter | Select-Object RemoteAddress
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallPortFilter | Select-Object Protocol, LocalPort

Sulje sitten silmukka niissä asioissa, jotka hajoavat ensi viikolla. Käynnistä isäntä uudelleen ja testaa uudelleen, koska väärälle profiilille rajattu sääntö toimii edelleen, kunnes sovitin palaa toiseen luokkaan. Testaa toiselta asiakkaalta, sillä yksi vanhentuneen vuokrasopimuksen omaava asiakas voi piilottaa altaan poikkeaman. Laske lisäämäsi säännöt poistamiasi vastaan, sillä päällekkäiset poikkeukset ovat tapa, jolla kahden rivin korjauksesta tulee suodatuskäytäntö, jota kukaan ei voi tarkastaa.

Ennen kuin kutsut sitä valmiiksi:

• Säännössä nimetty profiili on sen rajapinnan profiili, jolta liikenne saapuu.
• Etäalue on VPN-allas, ja tämä allas vastaa sitä, mitä palvelin todella jakaa.
• Mikään lisäämäsi sääntö ei käytä -RemoteAddress Any julkisessa profiilissa.
• Mitään ei poistettu käytöstä, jotta testi menisi läpi, ja jokainen luokan muutos kirjaa, kuka sen hyväksyi.