Ping wurket mar ien kant út: wêrom Windows it echo fan de tsjinner falle lit

Jo klant pingt de tsjinner, de tsjinner kin de klant net pingje, en de tunnel ferfiert blykber pakketten yn beide fan dy bewearings. Wat ferskilt is net it paad mar it earste pakket fan elke test: it iene is in antwurd op in stream dy't Windows al folget, it oare is in nij ynkommend fersyk dat gjin regel talitten hat. Dat ferskil ferklearret de measte rapporten oer ienrjochting-ping en wiist direkt nei de regel dy't jo skriuwe moatte. Twa tests yn tsjinoerstelde rjochtingen skiede de gefallen yn sawat in minút.

Twa rjochtingen, twa ferskillende besluten

As de klant it echo-fersyk stjoert, sjocht de Windows-firewall in útgeande ferbining dy't er besletten hat ta te litten. It antwurd komt werom binnen dy fêstige stream, dat de moter dy't tastân folget lit it ta sûnder in ynkommende regel foar ICMP te freegjen. Dat is wat tastân-basearre filterjen yn de praktyk betsjut, en de regel dy't nimmen skreau is der net by belutsen. It sukses fan de klant seit dus neat oer it ynkommende belied.

As de tsjinner it fersyk earst stjoert, past gjin tastân derop. Windows behannelet it pakket as in nije ynkommende ferbining en freget it ynkommende belied, dat by ferstek gjin bepaling hat foar echo-fersiken fan willekeurige boarnen.

It sukses fan de klant bewiisde dus dat útgeand ICMP en de weromwei wurkje. It hat nea de ynkommende beslissing test, en de natuerlike konklúzje, dat de firewall goed is, is ridlik en ferkeard. Dêrom werhellet de flater him yn tickets dy't it bewiis al befetsje.

Folgje it pakket oant it ferdwynt

Befêstigje de adressen foardat jo wat feroarje: brûk it tunneladres dat de klant wier hat, en kontrolearje dat de tsjinner dêrhinne rûtelet en net nei in LAN-adres efter de klant. De beide flaters sjogge der itselde út fan de opdrachtprompt fan de tsjinner, om't beide yn in tiidferrin einigje. Wêr't it pakket stjert is it iennige feit dat beslút wat te feroarjen.

As it fersyk it tunnel-ynterface berikt en der giet neat út, is de lokale firewall de wierskynlike reden. As it it ynterface nea berikt, is it antwurd streamop: in rûte op de tsjinner, in útgeand belied of de eigen levering tusken peers fan de VPN.

Fange op it tunnel-ynterface fan de klant wylst de tsjinner pingt. It fersyk oankommen sjen sûnder antwurd derneist is it bewiis dat it skriuwen fan in Windows-regel rjochtfeardiget. Neat sjen stjoert jo streamop, en in regel dy't yn dy tastân tafoege wurdt makket de masine allinnich toleranter foar in pakket dat nea oankaam. Yn beide gefallen kostet it opfangen minder as it giskjen dat it ferfangt.

Behein ien regel ynstee fan ICMP iepen te setten

Identifisearje de adapter en syn hjoeddeistige kategory foardat jo wat skriuwe, om't beide foarkomme yn it berik dat jo op it punt steane te setten. Dat alias is de Windows-ynterfacenamme, dy't net needsaaklik de namme is fan it VPN-profyl dat jo ymportearre hawwe. De kommando's hjirûnder listje wat bestiet, en toane dan in beheinde regel foarôf sûnder dy ta te passen.

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 is it echo-fersyk, it iennige berjocht dêr't de tsjinner antwurd op nedich hat. Behein it ta it tunneladres fan de tsjinner en ta it tunnel-ynterface, en lit it profyl sa't de adapter wier is. In netwurk omneame om it by in foarbyld te passen is in aparte feroaring mei eigen gefolgen.

Wat de regel net dekt

It echo fan IPv6 is in oar protokol mei in oar berjochttype, dat in ICMPv4-regel seit dêr neat oer, en in tunnel dy't beide famyljes draacht hat syn eigen regel foar de oare nedich. Dizze regel iepenet ek neat oars: RDP, bestân diele en elke oare tsjinst hingje noch altyd fan har eigen belied ôf. Dat is it hiele punt fan it beheinen fan ien smelle regel ynstee fan it ynskeakeljen fan in brede ICMP-tastimming. De brede tastimming is de maklike oplossing en dy't it langst oerlibbet, om't nimmen him letter mear heart.

Op in beheard apparaat kin de regel by de folgjende beliedsfernijing ferfongen wurde, dat de eigner fan it belied moat de lykweardige feroaring meitsje en net in pleatslike administrator. Skriuw de bedoeling yn it ticket njonken it kommando, om't in fernijing it kommando wiskje sil en de eask ûnferoare litte. De beide binne net itselde artefakt, en mar ien fan beide oerlibbet.

Lês it resultaat yn de goede rjochting

Nei't de regel jildt, pingje fan de tsjinner en befêstigje dat in antwurd de klant berikt, pingje dan fan in boarne dy't noch útsletten bliuwe moat en befêstigje dat it net berikt. Werhelje de berikberens-test op de oare adresfamylje as de tunnel ien draacht.

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

It printsjen fan de regel dy't krêft fan jild krige is better as it fertrouwen op it kommando dat him makke hat, om't in foarôfbyld en in tapaste regel ferskillende tastannen binne. As it adresfilter de boarne sjen lit dy't jo bedoelden en de útsletten boarne noch altyd yn tiidferrin einiget, docht de regel krekt wat syn berik seit. In suksesfolle ping fan de klant soe dat nea bewiisd hawwe, en dêrom heart de rjochting fan elke test yn it ferslach njonken syn resultaat. Hâld beide rjochtingen yn it ticket, oars werhellet de folgjende lêzer de test dy't net mislearje kin.