Connectat a OpenVPN però sense ping ni compartició SMB? Comproveu tres portes

El túnel s’aixeca, el client obté una adreça i res de la LAN remota respon. El ping falla, la compartició no s’obre i el registre del VPN sembla net perquè, des del seu punt de vista, la sessió és saludable. Entre aquesta sessió i un fitxer en un servidor hi ha tres portes independents: la política de reenviament, els ports que necessita el servei i el nom que heu escrit en lloc d’una adreça.

Cada porta falla amb un símptoma diferent, i només la primera és al servidor VPN.

El reenviament és una política de la cadena FORWARD

L’acceptació de l’oient OpenVPN passa per INPUT, i per això el túnel es pot connectar mentre es descarta cada paquet destinat a la LAN. El trànsit que arriba a tun0 i surt per la interfície de la LAN travessa FORWARD, i un amfitrió amb una política DROP per defecte allà el descarta en silenci. Comproveu tant el sysctl com la cadena abans de tocar res més: sysctl net.ipv4.ip_forward i iptables -L FORWARD -v -n.

Permeteu la direcció que voleu i les respostes que hi pertanyen, per exemple una regla accept de la interfície del túnel a la interfície de la LAN més una regla stateful per al trànsit established i related. Si la LAN és darrere d’un altre encaminador, aquest encaminador necessita una ruta de tornada al pool de clients o un source NAT al servidor VPN. Confirmeu aquest camí amb un sol ping abans d’afegir més regles, perquè una regla que no es pot assolir mai no apareix en un comptador.

L’SMB necessita més d’un port

La compartició de fitxers no és una sola conversa TCP 445. La descoberta fa servir UDP 137 i 138, les sessions NetBIOS antigues fan servir TCP 139 i les sessions SMB modernes fan servir TCP 445. Una regla que només obre el 445 produeix el cas desesperant en què una unitat mapada funciona i la navegació per la xarxa no, o al revés.

Les transferències grans per un túnel també topen amb problemes d’MSS que semblen una compartició trencada. Un SYN que anuncia la mida de segment completa de la LAN es descarta per l’MTU més petit del túnel, i la connexió es penja després de l’apretada de mans. Limitar l’MSS al camí de reenviament, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, elimina aquesta classe de bloqueig. Verifiqueu-ho amb una còpia d’uns quants megabytes en lloc d’un llistat de directori, perquè les respostes petites passen fins i tot quan les transferències grans no ho fan.

L’adaptador del túnel arriba com un perfil de xarxa nou

Windows classifica cada adaptador en un perfil de xarxa, i un adaptador de túnel nou sol caure a Public, on les regles de compartició de fitxers i impressores estan bloquejades. És una decisió del tallafoc de l’amfitrió al servidor de fitxers, no un problema d’encaminament al servidor VPN. Canvieu la categoria deliberadament amb Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private després de confirmar que la política ho permet, perquè la categoria també canvia quines regles d’entrada s’apliquen.

El mateix perfil explica un ping que falla mentre el TCP 445 té èxit: les peticions d’eco es descarten a Public per defecte.

Els noms no travessen sols un túnel encaminat

La resolució de noms NetBIOS i la descoberta local depenen de difusions que un túnel encaminat no transporta. Per això escriure el nom curt del servidor falla mentre la seva adreça funciona, i la compartició sembla trencada quan només ho està la consulta. Afegiu un registre DNS per al servidor al resolutor que reparteix el túnel, o feu servir l’adreça a la drecera.

Si el desplegament encara depèn de WINS, configureu-lo al client en lloc d’esperar que aparegui trànsit de difusió. Proveu primer per adreça perquè un error de nom no es confongui amb un error de tallafoc.

Proveu una capa alhora i llegiu el primer error

Avanceu cap amunt: feu ping a la passarel·la del túnel, feu ping a un amfitrió de la LAN per adreça, després obriu el port del servei amb Test-NetConnection -ComputerName 10.8.0.5 -Port 445, i només llavors autentiqueu-vos a la compartició. El primer pas que falla és la capa a arreglar, i cada pas posterior és soroll fins que aquell passa. Un ping que respon mentre el port continua tancat assenyala el tallafoc propi del servidor de fitxers, mentre que un port que s’obre malgrat pings silenciosos assenyala el filtratge ICMP. Anoteu el primer pas que falla abans de canviar res, perquè un segon canvi amaga el resultat del primer.

Si el servidor VPN no és l’encaminador de la LAN, confirmeu la ruta de tornada en aquest encaminador abans d’afegir més regles al servidor. Sense això, les peticions arriben a l’amfitrió i les respostes surten per la ruta per defecte cap a internet, cosa que des del costat del client sembla exactament un descart del tallafoc.

Manteniu el compte de compartició separat de l’inici de sessió del VPN a les vostres notes, perquè un túnel amb èxit no diu res dels permisos de fitxers. Exposar SMB a internet per esquivar una regla que falta no és cap solució.