Ping werk net een rigting: waarom Windows die bediener se eggo laat val

Jou kliënt ping die bediener, die bediener kan nie die kliënt ping nie, en die tonnel dra duidelik pakkette in albei van daardie stellings. Wat verskil, is nie die pad nie maar die eerste pakket van elke toets: een is ’n antwoord op ’n stroom wat Windows reeds volg, die ander is ’n nuwe inkomende versoek wat geen reël toegelaat het nie. Daardie verskil verduidelik die meeste eenrigting-pingverslae en wys reguit na die reël wat jy moet skryf. Twee toetse in teenoorgestelde rigtings skei die gevalle in omtrent ’n minuut.

Twee rigtings, twee verskillende besluite

Wanneer die kliënt die eggoversoek stuur, sien die Windows-vuurmuur ’n uitgaande verbinding wat hy besluit het om toe te laat. Die antwoord kom terug binne daardie gevestigde stroom, so die toestandbewuste enjin laat dit toe sonder om enige inkomende reël vir ICMP te raadpleeg. Dit is wat toestandbewuste filterring in die praktyk beteken, en die reël wat niemand geskryf het nie, is nie betrokke nie. Die kliënt se sukses sê dus niks oor die inkomende beleid nie.

Wanneer die bediener die versoek eerste stuur, pas geen toestand daarby nie. Windows behandel die pakket as ’n nuwe inkomende verbinding en vra die inkomende beleid, wat by verstek geen voorsiening het vir eggoversoeke wat van willekeurige bronne kom nie.

Die kliënt se sukses het dus bewys dat uitgaande ICMP en die terugpad werk. Dit het nooit die inkomende besluit getoets nie, en die natuurlike gevolgtrekking, dat die vuurmuur reg is, is redelik en verkeerd. Dis hoekom die fout bly herhaal in kaartjies wat reeds die bewyse bevat.

Volg die pakket totdat dit verdwyn

Bevestig die adresse voordat jy enigiets verander: gebruik die tonneladres wat die kliënt werklik het, en kyk of die bediener na dit roeteer eerder as na ’n LAN-adres agter die kliënt. Die twee foute lyk identies vanaf die bediener se opdragprompt, want albei eindig in ’n tydsverloop. Waar die pakket sterf, is die enigste feit wat besluit wat om te verander.

As die versoek die tonnelkoppelvlak bereik en niks verlaat dit nie, is die plaaslike vuurmuur die waarskynlike rede. As dit nooit die koppelvlak bereik nie, is die antwoord stroomop: ’n bedienerroete, ’n uitgaande beleid, of die VPN se eie portuuraflewering.

Vang op die kliënt se tonnelkoppelvlak terwyl die bediener ping. Om die versoek te sien aankom sonder ’n antwoord langsaan, is die bewys wat dit regverdig om ’n Windows-reël te skryf. Om glad niks te sien, stuur jou stroomop, en ’n reël wat in daardie toestand bygevoeg word, maak die masjien net meer toelatend vir ’n pakket wat nooit aangekom het nie. In albei gevalle kos die opvang minder as die giswerk wat dit vervang.

Beperk een reël in plaas daarvan om ICMP oop te maak

Identifiseer die adapter en sy huidige kategorie voordat jy enigiets skryf, want albei verskyn in die omvang wat jy op die punt is om te stel. Daardie alias is die Windows-koppelvlaknaam, wat nie noodwendig die naam van die VPN-profiel is wat jy ingevoer het nie. Die opdragte hieronder lys wat bestaan en wys dan ’n beperkte reël voorskou sonder om dit toe te pas.

Get-NetConnectionProfile
Get-NetAdapter | Where-Object Status -eq 'Up'
New-NetFirewallRule -DisplayName "VPN server echo" -Direction Inbound -Protocol ICMPv4 -IcmpType 8 -RemoteAddress 10.63.0.1 -InterfaceAlias "Office VPN" -Profile Private -Action Allow -WhatIf

ICMPv4 tipe 8 is die eggoversoek, die enigste boodskap wat die bediener beantwoord moet kry. Beperk dit tot die bediener se tonneladres en tot die tonnelkoppelvlak, en laat die profiel soos die adapter werklik is. Om ’n netwerk te herbenoem om by ’n voorbeeld te pas, is ’n aparte verandering met sy eie gevolge.

Wat die reël nie dek nie

IPv6-eggo is ’n ander protokol met ’n ander boodskaptipe, so ’n ICMPv4-reël sê niks daaroor nie, en ’n tonnel wat albei families dra, het sy eie reël vir die ander een nodig. Hierdie reël maak ook niks anders oop nie: RDP, lêerdeling en elke ander diens hang steeds van hul eie beleid af. Dit is die hele punt daarvan om een smal reël te beperk in plaas daarvan om ’n breë ICMP-toelating te aktiveer. Die breë toelating is die maklike oplossing en die een wat die langste oorleef, want niemand sien dit daarna raak nie.

Op ’n bestuurde toestel kan die reël by die volgende beleidsverfrissing vervang word, so die beleideienaar moet die ekwivalente verandering maak eerder as ’n plaaslike administrateur. Skryf die bedoeling in die kaartjie sowel as die opdrag, want ’n verfrissing sal die opdrag uitwis en die vereiste ongeskonde laat. Die twee is nie dieselfde artefak nie, en net een van hulle oorleef.

Lees die resultaat in die regte rigting

Nadat die reël toegepas is, ping vanaf die bediener en bevestig dat ’n antwoord die kliënt bereik, ping dan vanaf ’n bron wat steeds uitgesluit moet wees en bevestig dat dit nie gebeur nie. Herhaal die bereikbaarheidstoets op die ander adresfamilie as die tonnel een dra.

Get-NetFirewallRule -DisplayName "VPN server echo" | Get-NetFirewallAddressFilter
ping 10.63.4.17
ping -6 fd00:63::17

Om die reël te druk wat in werking getree het, is nuttiger as om die opdrag te vertrou wat dit geskep het, want ’n voorskou en ’n toegepaste reël is verskillende toestande. As die adresfilter die bron wys wat jy bedoel het en die uitgeslote bron steeds tydsverloop, doen die reël presies wat sy omvang sê. ’n Suksesvolle ping vanaf die kliënt sou dit nooit gedemonstreer het nie, en daarom hoort die rigting van elke toets in die rekord langs sy resultaat. Hou albei rigtings in die kaartjie, anders sal die volgende leser die toets herhaal wat nie kan misluk nie.