Conectado a OpenVPN pero sen ping nin compartición SMB? Comproba tres portas

O túnel levanta, o cliente recibe un enderezo e nada na LAN remota responde. O ping falla, a compartición non se abre e o rexistro do VPN parece limpo porque, desde o seu punto de vista, a sesión está san. Entre esa sesión e un ficheiro nun servidor hai tres portas independentes: a política de reenvío, os portos que necesita o servizo e o nome que escribiches no canto dun enderezo.

Cada porta falla cun síntoma distinto, e só a primeira está no servidor VPN.

O reenvío é unha política da cadea FORWARD

A aceptación do listener de OpenVPN ocorre en INPUT, por iso o túnel pode conectarse mentres se descarta cada paquete dirixido á LAN. O tráfico que chega por tun0 e sae pola interface da LAN atravesa FORWARD, e un host cunha política DROP predeterminada alí descártao en silencio. Comproba tanto o sysctl como a cadea antes de tocar calquera outra cousa: sysctl net.ipv4.ip_forward e iptables -L FORWARD -v -n.

Permite a dirección que pretendes e as respostas que lle pertencen, por exemplo unha regra accept da interface do túnel á interface da LAN máis unha regra stateful para tráfico established e related. Se a LAN está detrás doutro router, ese router necesita unha ruta de volta ao pool de clientes ou un source NAT no servidor VPN. Confirma esa ruta cun só ping antes de engadir máis regras, porque unha regra que non se pode acadar nunca aparece nun contador.

SMB necesita máis dun porto

Compartir ficheiros non é unha soa conversación TCP 445. O descubrimento usa UDP 137 e 138, as sesións NetBIOS antigas usan TCP 139 e as sesións SMB modernas usan TCP 445. Unha regra que só abre o 445 produce o caso desesperante no que unha unidade asignada funciona e a exploración da rede non, ou ao revés.

As transferencias grandes por un túnel tamén chocan con problemas de MSS que parecen unha compartición rota. Un SYN que anuncia o tamaño de segmento completo da LAN descártase polo MTU máis pequeno do túnel, e a conexión colga tras o handshake. Limitar o MSS na ruta de reenvío, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, elimina esa clase de bloqueo. Verifícao cunha copia dalgúns megabytes no canto dunha listaxe de directorio, porque as respostas pequenas pasan mesmo cando as transferencias grandes non.

O adaptador do túnel chega como un perfil de rede novo

Windows clasifica cada adaptador nun perfil de rede, e un adaptador de túnel novo adoita caer en Public, onde as regras de compartir ficheiros e impresoras están bloqueadas. É unha decisión do firewall do host no servidor de ficheiros, non un problema de encamiñamento no servidor VPN. Cambia a categoría a propósito con Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private despois de confirmar que a política o permite, porque a categoría tamén cambia que regras de entrada se aplican.

O mesmo perfil explica un ping que falla mentres o TCP 445 ten éxito: as solicitudes de eco descártanse en Public de forma predeterminada.

Os nomes non cruzan sós un túnel encamiñado

A resolución de nomes NetBIOS e o descubrimento local dependen de difusións que un túnel encamiñado non transporta. Por iso escribir o nome curto do servidor falla mentres o seu enderezo funciona, e a compartición parece rota cando só o está a consulta. Engade un rexistro DNS para o servidor no resolutor que entrega o túnel, ou usa o enderezo no atallo.

Se o despregamento aínda depende de WINS, configúrao no cliente no canto de esperar que apareza tráfico de difusión. Proba primeiro por enderezo para que un fallo de nome non se confunda cun fallo de firewall.

Proba unha capa á vez e le o primeiro fallo

Avanza cara arriba: fai ping á pasarela do túnel, fai ping a un host da LAN por enderezo, logo abre o porto do servizo con Test-NetConnection -ComputerName 10.8.0.5 -Port 445, e só entón autentícate na compartición. O primeiro paso que falla é a capa que hai que arranxar, e cada paso posterior é ruído ata que ese pase. Un ping que responde mentres o porto segue pechado apunta ao firewall propio do servidor de ficheiros, mentres que un porto que se abre pese a pings silenciosos apunta ao filtrado ICMP. Anota o primeiro paso que falla antes de cambiar nada, porque un segundo cambio oculta o resultado do primeiro.

Se o servidor VPN non é o router da LAN, confirma a ruta de volta nese router antes de engadir máis regras ao servidor. Sen ela, as solicitudes chegan ao host e as respostas saen pola ruta predeterminada cara a internet, o que desde o lado do cliente parece exactamente un descarte do firewall.

Mantén a conta da compartición separada do inicio de sesión do VPN nas túas notas, porque un túnel exitoso non di nada sobre os permisos de ficheiros. Expor SMB a internet para sortear unha regra que falta non é unha solución.