Ping funkcias nur unudirekte: kial Windows forĵetas la eĥon de la servilo

Via kliento pingas la servilon, la servilo ne povas pingi la klienton, kaj la tunelo evidente transportas paketojn en ambaŭ el tiuj asertoj. Malsamas ne la vojo sed la unua paketo de ĉiu testo: unu estas respondo al fluo, kiun Windows jam sekvas, la alia estas nova envenanta peto, kiun neniu regulo akceptis. Tiu diferenco klarigas la plej multajn raportojn pri unudirekta ping kaj montras rekte al la regulo, kiun vi devas skribi. Du testoj en kontraŭaj direktoj disigas la kazojn en proksimume unu minuto.

Du direktoj, du malsamaj decidoj

Kiam la kliento sendas la eĥo-peton, la fajroŝirmilo de Windows vidas elirantan konekton, kiun ĝi decidis permesi. La respondo revenas ene de tiu establita fluo, do la stato-konscia motoro akceptas ĝin sen konsulti iun envenantan regulon por ICMP. Tion signifas stato-bazita filtrado en la praktiko, kaj la regulo, kiun neniu skribis, ne partoprenas. La sukceso de la kliento do diras nenion pri la envenanta politiko.

Kiam la servilo sendas la peton unue, neniu stato kongruas kun ĝi. Windows traktas la paketon kiel novan envenantan konekton kaj demandas la envenantan politikon, kiu defaŭlte tute ne antaŭvidas eĥo-petojn venantajn el arbitraj fontoj.

Do la sukceso de la kliento pruvis, ke eliranta ICMP kaj la reena vojo funkcias. Ĝi neniam testis la envenantan decidon, kaj la natura konkludo, ke la fajroŝirmilo estas en ordo, estas racia kaj malĝusta. Tial la eraro ripetiĝas en biletoj, kiuj jam enhavas la pruvon.

Sekvu la paketon ĝis ĝi malaperos

Konfirmu la adresojn antaŭ ol ŝanĝi ion ajn: uzu la tuneladreson, kiun la kliento efektive havas, kaj kontrolu, ke la servilo enkursigas al ĝi kaj ne al LAN-adreso malantaŭ la kliento. La du malsukcesoj aspektas identaj el la komanda invito de la servilo, ĉar ambaŭ finiĝas per tempolimo. Kie la paketo mortas estas la sola fakto, kiu decidas, kion ŝanĝi.

Se la peto atingas la tunel-interfacon kaj nenio eliras, la loka fajroŝirmilo estas la verŝajna kialo. Se ĝi neniam atingas la interfacon, la respondo estas pli supre: itinero sur la servilo, eliranta politiko aŭ la propra transdono inter samtavolaj nodoj de la VPN.

Kaptu sur la tunel-interfaco de la kliento dum la servilo pingas. Vidi la peton alveni sen respondo apud ĝi estas la pruvo, kiu pravigas skribi regulon por Windows. Vidi tute nenion sendas vin pli supre, kaj regulo aldonita en tiu stato nur igas la maŝinon pli permesema por paketo, kiu neniam alvenis. Ĉiukaze la kapto kostas malpli ol la konjektoj, kiujn ĝi anstataŭas.

Limigu unu regulon anstataŭ malfermi ICMP

Identigu la adaptilon kaj ĝian nunan kategorion antaŭ ol skribi ion ajn, ĉar ambaŭ aperas en la amplekso, kiun vi baldaŭ fiksos. Tiu alinomo estas la nomo de la Windows-interfaco, kiu ne nepre estas la nomo de la VPN-profilo, kiun vi importis. La subaj komandoj listigas, kio ekzistas, kaj poste antaŭmontras limigitan regulon sen apliki ĝin.

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 tipo 8 estas la eĥo-peto, la sola mesaĝo, kiun la servilo bezonas respondi. Limigu ĝin al la tuneladreso de la servilo kaj al la tunel-interfaco, kaj lasu la profilon tia, kia la adaptilo efektive estas. Renomi reton por kongruigi ĝin kun ekzemplo estas aparta ŝanĝo kun propraj sekvoj.

Kion la regulo ne kovras

La eĥo de IPv6 estas alia protokolo kun alia mesaĝa tipo, do regulo pri ICMPv4 diras nenion pri ĝi, kaj tunelo, kiu portas ambaŭ familiojn, bezonas propran regulon por la alia. Ĉi tiu regulo ankaŭ malfermas nenion alian: RDP, dosier-kunhavigo kaj ĉiu alia servo ankoraŭ dependas de sia propra politiko. Tio estas la tuta senco limigi unu mallarĝan regulon anstataŭ ebligi larĝan ICMP-permeson. La larĝa permeso estas la facila riparo kaj tiu, kiu postvivas plej longe, ĉar poste neniu rimarkas ĝin.

Sur administrata aparato la regulo povas esti anstataŭigita ĉe la sekva politik-ĝisdatigo, do la posedanto de la politiko devas fari la ekvivalentan ŝanĝon, ne loka administranto. Skribu la intencon en la bileton kune kun la komando, ĉar ĝisdatigo forviŝos la komandon kaj lasos la postulon netuŝita. La du ne estas la sama artefakto, kaj nur unu el ili postvivas.

Legu la rezulton en la ĝusta direkto

Post kiam la regulo validas, pingu el la servilo kaj konfirmu, ke respondo atingas la klienton, poste pingu el fonto, kiu ankoraŭ devus esti ekskludita, kaj konfirmu, ke ĝi ne atingas. Ripetu la atingeblo-teston sur la alia adresa familio, se la tunelo portas unu.

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

Presi la regulon, kiu efektiviĝis, estas pli utile ol fidi la komandon, kiu kreis ĝin, ĉar antaŭmontro kaj aplikita regulo estas malsamaj statoj. Se la adresa filtrilo montras la celitan fonton kaj la ekskludita fonto ankoraŭ tempolimas, la regulo faras ĝuste tion, kion diras ĝia amplekso. Sukcesa ping el la kliento neniam montrus tion, kaj tial la direkto de ĉiu testo apartenas al la protokolo apud sia rezulto. Konservu ambaŭ direktojn en la bileto, alie la sekva leganto ripetos la teston, kiu ne povas malsukcesi.