NAS inaccesible pola VPN: enderezo, camiño de volta ou servizo?
Un túnel privado necesita unha ruta cara ao NAS, un camiño de resposta e un servizo permitido. Decida cal dos tres fallou antes de cambiar as credenciais.
Os túneles levántanse, os clientes reciben un enderezo e o NAS non responde absolutamente nada. Ese único síntoma cobre tres fallos sen relación, e a orde na que os probe decide canto dura a reparación. O enderezanento vai primeiro, porque unha subrede solapada pode enviar a súa petición a un dispositivo alleo. O camiño de volta vai segundo, porque unha petición que chega sen resposta parece idéntica a un servizo pechado. O servizo e o permiso van ao final, e só despois de probar os dous primeiros.
Tres fallos que todos se len como inaccesible
A selección de enderezo, o encamiñamento de volta e a autorización do servizo producen a mesma mensaxe visible: non pasa nada. Teñen probas, responsables e correccións distintas, así que separalos é toda a tarefa. Un ping que falla demostra pouco por si só, e un rexeitamento TCP correcto é en realidade unha boa noticia.
| Observation | Most likely conclusion |
|---|---|
| Route to the NAS address leaves the wrong interface | Overlapping or missing private route |
| Request visible on the server, no reply seen | Return path, gateway forwarding or translation |
| TCP connection refused rather than dropped | Reachable host, service not listening or filtered |
| TCP works, login or file access fails | Share permission, account or protocol version |
Lea a táboa como unha orde de probas e non como unha lista de causas. Cada fila limita a seguinte, porque un rexeitamento xa demostra que o enderezanento e o camiño de volta funcionan. Pasar vinte minutos dentro de regras de devasas antes de comprobar que interface escolleu a ruta é a forma máis habitual de perder unha tarde. Traballa de arriba abaixo e detense na primeira fila que encaixe.
Condición un: é ese enderezo o dispositivo correcto?
Anote a subrede do NAS e o rango que a VPN entrega aos clientes, e compare ambos coa rede na que está o seu portátil agora mesmo. Neste percorrido o NAS está en 10.40.7.25 e o conxunto da VPN é 10.40.9.0/24, dous rangos privados separados dentro dun mesmo plan de sitio; un fogar que use 192.168.0.0/24 ou 10.0.0.0/24 ten moitas máis posibilidades de chocar cun deles.
Cando a rede local e a rede do NAS se solapan, o cliente envía ese tráfico á súa propia pasarela e pode chegar a un dispositivo non relacionado que casualmente teña o mesmo enderezo. Verifique o camiño antes de escribir credenciais en calquera cousa que responda.
ip -4 route get 10.40.7.25
traceroute -n -m 5 10.40.7.25A primeira orde indica a interface e a pasarela que usaría o núcleo, e a segunda mostra os primeiros saltos que responden de verdade. Se as dúas non coinciden, crea a consulta, porque é o camiño que tomará o paquete. Unha lista de saltos que se detén un salto antes do NAS tamén é un achado e non un fallo. Unha consulta que se resolve cara ao adaptador físico en lugar do túnel remata a investigación neste punto.
Condición dous: volve a resposta?
O cliente necesita unha ruta cara ao NAS, e a rede do NAS necesita un camiño de volta cara ao conxunto da VPN. O reenvío da pasarela, as regras de devasas e a tradución deliberada afectan cada un ese par. as notas de reenvío de strongSwan describen as opcións de ruta de volta e de tradución para unha subrede privada detrás dunha pasarela.
Cando a petición chega e a resposta sae por outra pasarela, ningún cambio de DNS repara a asimetría. Unha captura nos dous lados resólveo nun só intento, e tamén mostra se a tradución reescribiu a orixe á que respondeu o NAS. O administrador é dono desa fronteira: permita só os servizos necesarios e o rango de clientes da VPN, e anote se se escolleu encamiñamento ou tradución.
Condición tres: está o servizo e está permitido?
Unha páxina de xestión e un servizo de compartición de ficheiros son puntos finais distintos na mesma máquina, e un pode aceptar conexións mentres o outro queda bloqueado pola devasa do hospedante, a configuración do servizo ou un permiso de compartición. Un dispositivo que responde cun rexeitamento xa probou as dúas primeiras condicións, o que estreita moito a terceira.
Probe coa conta que realmente necesita os ficheiros, non coa conta de administrador da instalación, porque os dereitos administrativos non poden reparar unha ruta que falta e unha ruta non pode conceder un permiso de compartición. Os nomes tamén teñen cabida aquí: un nome de NAS descuberto na casa adoita depender de multicast local, que un túnel encamiñado non transporta, así que probe o nome de host privado documentado polo fabricante ou o propio enderezo para separar a denominación do acceso.
Probe desde fóra da rede do NAS e amplíe despois aos poucos
Unha proba feita na mesma LAN agocha cada parte incompleta do camiño remoto, e por iso o primeiro intento remoto correcto merece unha nota no rexistro de cambios. Execute as comprobacións desde un cliente que só chegue ao NAS polo túnel, e garde o texto de erro orixinal de cada intento.
nc -vz 10.40.7.25 445
smbclient -L 10.40.7.25 -U guestCando o camiño funcione, transfira un ficheiro inofensivo e confirme o comportamento de lectura ou escritura que realmente necesita. Se as transferencias grandes se atascan mentres as pequenas funcionan, o problema restante é o tratamento do tamaño de paquete ou a estabilidade da conexión, non o enderezanento.
Non publique portos de compartición de ficheiros nin de administración en internet para evitar un fallo sen explicación. Repare o camiño privado, manteña o software do NAS con soporte e probe a restauración de todo o que copie a través del antes de confiar nesa copia.