Pingul funcționează doar într-un sens: de ce Windows aruncă ecoul serverului

Clientul dumneavoastră face ping către server, serverul nu poate face ping către client, iar tunelul transportă clar pachete în ambele afirmații. Ceea ce diferă nu este calea, ci primul pachet al fiecărui test: unul este un răspuns la un flux pe care Windows îl urmărește deja, celălalt este o cerere nouă de intrare pe care nicio regulă nu a admis-o. Această diferență explică majoritatea rapoartelor de ping unidirecțional și indică direct regula pe care trebuie să o scrieți. Două teste în sensuri opuse separă cazurile în aproximativ un minut.

Două sensuri, două decizii diferite

Când clientul trimite cererea de ecou, firewallul Windows vede o conexiune de ieșire pe care a hotărât să o permită. Răspunsul se întoarce în interiorul acelui flux deja stabilit, așa că motorul care urmărește starea îl admite fără să întrebe vreo regulă de intrare pentru ICMP. Asta înseamnă filtrarea cu stare în practică, iar regula pe care nimeni nu a scris-o nu este implicată. Succesul clientului nu spune deci nimic despre politica de intrare.

Când serverul trimite cererea primul, nicio stare nu i se potrivește. Windows tratează pachetul ca o conexiune nouă de intrare și întreabă politica de intrare, care implicit nu prevede nimic pentru cererile de ecou venite din surse arbitrare.

Așadar succesul clientului a dovedit că ICMP de ieșire și calea de întoarcere funcționează. Nu a testat niciodată decizia de intrare, iar concluzia firească, că firewallul este în regulă, este rezonabilă și greșită. De aceea greșeala se repetă în tichete care conțin deja dovada.

Urmați pachetul până dispare

Confirmați adresele înainte de a schimba ceva: folosiți adresa de tunel pe care clientul o are cu adevărat și verificați că serverul rutează către ea și nu către o adresă LAN din spatele clientului. Cele două eșecuri arată identic din promptul serverului, pentru că ambele se termină în expirare. Unde moare pachetul este singurul fapt care decide ce trebuie schimbat.

Dacă cererea ajunge la interfața tunelului și nimic nu iese, firewallul local este cauza probabilă. Dacă nu ajunge niciodată la interfață, răspunsul este mai sus: o rută pe server, o politică de ieșire sau livrarea proprie a VPN-ului între parteneri.

Capturați pe interfața tunelului clientului în timp ce serverul face ping. A vedea cererea sosind fără un răspuns alături este dovada care justifică scrierea unei reguli Windows. A nu vedea nimic vă trimite mai sus, iar o regulă adăugată în acea stare doar face mașina mai permisivă pentru un pachet care nu a ajuns niciodată. În ambele cazuri captura costă mai puțin decât presupunerile pe care le înlocuiește.

Limitați o regulă în loc să deschideți ICMP

Identificați adaptorul și categoria lui actuală înainte de a scrie orice, pentru că ambele apar în domeniul pe care urmează să îl stabiliți. Acel alias este numele interfeței Windows, care nu este neapărat numele profilului VPN pe care l-ați importat. Comenzile de mai jos listează ce există, apoi previzualizează o regulă limitată fără a o aplica.

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 tip 8 este cererea de ecou, singurul mesaj la care serverul are nevoie de un răspuns. Limitați-o la adresa de tunel a serverului și la interfața tunelului, și lăsați profilul așa cum este adaptorul în realitate. Redenumirea unei rețele pentru a se potrivi unui exemplu este o schimbare separată cu propriile consecințe.

Ce nu acoperă regula

Ecoul IPv6 este alt protocol cu alt tip de mesaj, deci o regulă ICMPv4 nu spune nimic despre el, iar un tunel care transportă ambele familii are nevoie de propria regulă pentru cealaltă. Nici această regulă nu deschide altceva: RDP, partajarea fișierelor și orice alt serviciu depind în continuare de propria politică. Acesta este tot rostul limitării unei reguli înguste în locul activării unei permisiuni ICMP largi. Permisiunea largă este soluția ușoară și cea care supraviețuiește cel mai mult, pentru că nimeni nu o observă după aceea.

Pe un dispozitiv administrat regula poate fi înlocuită la următoarea reîmprospătare a politicii, așa că proprietarul politicii trebuie să facă schimbarea echivalentă, nu un administrator local. Scrieți intenția în tichet împreună cu comanda, pentru că o reîmprospătare va șterge comanda și va lăsa cerința neatinsă. Cele două nu sunt același artefact, și doar unul supraviețuiește.

Citiți rezultatul în sensul corect

După ce regula se aplică, faceți ping din server și confirmați că un răspuns ajunge la client, apoi faceți ping dintr-o sursă care ar trebui să rămână exclusă și confirmați că nu ajunge. Repetați testul de accesibilitate pe cealaltă familie de adrese dacă tunelul o transportă.

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

Tipărirea regulii care a intrat în vigoare este mai utilă decât încrederea în comanda care a creat-o, pentru că o previzualizare și o regulă aplicată sunt stări diferite. Dacă filtrul de adrese arată sursa dorită și sursa exclusă expiră în continuare, regula face exact ce spune domeniul ei. Un ping reușit pornit din client nu ar fi demonstrat niciodată asta, de aceea sensul fiecărui test aparține înregistrării de lângă rezultat. Păstrați ambele sensuri în tichet, altfel următorul cititor va repeta testul care nu poate eșua.