Il ping funziona in un solo senso: perché Windows scarta l'eco del server

Il tuo client fa ping verso il server, il server non riesce a fare ping verso il client, e il tunnel trasporta pacchetti con chiarezza in entrambe queste affermazioni. Ciò che cambia non è il percorso ma il primo pacchetto di ogni prova: uno è una risposta a un flusso che Windows già segue, l'altro è una nuova richiesta in ingresso che nessuna regola ha ammesso. Questa differenza spiega la maggior parte delle segnalazioni di ping unidirezionale e indica direttamente la regola che devi scrivere. Due prove in sensi opposti separano i casi in circa un minuto.

Due sensi, due decisioni diverse

Quando il client invia la richiesta di eco, il firewall di Windows vede una connessione in uscita che ha deciso di consentire. La risposta torna dentro quel flusso già stabilito, quindi il motore con stato la ammette senza consultare alcuna regola in ingresso per ICMP. Questo significa filtraggio con stato nella pratica, e la regola che nessuno ha scritto non c'entra. Il successo del client non dice quindi nulla sulla politica in ingresso.

Quando il server invia la richiesta per primo, nessuno stato le corrisponde. Windows tratta il pacchetto come una nuova connessione in ingresso e interroga la politica in ingresso, che per impostazione predefinita non prevede nulla per le richieste di eco provenienti da fonti arbitrarie.

Il successo del client ha quindi dimostrato che l'ICMP in uscita e il percorso di ritorno funzionano. Non ha mai messo alla prova la decisione in ingresso, e la conclusione naturale, che il firewall vada bene, è ragionevole e sbagliata. Ecco perché l'errore si ripete nei ticket che già contengono la prova.

Segui il pacchetto finché non scompare

Conferma gli indirizzi prima di cambiare qualsiasi cosa: usa l'indirizzo del tunnel che il client ha davvero e verifica che il server instradi verso di esso e non verso un indirizzo LAN dietro il client. I due guasti sembrano identici dal prompt del server, perché entrambi finiscono in un timeout. Dove muore il pacchetto è l'unico fatto che decide cosa cambiare.

Se la richiesta raggiunge l'interfaccia del tunnel e nulla esce, il firewall locale è la causa probabile. Se non raggiunge mai l'interfaccia, la risposta è più a monte: una rotta sul server, una politica in uscita o la consegna tra peer della VPN stessa.

Cattura sull'interfaccia del tunnel del client mentre il server fa ping. Vedere la richiesta arrivare senza una risposta accanto è la prova che giustifica scrivere una regola di Windows. Non vedere nulla ti manda più a monte, e una regola aggiunta in quello stato rende la macchina solo più permissiva per un pacchetto che non è mai arrivato. In ogni caso la cattura costa meno delle congetture che sostituisce.

Limita una regola invece di aprire ICMP

Identifica l'adattatore e la sua categoria attuale prima di scrivere qualsiasi cosa, perché entrambi compaiono nell'ambito che stai per impostare. Quell'alias è il nome dell'interfaccia di Windows, che non è necessariamente il nome del profilo VPN importato. I comandi qui sotto elencano ciò che esiste, poi mostrano in anteprima una regola limitata senza applicarla.

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 è la richiesta di eco, l'unico messaggio a cui il server deve ricevere risposta. Limitala all'indirizzo del tunnel del server e all'interfaccia del tunnel, e lascia il profilo così come l'adattatore è davvero. Rinominare una rete per farla combaciare con un esempio è una modifica separata con conseguenze proprie.

Cosa non copre la regola

L'eco IPv6 è un altro protocollo con un altro tipo di messaggio, quindi una regola ICMPv4 non dice nulla al riguardo, e un tunnel che trasporta entrambe le famiglie ha bisogno della propria regola per l'altra. Questa regola non apre nient'altro: RDP, condivisione file e ogni altro servizio dipendono ancora dalla propria politica. È tutto il senso di limitare una regola stretta invece di abilitare un permesso ICMP ampio. Il permesso ampio è la soluzione facile e quella che sopravvive più a lungo, perché poi nessuno se ne accorge.

Su un dispositivo gestito la regola può essere sostituita al prossimo aggiornamento dei criteri, quindi il proprietario dei criteri deve fare la modifica equivalente e non un amministratore locale. Scrivi l'intenzione nel ticket insieme al comando, perché un aggiornamento cancellerà il comando e lascerà intatto il requisito. I due non sono lo stesso artefatto, e solo uno dei due sopravvive.

Leggi il risultato nel verso giusto

Applicata la regola, fai ping dal server e conferma che una risposta raggiunga il client, poi fai ping da una sorgente che deve restare esclusa e conferma che non arrivi. Ripeti la prova di raggiungibilità sull'altra famiglia di indirizzi se il tunnel ne trasporta una.

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

Stampare la regola entrata in vigore è più utile che fidarsi del comando che l'ha creata, perché un'anteprima e una regola applicata sono stati diversi. Se il filtro degli indirizzi mostra la sorgente voluta e la sorgente esclusa va ancora in timeout, la regola fa esattamente ciò che dice il suo ambito. Un ping riuscito partito dal client non l'avrebbe mai dimostrato, ed è per questo che il verso di ogni prova appartiene al verbale accanto al suo esito. Conserva entrambi i versi nel ticket, altrimenti il prossimo lettore ripeterà la prova che non può fallire.