VPN klientai blokuojami viešojo „Windows“ užkardos profilio
„Windows“ priskiria VPN adapterį Viešajam profiliui, todėl jūsų LAN taisyklės niekada neveikia. Patikrinkite profilį, apribokite vieną įeinančią taisyklę baseinui ir tada patikrinkite prievadą.
Jūsų tunelis veikia, šliuzas atsako į ping, o failų bendrinimas vis tiek baigiasi skirtuoju laiku. Toks derinys retai būna maršrutizavimo problema: „Windows“ įdėjo VPN adapterio potinklį į Viešąjį profilį, ir kiekviena leidimo taisyklė, parašyta Privačiam ar Domeno profiliui, niekada nebuvo pritaikyta. Su tuo susidūriau tiek nešiojamuose kompiuteriuose, kurie be problemų pasiekia biurą, tiek RRAS serveriuose, kurie aptarnauja visus kitus klientus, o pataisymas trumpas, kai tik įvardysite susijusį profilį. Štai tvarka, kuria dirbu, su patikra, kuri pasakys, kada sustoti prieš kitą žingsnį.
Išsiaiškinkite, per kurį profilį srautas iš tikrųjų ateina
„Windows“ užkarda neturi vieno visuotinio režimo. Kiekviena prijungta sąsaja turi kategoriją, o įeinantys paketai filtruojami pagal sąsajos, per kurią jie ateina, kategoriją, todėl VPN adapterio profilis nusprendžia, ką tunelyje esantis klientas gali pasiekti, o ne šalia esantis „Wi-Fi“ ar „Ethernet“ adapteris. Perskaitykite abu faktus prieš ką nors keisdami:
Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory, IPv4Connectivity
Get-NetFirewallProfile -Name Public | Select-Object Name, Enabled, DefaultInboundAction
Įprastai įdiegus „OpenVPN“ ar „WireGuard“, VPN adapteris rodomas kaip neatpažintas tinklas ir patenka į Viešąjį profilį, kuris yra numatytasis bet kuriam tinklui, kurio „Windows“ negali klasifikuoti: joks domeno valdiklis neatsakė per jį ir joks šliuzo profilis neatitiko. Sąsajos pavadinimas čia neturi reikšmės, todėl adapterio pavadinimas „VPN“ ar „Corp“ nieko nekeičia. DomainAuthenticated reikalauja prie domeno prijungto kompiuterio , kuris per tą sąsają iš tikrųjų gali pasiekti domeno valdiklį; padalintas tunelis, pernešantis tik vieną potinklį, šios sąlygos netenkins.
Jei reikiama taisyklė jau apribota VPN baseinui ir jau taikoma kategorijai, kurią ką tik perskaitėte, sustokite čia: filtravimas nėra jūsų sluoksnis, o kita vieta, kur žiūrėti, yra paslaugos konfigūracija. Ši patikra trunka dešimt sekundžių ir sutaupo valandą taisyklių redagavimo. Kategorijų pavadinimai ir ką kiekviena apima dokumentuoti Get-NetConnectionProfile nuorodoje.
Patvirtinkite filtravimą, o ne maršrutizavimą, prieš redaguodami taisykles
Ping yra silpnas testas. ICMP gali praeiti, kol paslaugos prievadas atmetamas, o mazgas gali atsakyti iš LAN, tuo pat metu atmesdamas tą patį prašymą per tunelį. Išbandykite prievadą, kurio reikia klientui, iš kliento:
Test-NetConnection 10.8.0.1 -Port 445
Test-NetConnection 10.8.0.1 -Port 3389 -InformationLevel Detailed
Jei prievado testas nepavyksta, atskirkite du sluoksnius. Tunelio ar maršruto gedimas paprastai pasireiškia kaip visiškas atsakymo iš šliuzo adreso nebuvimas, o užkardos atmetimas rodo atsakantį šliuzą ir neatsakantį paslaugos prievadą. „Windows“ serveryje, kuris skelbia baseiną per RRAS, paleiskite tą patį testą iš kliento ir perskaitykite paties serverio profilį: RAS sąsaja gali būti kategorijoje, kurios įeinančios taisyklės niekada nemini klientų diapazono, ir todėl mašina aptarnauja savo LAN ir atmeta kiekvieną tunelio klientą.
Kai rezultatas vis dar dviprasmiškas, užregistruokite susijusio profilio atmetimus ir perskaitykite juos:
Set-NetFirewallProfile -Name Public -LogBlocked True `
-LogFileName "$env:systemroot\system32\LogFiles\Firewall\pfirewall.log"
Įrašai, kuriuose nurodomas kliento adresas ir prievadas su DROP, yra lemiami, ir jie taip pat pasako, kurios taisyklės trūko. Žurnalas, kuriame nieko nėra, o kliento SYN niekada nepasirodo, rodo aukščiau mazgo, todėl grįžkite prie tunelio, NAT taisyklės ar baseino maršruto, prieš liesdami kitą užkardos objektą.
Apribokite vieną įeinančią taisyklę klientų baseinui
Pataisymas yra viena įeinanti leidimo taisyklė, kurios nuotolinis adresas yra baseinas, o ne visas pasaulis. Iš padidintų teisių sesijos:
New-NetFirewallRule -DisplayName "VPN clients - SMB 445" `
-Direction Inbound -Action Allow -Protocol TCP -LocalPort 445 `
-RemoteAddress 10.8.0.0/24 -Profile PublicKai paslauga yra vienas dvejetainis failas, pirmenybę teikite programai apribotai taisyklei su -Program vietoj prievadų sąrašo; tai apriboja išimtį ir procesui, ir šaltinio diapazonui.
Profilio pasirinkimas yra vieta, kur ta pati klaida daroma priešinga kryptimi. -Profile Public pakanka, kai adapteris yra Viešas ir lieka Viešas. -Profile Any yra pateisinama, kai paslauga turi veikti nepriklausomai nuo to, kaip „Windows“ klasifikuoja adapterį, bet tik tol, kol išlieka nuotolinė sritis. Tai, kas niekada nepateisinama, yra -RemoteAddress Any Viešajame profilyje: ši taisyklė seka nešiojamąjį kompiuterį į kiekvieną kavinės ir viešbučio tinklą, prie kurio jis prisijungia, ir atveria prievadą visiems, kurie dalijasi tuo potinkliu.
Užrašykite baseiną prie taisyklės. -RemoteAddress 10.8.0.0/24 tyliai nustoja atitikti tą dieną, kai VPN baseinas pernumeruojamas, o gedimas atrodo lygiai taip pat kaip pradinė klaida, todėl kainuoja antrą popietę. Pavadinkite taisykles pagal paslaugą ir šaltinio diapazoną, laikykite jas kartu su -Group, ir perskaitykite jas iš naujo kiekvieną kartą, kai pasikeičia baseino apibrėžimas. Taisyklių inventorius, kurį galite patikrinti viename ekrane, nugali teisingą taisyklę, kurios niekas neranda.
Keiskite kategoriją tik tada, kai kategorija yra sprendimas
Sąsajos perjungimas į Privačią taip pat veikia, ir tai neteisingas numatytasis nustatymas. Privatus profilis turi ilgą įtaisytųjų leidimo taisyklių sąrašą, apimantį failų ir spausdintuvų bendrinimą, tinklo aptikimą, nuotolinį darbalaukį ir daugiau priklausomai nuo bazinės linijos, todėl VPN adapterio perklasifikavimas įjungia jas visas iš karto kiekvienam tunelio klientui. Viena apribota taisyklė suteikia vieną paslaugą vienam diapazonui. Nešiojamame kompiuteryje, kuris taip pat jungiasi prie nepatikimų tinklų, tas skirtumas nėra kosmetinis.
Pasitaiko atvejų, kai klasifikacija tikrai klaidinga: visada įjungtas ar tarp svetainių tunelis, pernešantis biuro potinklį, yra patikima infrastruktūra, o to adapterio žymėjimas Privačiu yra teisėtas dizaino sprendimas, priimtas vieną kartą pagal politiką, o ne už kiekvieną bilietą. Kai tai darote, darykite tai aiškiai:
Set-NetConnectionProfile -InterfaceAlias "OpenVPN TAP-Windows6" -NetworkCategory PrivateValdomame įrenginyje pirmiausia patikrinkite, ar nustatymą valdo grupės politika, ar MDM bazinė linija. Jei taip, vietinis pakeitimas atšaukiamas per kitą atnaujinimą, ir gpresult /h nurodys politiką, kuri jį valdo; taisykite ten, o ne galiniame taške.
Patikrinkite iš abiejų galų ir palikite pėdsaką
Patikrinkite vartotojo praneštą srautą iš kliento po pakeitimo:
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
Tada uždarykite ciklą dėl dalykų, kurie sulūš kitą savaitę. Paleiskite mazgą iš naujo ir bandykite dar kartą, nes taisyklė, apribota netinkamam profiliui, veikia toliau, kol adapteris grįžta į kitą kategoriją. Išbandykite iš antro kliento, nes vienas klientas su pasenusia nuoma gali paslėpti baseino neatitikimą. Suskaičiuokite pridėtas taisykles prieš pašalintas, nes persidengiančios išimtys yra būdas, kuriuo dviejų eilučių pataisymas tampa filtravimo politika, kurios niekas negali peržiūrėti.
Prieš laikydami tai baigtu:
- Taisyklėje nurodytas profilis yra sąsajos, per kurią ateina srautas, profilis.
- Nuotolinė sritis yra VPN baseinas, ir tas baseinas atitinka tai, ką serveris iš tikrųjų išduoda.
- Nė viena jūsų pridėta taisyklė nenaudoja
-RemoteAddress AnyViešajame profilyje. - Niekas nebuvo išjungta, kad testas praeitų, ir kiekvienas kategorijos pakeitimas įrašo, kas jį patvirtino.