NAS inaccesibil prin VPN: adresă, cale de retur sau serviciu?
Un tunel privat are nevoie de o rută către NAS, de o cale de răspuns și de un serviciu permis. Stabiliți care dintre cele trei a eșuat înainte de a schimba datele de autentificare.
Tunelurile pornesc, clienții primesc o adresă, iar NAS-ul nu răspunde absolut deloc. Acest singur simptom acoperă trei defecțiuni fără legătură între ele, iar ordinea în care le testați decide cât durează reparația. Adresarea vine prima, pentru că o subrețea suprapusă poate trimite cererea către un dispozitiv străin. Calea de retur vine a doua, pentru că o cerere care ajunge fără răspuns arată identic cu un serviciu închis. Serviciul și permisiunea vin la final, și numai după ce primele două sunt dovedite.
Trei defecțiuni care toate se citesc ca inaccesibil
Alegerea adresei, rutarea de retur și autorizarea serviciului produc același mesaj vizibil: nu se întâmplă nimic. Au dovezi, responsabili și remedieri diferite, așa că separarea lor este întreaga sarcină. Un ping care eșuează dovedește puțin de unul singur, iar un refuz TCP reușit este de fapt o veste bună.
| 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 |
Citiți tabelul ca pe o ordine de teste, nu ca pe o listă de cauze. Fiecare rând îl limitează pe următorul, pentru că un refuz dovedește deja că adresarea și calea de retur funcționează. A petrece douăzeci de minute în regulile de firewall înainte de a verifica ce interfață a ales ruta este cea mai frecventă modalitate de a pierde o după-amiază. Lucrați de sus în jos și opriți-vă la primul rând care se potrivește.
Condiția unu: este acea adresă dispozitivul corect?
Notați subrețeaua NAS-ului și intervalul pe care VPN-ul îl dă clienților, apoi comparați ambele cu rețeaua în care se află laptopul dumneavoastră acum. În acest parcurs NAS-ul stă la 10.40.7.25 și pool-ul VPN este 10.40.9.0/24, două intervale private separate în cadrul unui singur plan de sit; o gospodărie care folosește 192.168.0.0/24 sau 10.0.0.0/24 are șanse mult mai mari să intre în conflict cu unul dintre ele.
Când rețeaua locală și rețeaua NAS-ului se suprapun, clientul trimite acel trafic către propria poartă de acces și poate ajunge la un dispozitiv fără legătură care are din întâmplare aceeași adresă. Verificați calea înainte de a tasta date de autentificare în orice răspunde.
ip -4 route get 10.40.7.25
traceroute -n -m 5 10.40.7.25Prima comandă numește interfața și poarta de acces pe care le-ar folosi nucleul, iar a doua arată primele salturi care răspund efectiv. Dacă cele două nu sunt de acord, credeți interogarea, pentru că aceea este calea pe care o va urma pachetul. O listă de salturi care se oprește cu un salt înainte de NAS este și ea o constatare, nu un eșec. O interogare care se rezolvă către adaptorul fizic în locul tunelului încheie investigația în acest punct.
Condiția doi: se întoarce răspunsul?
Clientul are nevoie de o rută către NAS, iar rețeaua NAS-ului are nevoie de o cale de retur către pool-ul VPN. Forwardarea la nivel de poartă de acces, regulile de firewall și traducerea deliberată afectează fiecare acea pereche. notele de forwardare ale strongSwan descriu opțiunile de rută de retur și de traducere pentru o subrețea privată în spatele unei porți de acces.
Când cererea ajunge și răspunsul pleacă prin altă poartă de acces, nicio modificare DNS nu repară asimetria. O captură pe ambele părți lămurește problema într-o singură încercare și arată și dacă traducerea a rescris sursa căreia i-a răspuns NAS-ul. Administratorul deține acea graniță: permiteți doar serviciile necesare și intervalul clienților VPN, și notați dacă s-a ales rutare sau traducere.
Condiția trei: există serviciul și este permis?
O pagină de administrare și un serviciu de partajare a fișierelor sunt puncte terminale diferite pe aceeași mașină, iar unul poate accepta conexiuni în timp ce celălalt este blocat de firewall-ul gazdei, de configurația serviciului sau de o permisiune de partajare. Un dispozitiv care răspunde cu un refuz a dovedit deja primele două condiții, ceea ce restrânge considerabil a treia.
Testați cu contul care are efectiv nevoie de fișiere, nu cu contul de administrator folosit la instalare, pentru că drepturile administrative nu pot repara o rută lipsă, iar o rută nu poate acorda o permisiune de partajare. Și numele își au locul aici: un nume de NAS descoperit acasă depinde adesea de multicast local, pe care un tunel rutat nu îl transportă, așa că încercați numele de gazdă privat documentat de producător sau adresa în sine pentru a separa denumirea de acces.
Testați din afara rețelei NAS-ului, apoi extindeți încet
Un test făcut în aceeași rețea LAN ascunde fiecare parte incompletă a căii la distanță, de aceea prima încercare la distanță reușită merită o notă în registrul de modificări. Rulați verificările de pe un client care ajunge la NAS numai prin tunel și păstrați textul original al erorii din fiecare încercare.
nc -vz 10.40.7.25 445
smbclient -L 10.40.7.25 -U guestOdată ce calea funcționează, transferați un fișier inofensiv și confirmați comportamentul de citire sau scriere de care aveți nevoie. Dacă transferurile mari se blochează în timp ce cele mici reușesc, problema rămasă este gestionarea dimensiunii pachetelor sau stabilitatea conexiunii, nu adresarea.
Nu publicați porturi de partajare a fișierelor sau de administrare pe internet pentru a ocoli o defecțiune neexplicată. Reparați calea privată, mențineți software-ul NAS-ului cu suport și testați restaurarea a tot ce copiați prin el înainte de a vă baza pe acea copie.