Net die Windows-firewall as VPN-doodskakelaar: hou dit?
Reëls op grond van koppelvlaktipe kan die fisiese adapters blokkeer, maar 'n derdeparty-tonnel lyk dikwels bedraad. Kontroleer klassifikasie, die eindpuntroete en dan DNS.
Vra of die Windows-firewall op sy eie as doodskakelaar kan dien, en jy kry twee selfversekerde, onversoenbare antwoorde. Een sê die reël op grond van koppelvlaktipe doen die hele werk; die ander sê dit kan nie sonder scripting werk nie. Albei beskryf die helfte van dieselfde meganisme. Die firewall kan die blok uitdruk, en of die uitslag werklik gesluit misluk, hang van drie dinge af: hoe Windows die tonneladapter klassifiseer, of die eindpunt-uitsondering behoue bly, en of naamresolusie en IPv6 gedek is. Kry enige een daarvan verkeerd en die masjien lek óf verloor alle verbinding.
Drie voorwaardes, in hierdie volgorde
Die eerste voorwaarde is klassifikasie, en dit bepaal of die reël wat jy wil hê, hoegenaamd uitgedruk kan word. Windows-firewallreëls kan volgens koppelvlaktipe beperk word: bedraad, draadloos of afstandtoegang. 'n Beleid wat uitgaande verkeer op die fisiese tipes blokkeer terwyl die tonnel toegelaat word, werk net as Windows die tonnel as afstandtoegang erken.
Die tweede voorwaarde is die eindpunt-uitsondering. Voordat enige tonnel bestaan, moet die kliënt die VPN-bediener oor die fisiese adapter bereik, so 'n volledige blok op daardie adapter verhoed juis die verbinding wat die blok onnodig sou maak. Die uitsondering moet die bediener en sy poort noem, en die pakkie moet deur die fisiese gateway gestuur word eerder as in 'n tonnel wat nog nie op is nie.
Die derde is dekking. 'n Reëlstel wat IPv4 blokkeer en IPv6 vergeet, of wat die plaaslike resolver vir die eindpunt-opsoek toelaat en dus elke ander opsoek toelaat, misluk oop in presies die venster wat die doodskakelaar bestaan om te dek. Dit is 'n ontwerpgaping eerder as 'n fout in die firewall. Dit is ook die gaping wat elke toetslopie op 'n lessenaar oorleef.
Klassifikasie is die eerste hek
Kyk wat Windows van die adapters dink voordat jy 'n enkele reël skryf. 'n Inheemse Windows-VPN-verbinding verskyn gewoonlik as afstandtoegang. 'n Derdeparty-kliënt wat sy eie virtuele adapter skep, verskyn dikwels as bedraad, wat beteken dat 'n blok wat op bedrade adapters gemik is, ook die tonnel blokkeer.
Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory
Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultOutboundActionDie derde opdrag sê vir jou of 'n verstek-uitgaandeblok reeds van krag is, wat die hele vorm van die ontwerp verander. As die verstek reeds blokkeer, skryf jy toelaatreëls eerder as uitsonderings op 'n toelatende basislyn, en dit is 'n veel makliker posisie om oor te redeneer.
As jou tonneladapter as bedraad rapporteer, is net-die-firewall nie die regte instrument vir 'n geslote-ontwerp nie, en geen hoeveelheid reëlverstelling verander dit nie. Dit is die geval waar die tweede mening in elke forumdraad korrek is.
Die eindpunt-uitsondering het 'n roete sowel as 'n reël nodig
Neem aan die klassifikasie werk. Die uitsondering bestaan uit twee stukke, en hulle woon in verskillende substelsels. Die firewallreël laat die verkeer toe; die gasheerroete laat dit deur die regte koppelvlak vertrek terwyl die tonnel af is.
New-NetFirewallRule -DisplayName "VPN endpoint allow" -Direction Outbound -Action Allow \
-Protocol TCP -RemoteAddress 203.0.113.9 -RemotePort 443 -InterfaceType Wired,Wireless
New-NetRoute -DestinationPrefix 203.0.113.9/32 -InterfaceIndex 12 -NextHop 192.168.1.1
Get-NetRoute -DestinationPrefix 203.0.113.9/32Sonder die roete help die eindpunt-uitsondering net terwyl 'n verstekroete nog na die fisiese gateway wys. Sodra die kliënt sy eie verstekroete installeer en dan sterf, het die toegelate pakkies nêrens sinvol om heen te gaan nie en kan die verbinding nie herstel word nie. Daardie mislukking lyk soos 'n stukkende kliënt en is eintlik 'n ontbrekende roete.
Hou die uitsondering so smal as wat die kliënt toelaat. Een adres en een poort is hersienbaar; 'n reeks wat die verskaffer se hele netwerk dek, is nie. Daardie wyer reël laat ook enigiets anders toe wat by dieselfde verskaffer gehuisves word, wat gewoonlik meer is as wat jy bedoel het.
DNS en IPv6 is waar dit oop misluk
Naamresolusie is die klassieke lek. As die eindpunt 'n hostname is, moet die kliënt dit oplos voordat die tonnel bestaan, wat beteken die fisiese adapter moet toegelaat word om 'n resolver te bereik. Dieselfde toestemming laat elke ander opsoek uit terwyl die tonnel af is, en een opsoek is genoeg om te openbaar wat jy op die punt was om te besoek.
IPv6 is die tweede. Reëls geskryf vir IPv4 dek nie die ander familie nie, en baie kliënte installeer net IPv4-roetes. 'n Masjien met inheemse IPv6-verbinding kan dus aanhou met die internet praat terwyl die IPv4-kant stewig geblokkeer is, en die doodskakelaar rapporteer regdeur sukses.
| Gap | What leaks | Control |
|---|---|---|
| Resolver permitted for endpoint lookup | Every name queried while down | Pin the endpoint as an address, or block non-tunnel DNS |
| Rules only for IPv4 | Full IPv6 connectivity | Add the same rules for the other family |
| Application bound to physical interface | Its own traffic | Firewall cannot fix this; change the binding |
Die derde ry is werd om te verstaan eerder as om dit te omseil. 'n Firewall besluit oor pakkies, nie oor watter koppelvlak 'n toepassing gevra het om te gebruik nie, en 'n program wat eksplisiet bind, kan moeilik wees om in bedwang te hou. Dit is 'n argument vir 'n kliëntkant-doodskakelaar wat onder die toepassing werk, nie vir meer reëls nie.
Toets deur die kliënt te stop, nie deur die kabel te trek nie
Die enigste sinvolle toets is die een wat die mislukking naboots waarteen jy beskerm. Stop die diens, doodmaak die proses, of deaktiveer die adapter wat die kliënt geskep het, en probeer dan die internet en 'n naam bereik:
Stop-Service -Name "YourVpnService" -Force
Test-NetConnection -ComputerName 1.1.1.1 -Port 443
Resolve-DnsName example.com
Test-NetConnection -ComputerName 2606:4700:4700::1111 -Port 443Al drie behoort te misluk. As die eerste slaag, is die blok nie van krag nie; as die tweede slaag waar die eerste misluk het, het jy 'n DNS-lek; as die derde slaag, is IPv6 ongedek. Elke uitkoms wys na presies een van die gapings hierbo.
Herhaal die toets ná 'n slaap en hervat, want die firewallprofiel kan verander wanneer Windows besluit 'n netwerk is publiek of privaat, en reëls wat op 'n profiel gemik is, volg dit. 'n Ontwerp wat op 'n lessenaar hou en op 'n trein misluk, is 'n ontwerp wat een keer getoets is.
As die klassifikasiehek of die DNS-vereiste die net-die-firewall-benadering onwerkbaar maak, is 'n kliëntkant-doodskakelaar die eerlike antwoord. As die tonnel eerder op 'n router eindig, moet die router die beleid besit, want een reël daar dek elke toestel daarachter en hang nie af van hoe Windows 'n adapter benoem nie.