NAS inaccessible per la VPN: adreça, camí de tornada o servei?
Un túnel privat necessita una ruta cap al NAS, un camí de resposta i un servei permès. Decidiu quin dels tres ha fallat abans de canviar les credencials.
Els túnels s'aixequen, els clients reben una adreça i el NAS no respon absolutament res. Aquest sol símptoma cobreix tres fallades sense relació, i l'ordre en què les proveu decideix quant durarà la reparació. L'adreçament va primer, perquè una subxarxa solapada pot enviar la vostra petició a un dispositiu desconegut. El camí de tornada va segon, perquè una petició que arriba sense resposta sembla idèntica a un servei tancat. El servei i el permís van al final, i només després que els dos primers estiguin provats.
Tres fallades que totes es llegeixen com a inaccessible
La selecció d'adreça, l'encaminament de tornada i l'autorització del servei produeixen el mateix missatge visible: no passa res. Tenen proves, responsables i correccions diferents, així que separar-les és tota la feina. Un ping que falla demostra poc per si sol, i un refús TCP correcte és, de fet, una bona notícia.
| 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 |
Llegiu la taula com un ordre de proves i no com una llista de causes. Cada fila limita la següent, perquè un refús ja demostra que l'adreçament i el camí de tornada funcionen. Passar vint minuts dins de regles de tallafoc abans de comprovar quina interfície ha triat la ruta és la manera més habitual de perdre una tarda. Treballeu de dalt a baix i atureu-vos a la primera fila que encaixi.
Condició u: és aquesta adreça el dispositiu correcte?
Anoteu la subxarxa del NAS i el rang que la VPN lliura als clients, i compareu tots dos amb la xarxa on és ara el vostre portàtil. En aquest recorregut el NAS és a 10.40.7.25 i el pool de la VPN és 10.40.9.0/24, dos rangs privats separats dins d'un mateix pla de lloc; una llar que faci servir 192.168.0.0/24 o 10.0.0.0/24 té moltes més possibilitats de xocar amb un d'ells.
Quan la xarxa local i la xarxa del NAS se solapen, el client envia aquest trànsit a la seva pròpia porta d'enllaç i pot arribar a un dispositiu no relacionat que casualment tingui la mateixa adreça. Verifiqueu el camí abans d'escriure credencials a qualsevol cosa que respongui.
ip -4 route get 10.40.7.25
traceroute -n -m 5 10.40.7.25La primera ordre indica la interfície i la porta d'enllaç que faria servir el nucli, i la segona mostra els primers salts que responen realment. Si les dues no coincideixen, creieu la consulta, perquè és el camí que farà el paquet. Una llista de salts que s'atura un salt abans del NAS també és una troballa i no un fracàs. Una consulta que es resol cap a l'adaptador físic en lloc del túnel acaba la investigació en aquest punt.
Condició dos: torna la resposta?
El client necessita una ruta cap al NAS, i la xarxa del NAS necessita un camí de tornada cap al pool de la VPN. El reenviament de la porta d'enllaç, les regles de tallafoc i la traducció deliberada afecten cadascun aquest parell. les notes de reenviament de strongSwan descriuen les opcions de ruta de tornada i de traducció per a una subxarxa privada darrere d'una porta d'enllaç.
Quan la petició arriba i la resposta surt per una altra porta d'enllaç, cap canvi de DNS repara l'asimetria. Una captura a les dues bandes ho resol en un sol intent, i també mostra si la traducció va reescriure l'origen al qual el NAS va respondre. L'administrador és el propietari d'aquesta frontera: permeteu només els serveis necessaris i el rang de clients de la VPN, i anoteu si es va triar encaminament o traducció.
Condició tres: hi és el servei i està permès?
Una pàgina de gestió i un servei de compartició de fitxers són punts finals diferents a la mateixa màquina, i un pot acceptar connexions mentre l'altre queda bloquejat pel tallafoc de l'amfitrió, la configuració del servei o un permís de compartició. Un dispositiu que respon amb un refús ja ha provat les dues primeres condicions, cosa que estreny molt la tercera.
Proveu amb el compte que realment necessita els fitxers, no amb el compte d'administrador de la instal·lació, perquè els drets administratius no poden reparar una ruta que falta i una ruta no pot concedir un permís de compartició. Els noms també hi tenen lloc: un nom de NAS descobert a casa sovint depèn de multicast local, que un túnel encaminat no transporta, així que proveu el nom d'amfitrió privat documentat pel fabricant o l'adreça mateixa per separar l'anomenament de l'accés.
Proveu des de fora de la xarxa del NAS i amplieu després a poc a poc
Una prova feta a la mateixa LAN amaga cada part incompleta del camí remot, i per això el primer intent remot correcte mereix una nota al registre de canvis. Feu les comprovacions des d'un client que només arribi al NAS pel túnel, i guardeu el text d'error original de cada intent.
nc -vz 10.40.7.25 445
smbclient -L 10.40.7.25 -U guestQuan el camí funcioni, transferiu un fitxer innocu i confirmeu el comportament de lectura o escriptura que realment necessiteu. Si les transferències grans s'encallen mentre les petites funcionen, el problema restant és el tractament de la mida del paquet o l'estabilitat de la connexió, no l'adreçament.
No publiqueu ports de compartició de fitxers ni d'administració a internet per evitar una fallada sense explicació. Repareu el camí privat, manteniu el programari del NAS amb suport i proveu la restauració de tot allò que copieu a través d'ell abans de confiar en aquesta còpia.