Ping verkar berre éin veg: kvifor Windows slepp ekkoet frå tenaren

Klienten din pingar tenaren, tenaren kan ikkje pinga klienten, og tunnelen fraktar tydeleg pakkar i båe dei utsegnene. Det som skil er ikkje vegen, men den første pakken i kvar test: den eine er eit svar på ein straum Windows alt følgjer, den andre er ein ny innkomande førespurnad som ingen regel har sleppt inn. Skilnaden forklarar dei fleste rapportane om einvegs ping og peikar rett på regelen du må skrive. To testar i motsette retningar skil tilfella på rundt eitt minutt.

To retningar, to ulike avgjerder

Når klienten sender ekko-førespurnaden, ser Windows-brannmuren ein utgåande samband som han har bestemt seg for å tillate. Svaret kjem tilbake inne i denne etablerte straumen, så motoren som følgjer tilstand slepp det inn utan å spørje nokon innkomande regel for ICMP. Det er kva tilstandsbasert filtrering tyder i praksis, og regelen ingen skreiv er ikkje med. Klienten sin suksess seier derfor ingenting om den innkomande policyen.

Når tenaren sender førespurnaden først, passar ingen tilstand til han. Windows handsamar pakken som eit nytt innkomande samband og spør den innkomande policyen, som som standard ikkje har noka føresegn for ekko-førespurnader frå vilkårlege kjelder.

Klienten sin suksess prova altså at utgåande ICMP og returvegen verkar. Han prøvde aldri den innkomande avgjerda, og den naturlege slutninga, at brannmuren er i orden, er rimeleg og feil. Derfor går feilen att i saker som alt inneheld prova.

Følg pakken til han forsvinn

Stadfest adressene før du endrar noko: bruk tunneladressa klienten faktisk har, og kontroller at tenaren rutar dit og ikkje til ei LAN-adresse bak klienten. Dei to feila ser identiske ut frå ledeteksta på tenaren, fordi båe endar i tidsavbrot. Kvar pakken døyr er det einaste faktumet som avgjer kva som må endrast.

Viss førespurnaden når tunnelgrensesnittet og ingenting går ut, er den lokale brannmuren den sannsynlege årsaka. Viss han aldri når grensesnittet, er svaret lenger oppe: ei rute på tenaren, ein utgåande policy eller VPN-en si eiga levering mellom likemenn.

Ta opp på tunnelgrensesnittet til klienten medan tenaren pingar. Å sjå førespurnaden kome utan eit svar ved sida er prova som rettferdiggjer å skrive ein Windows-regel. Å sjå ingenting sender deg lenger oppe, og ein regel lagd til i den tilstanden gjer berre maskinen meir ettergjevande for ein pakke som aldri kom. I båe høve kostar opptaket mindre enn gjettinga det erstattar.

Avgrens éi regel i staden for å opne ICMP

Identifiser adapteren og den noverande kategorien hans før du skriv noko, fordi båe viser seg i omfanget du er i ferd med å setje. Det aliaset er grensesnittnamnet i Windows, som ikkje nødvendigvis er namnet på VPN-profilen du importerte. Kommandoane nedanfor listar kva som finst, og førehandsvier deretter ein avgrensa regel utan å bruke han.

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 type 8 er ekko-førespurnaden, den einaste meldinga tenaren treng å få svart. Avgrens han til tunneladressa til tenaren og til tunnelgrensesnittet, og lat profilen vere slik adapteren faktisk er. Å gje eit nettverk nytt namn for å passe eit døme er ei eiga endring med eigne følgjer.

Det regelen ikkje dekkjer

IPv6-ekko er ein annan protokoll med ein annan meldingstype, så ein ICMPv4-regel seier ingenting om han, og ein tunnel som ber båe familiane treng sin eigen regel for den andre. Denne regelen opnar heller ikkje noko anna: RDP, fildeling og kvar andre teneste er framleis avhengige av sin eigen policy. Det er heile poenget med å avgrense éi smal regel i staden for å slå på ei brei ICMP-tillating. Den breie tillatinga er den enkle løysinga og den som varer lengst, fordi ingen legg merke til henne etterpå.

På ein administrert eining kan regelen bli erstatta ved neste policyoppdatering, så policyeigaren må gjere den tilsvarande endringa og ikkje ein lokal administrator. Skriv hensikta i saka saman med kommandoen, fordi ei oppdatering vil slette kommandoen og la kravet stå urørt. Dei to er ikkje same artefakt, og berre éin av dei overlever.

Les resultatet i rett retning

Når regelen gjeld, ping frå tenaren og stadfest at eit svar når klienten, ping deretter frå ei kjelde som framleis skal vere utelukka og stadfest at det ikkje gjer det. Gjenta tilgjengelegheitstesten på den andre adressefamilien viss tunnelen ber ein.

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

Å skrive ut regelen som tredde i kraft er nyttigare enn å stole på kommandoen som laga han, fordi ein førehandsvising og ein brukt regel er ulike tilstandar. Viss adressefilteret viser kjelda du meinte, og den utelukka kjelda framleis får tidsavbrot, gjer regelen nøyaktig det omfanget hans seier. Ein vellukka ping frå klienten ville aldri ha vist det, og derfor høyrer retninga til kvar test heime i registeret ved sida av resultatet. Hald båe retningane i saka, elles vil neste lesar gjenta testen som ikkje kan feile.