Connessi a OpenVPN ma nessun ping né condivisione SMB? Controllate tre porte

Il tunnel sale, il client ottiene un indirizzo e nulla sulla LAN remota risponde. Il ping fallisce, la condivisione non si apre e il registro del VPN sembra pulito perché, dal suo punto di vista, la sessione è sana. Tra quella sessione e un file su un server ci sono tre porte indipendenti: la politica di inoltro, le porte di cui ha bisogno il servizio e il nome che avete digitato al posto di un indirizzo.

Ogni porta fallisce con un sintomo diverso, e solo la prima si trova sul server VPN.

L’inoltro è una politica della catena FORWARD

L’accettazione del listener OpenVPN avviene su INPUT, per questo il tunnel può connettersi mentre ogni pacchetto diretto alla LAN viene scartato. Il traffico che arriva su tun0 ed esce dall’interfaccia della LAN attraversa FORWARD, e un host con politica DROP predefinita lì lo scarta in silenzio. Controllate sia il sysctl sia la catena prima di toccare qualsiasi altra cosa: sysctl net.ipv4.ip_forward e iptables -L FORWARD -v -n.

Consentite la direzione che volete e le risposte che le appartengono, per esempio una regola accept dall’interfaccia del tunnel all’interfaccia della LAN più una regola stateful per il traffico established e related. Se la LAN sta dietro un altro router, quel router ha bisogno di una rotta di ritorno verso il pool dei client o di un source NAT sul server VPN. Confermate quel percorso con un solo ping prima di aggiungere altre regole, perché una regola che non si può raggiungere non compare mai in un contatore.

SMB ha bisogno di più di una porta

La condivisione di file non è una sola conversazione TCP 445. La scoperta usa UDP 137 e 138, le sessioni NetBIOS più vecchie usano TCP 139 e le sessioni SMB moderne usano TCP 445. Una regola che apre solo 445 produce il caso esasperante in cui un’unità mappata funziona e la navigazione della rete no, o il contrario.

I trasferimenti grandi attraverso un tunnel incontrano anche problemi di MSS che sembrano una condivisione rotta. Un SYN che annuncia la dimensione completa del segmento della LAN viene scartato dall’MTU più piccolo del tunnel, e la connessione resta appesa dopo lo handshake. Il clamping dell’MSS sul percorso di inoltro, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, elimina quella classe di blocco. Verificate con una copia di qualche megabyte invece che con un elenco di cartelle, perché le risposte piccole passano anche quando i trasferimenti grandi non passano.

L’adattatore del tunnel arriva come un nuovo profilo di rete

Windows classifica ogni adattatore in un profilo di rete, e un adattatore di tunnel nuovo di solito finisce in Public, dove le regole di condivisione di file e stampanti sono bloccate. È una decisione del firewall dell’host sul file server, non un problema di routing sul server VPN. Cambiate la categoria deliberatamente con Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private dopo aver confermato che la politica lo consente, perché la categoria cambia anche quali regole in ingresso si applicano.

Lo stesso profilo spiega un ping che fallisce mentre TCP 445 riesce: le richieste di eco vengono scartate in Public per impostazione predefinita.

I nomi non attraversano da soli un tunnel instradato

La risoluzione dei nomi NetBIOS e la scoperta locale si basano su trasmissioni che un tunnel instradato non trasporta. Digitare il nome breve del server fallisce quindi mentre il suo indirizzo funziona, e la condivisione sembra rotta quando lo è solo la ricerca. Aggiungete un record DNS per il server sul resolver che il tunnel distribuisce, oppure usate l’indirizzo nel collegamento.

Se la distribuzione dipende ancora da WINS, configuratelo sul client invece di sperare che compaia traffico di trasmissione. Testate prima per indirizzo, così un guasto del nome non venga scambiato per un guasto del firewall.

Testate uno strato alla volta e leggete il primo guasto

Salite: fate ping al gateway del tunnel, fate ping a un host della LAN per indirizzo, poi aprite la porta del servizio con Test-NetConnection -ComputerName 10.8.0.5 -Port 445, e solo dopo autenticatevi sulla condivisione. Il primo passo che fallisce è lo strato da correggere, e ogni passo successivo è rumore finché quello non passa. Un ping che risponde mentre la porta resta chiusa indica il firewall del file server stesso, mentre una porta che si apre nonostante ping silenziosi indica il filtraggio ICMP. Annotate il primo passo che fallisce prima di cambiare qualcosa, perché un secondo cambiamento nasconde il risultato del primo.

Se il server VPN non è il router della LAN, confermate la rotta di ritorno su quel router prima di aggiungere altre regole al server. Senza di essa le richieste raggiungono l’host e le risposte escono dalla rotta predefinita verso internet, il che dal lato client sembra esattamente uno scarto del firewall.

Tenete l’account della condivisione separato dall’accesso VPN nelle vostre note, perché un tunnel riuscito non dice nulla sui permessi dei file. Esporre SMB a internet per aggirare una regola mancante non è una soluzione.