El ping funciona en un sol sentit: per què Windows descarta l'eco del servidor

El teu client fa ping al servidor, el servidor no pot fer ping al client, i el túnel porta paquets clarament en les dues afirmacions. El que difereix no és el camí sinó el primer paquet de cada prova: un és una resposta a un flux que Windows ja segueix, l'altre és una petició entrant nova que cap regla no ha admès. Aquesta diferència explica la majoria d'informes de ping unidireccional i apunta directament a la regla que has d'escriure. Dues proves en sentits oposats separen els casos en aproximadament un minut.

Dos sentits, dues decisions diferents

Quan el client envia la petició d'eco, el tallafoc de Windows veu una connexió sortint que ha decidit permetre. La resposta torna dins d'aquest flux establert, així que el motor amb estat l'admet sense consultar cap regla entrant per a ICMP. Això és el que significa el filtratge amb estat a la pràctica, i la regla que ningú no va escriure no hi intervé. Per tant, l'èxit del client no diu res sobre la política entrant.

Quan el servidor envia la petició primer, cap estat no hi coincideix. Windows tracta el paquet com una connexió entrant nova i pregunta a la política entrant, que per defecte no preveu res per a les peticions d'eco provinents de fonts arbitràries.

Així, l'èxit del client va demostrar que l'ICMP sortint i el camí de tornada funcionen. Mai no va exercitar la decisió entrant, i la conclusió natural, que el tallafoc està bé, és raonable i errònia. Per això l'error es repeteix en tiquets que ja contenen la prova.

Segueix el paquet fins que desaparegui

Confirma les adreces abans de canviar res: fes servir l'adreça de túnel que el client té realment i comprova que el servidor hi encamina, i no a una adreça de LAN darrere del client. Les dues fallades semblen idèntiques des del terminal del servidor, perquè totes dues acaben en un temps d'espera esgotat. On mor el paquet és l'únic fet que decideix què cal canviar.

Si la petició arriba a la interfície del túnel i no en surt res, el tallafoc local és el motiu probable. Si no arriba mai a la interfície, la resposta és més amunt: una ruta del servidor, una política sortint o el lliurament propi entre parells de la VPN.

Captura a la interfície del túnel del client mentre el servidor fa ping. Veure la petició arribar sense cap resposta al costat és la prova que justifica escriure una regla de Windows. No veure-hi res et envia més amunt, i una regla afegida en aquest estat només fa la màquina més permissiva per a un paquet que mai no va arribar. En tots dos casos la captura costa menys que les conjectures que substitueix.

Limita una regla en lloc d'obrir ICMP

Identifica l'adaptador i la seva categoria actual abans d'escriure res, perquè tots dos apareixen a l'abast que estàs a punt de fixar. Aquest àlies és el nom de la interfície de Windows, que no és necessàriament el nom del perfil de VPN que has importat. Les ordres de sota llisten què hi ha i després previsualitzen una regla limitada sense aplicar-la.

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 tipus 8 és la petició d'eco, l'únic missatge que el servidor ha de respondre. Limita-la a l'adreça de túnel del servidor i a la interfície del túnel, i deixa el perfil tal com l'adaptador és realment. Reanomenar una xarxa per encaixar-la en un exemple és un canvi a part amb conseqüències pròpies.

Què no cobreix la regla

L'eco d'IPv6 és un protocol diferent amb un tipus de missatge diferent, així que una regla ICMPv4 no en diu res, i un túnel que porta les dues famílies necessita la seva pròpia regla per a l'altra. Aquesta regla tampoc no obre res més: RDP, compartició de fitxers i tota la resta de serveis depenen encara de la seva pròpia política. Aquest és tot el sentit de limitar una regla estreta en lloc d'habilitar un permís ampli d'ICMP. El permís ampli és la solució fàcil i la que sobreviu més temps, perquè ningú no se n'adona després.

En un dispositiu gestionat la regla es pot substituir en la propera actualització de política, així que el propietari de la política ha de fer el canvi equivalent i no un administrador local. Escriu la intenció al tiquet igual que l'ordre, perquè una actualització esborrarà l'ordre i deixarà el requisit intacte. No són el mateix artefacte, i només un dels dos sobreviu.

Llegeix el resultat en el sentit correcte

Un cop aplicada la regla, fes ping des del servidor i confirma que una resposta arriba al client, després fes ping des d'una font que encara hauria de quedar exclosa i confirma que no hi arriba. Repeteix la prova d'abastabilitat a l'altra família d'adreces si el túnel en porta una.

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

Imprimir la regla que ha entrat en vigor és més útil que confiar en l'ordre que la va crear, perquè una previsualització i una regla aplicada són estats diferents. Si el filtre d'adreces mostra la font que volies i la font exclosa encara fa temps d'espera, la regla fa exactament el que diu el seu abast. Un ping correcte originat al client no ho hauria demostrat mai, i per això el sentit de cada prova pertany al registre al costat del seu resultat. Guarda tots dos sentits al tiquet, o el proper lector repetirà la prova que no pot fallar.