Ligado ao OpenVPN mas sem ping nem partilha SMB? Verifique três portas

O túnel sobe, o cliente recebe um endereço e nada na LAN remota responde. O ping falha, a partilha não abre e o registo do VPN parece limpo porque, do seu ponto de vista, a sessão está saudável. Entre essa sessão e um ficheiro num servidor há três portas independentes: a política de encaminhamento, as portas de que o serviço precisa e o nome que escreveu em vez de um endereço.

Cada porta falha com um sintoma diferente, e só a primeira está no servidor VPN.

O encaminhamento é uma política da cadeia FORWARD

A aceitação do listener do OpenVPN acontece em INPUT, por isso o túnel consegue ligar-se enquanto cada pacote dirigido à LAN é descartado. O tráfego que chega em tun0 e sai pela interface da LAN atravessa FORWARD, e um anfitrião com política DROP predefinida ali descarta-o em silêncio. Verifique tanto o sysctl como a cadeia antes de tocar em qualquer outra coisa: sysctl net.ipv4.ip_forward e iptables -L FORWARD -v -n.

Permita a direção que pretende e as respostas que lhe pertencem, por exemplo uma regra accept da interface do túnel para a interface da LAN mais uma regra stateful para tráfego established e related. Se a LAN estiver atrás de outro router, esse router precisa de uma rota de regresso ao pool de clientes ou de um source NAT no servidor VPN. Confirme esse caminho com um único ping antes de acrescentar mais regras, porque uma regra que não pode ser alcançada nunca aparece num contador.

O SMB precisa de mais do que uma porta

A partilha de ficheiros não é uma única conversa TCP 445. A descoberta usa UDP 137 e 138, as sessões NetBIOS mais antigas usam TCP 139 e as sessões SMB modernas usam TCP 445. Uma regra que só abre a 445 produz o caso exasperante em que uma unidade mapeada funciona e a navegação da rede não, ou o contrário.

Transferências grandes por um túnel também batem em problemas de MSS que parecem uma partilha avariada. Um SYN que anuncia o tamanho completo do segmento da LAN é descartado pelo MTU menor do túnel, e a ligação fica pendurada após o handshake. Limitar o MSS no caminho de encaminhamento, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, elimina esse tipo de bloqueio. Verifique com uma cópia de alguns megabytes em vez de uma listagem de diretório, porque as respostas pequenas passam mesmo quando as transferências grandes não passam.

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

O Windows classifica cada adaptador num perfil de rede, e um adaptador de túnel novo cai normalmente em Public, onde as regras de partilha de ficheiros e impressoras estão bloqueadas. É uma decisão da firewall do anfitrião no servidor de ficheiros, não um problema de encaminhamento no servidor VPN. Mude a categoria deliberadamente com Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private depois de confirmar que a política o permite, porque a categoria também muda que regras de entrada se aplicam.

O mesmo perfil explica um ping que falha enquanto o TCP 445 tem êxito: os pedidos de eco são descartados em Public por predefinição.

Os nomes não atravessam sozinhos um túnel encaminhado

A resolução de nomes NetBIOS e a descoberta local dependem de difusões que um túnel encaminhado não transporta. Por isso escrever o nome curto do servidor falha enquanto o endereço funciona, e a partilha parece avariada quando só a pesquisa está. Acrescente um registo DNS para o servidor no resolver que o túnel distribui, ou use o endereço no atalho.

Se a implementação ainda depende do WINS, configure-o no cliente em vez de esperar que apareça tráfego de difusão. Teste primeiro por endereço para que uma falha de nome não seja confundida com uma falha de firewall.

Teste uma camada de cada vez e leia a primeira falha

Avance para cima: faça ping à gateway do túnel, faça ping a um anfitrião da LAN por endereço, depois abra a porta do serviço com Test-NetConnection -ComputerName 10.8.0.5 -Port 445, e só então autentique-se na partilha. O primeiro passo que falha é a camada a corrigir, e cada passo seguinte é ruído até esse passar. Um ping que responde enquanto a porta fica fechada aponta para a firewall do próprio servidor de ficheiros, enquanto uma porta que abre apesar de pings silenciosos aponta para filtragem ICMP. Anote o primeiro passo que falha antes de mudar algo, porque uma segunda mudança esconde o resultado da primeira.

Se o servidor VPN não é o router da LAN, confirme a rota de regresso nesse router antes de acrescentar mais regras ao servidor. Sem ela, os pedidos chegam ao anfitrião e as respostas saem pela rota predefinida para a internet, o que do lado do cliente parece exatamente um descarte da firewall.

Mantenha a conta da partilha separada do início de sessão do VPN nas suas notas, porque um túnel bem-sucedido não diz nada sobre permissões de ficheiros. Expor o SMB à internet para contornar uma regra em falta não é uma solução.