NAS onbereikbaar oor die VPN: adres, terugroete of diens?
’n Privaat tonnel het ’n roete na die NAS, ’n antwoordroete en ’n toegelate diens nodig. Besluit watter van die drie gefaal het voordat jy aanmeldingsdata verander.
Tonnel staan op, kliënte kry ’n adres, en die NAS antwoord heeltemal niks. Daardie enkele simptoom dek drie onverwante foute, en die volgorde waarin jy hulle toets bepaal hoe lank die herstel duur. Adressering kom eerste, want ’n oorvleuelende subnet kan jou versoek na ’n vreemde toestel stuur. Die terugroete kom tweede, want ’n versoek wat aankom sonder ’n antwoord lyk identies aan ’n geslote diens. Diens en toestemming kom laaste, en eers nadat die eerste twee bewys is.
Drie foute wat almal as onbereikbaar gelees word
Adreskeuse, terugroetering en diensmagtiging lewer dieselfde sigbare boodskap: niks gebeur nie. Hulle het verskillende bewyse, verskillende eienaars en verskillende regstellings, so die skeiding daarvan is die hele taak. ’n Ping wat misluk bewys min op sy eie, en ’n geslaagde TCP-weiering is eintlik goeie nuus.
| 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 |
Lees die tabel as ’n orde van toetse eerder as ’n lys oorsake. Elke ry beperk die volgende, want ’n weiering bewys reeds dat adressering en die terugroete werk. Om twintig minute binne firewall-reëls deur te bring voordat jy kyk watter koppelvlak die roete gekies het, is die mees algemene manier om ’n middag te verloor. Werk van bo na onder en stop by die eerste ry wat pas.
Voorwaarde een: is daardie adres die regte toestel?
Skryf die NAS-subnet neer en die reeks wat die VPN aan kliënte gee, en vergelyk albei met die netwerk waarop jou skootrekenaar nou is. In hierdie deurloop sit die NAS by 10.40.7.25 en die VPN-poel is 10.40.9.0/24, twee afsonderlike private reekse binne een terreinplan; ’n huishouding wat 192.168.0.0/24 of 10.0.0.0/24 gebruik, het ’n baie groter kans om met een van hulle te bots.
Wanneer die plaaslike netwerk en die NAS-netwerk oorvleuel, stuur die kliënt daardie verkeer na sy eie poort en kan dit ’n onverwante toestel bereik wat toevallig dieselfde adres het. Verifieer die roete voordat jy aanmeldingsdata in enigiets intik wat antwoord.
ip -4 route get 10.40.7.25
traceroute -n -m 5 10.40.7.25Die eerste opdrag noem die koppelvlak en poort wat die kern sou gebruik, en die tweede wys die eerste spronge wat werklik antwoord. As die twee verskil, glo die opsoek, want dit is die roete wat die pakkie sal volg. ’n Spronglys wat een sprong voor die NAS stop, is ook ’n bevinding eerder as ’n mislukking. ’n Opsoek wat na die fisiese adapter in plaas van die tonnel oplos, beëindig die ondersoek op hierdie punt.
Voorwaarde twee: kom die antwoord terug?
Die kliënt het ’n roete na die NAS nodig, en die NAS-netwerk het ’n terugroete na die VPN-poel nodig. Poortdeurstuur, firewall-reëls en doelbewuste vertaling beïnvloed elkeen daardie paar. strongSwan se deurstuur-notas beskryf die terugroete- en vertalingskeuses vir ’n private subnet agter ’n poort.
Wanneer die versoek aankom en die antwoord via ’n ander poort vertrek, herstel geen DNS-verandering die asimmetrie nie. ’n Opname aan beide kante besleg dit in een poging, en dit wys ook of vertaling die bron herskryf het waarop die NAS geantwoord het. Die administrateur besit daardie grens: laat slegs die vereiste dienste en die VPN-kliëntreeks toe, en skryf neer watter van roetering of vertaling gekies is.
Voorwaarde drie: is die diens daar en toegelaat?
’n Bestuursbladsy en ’n lêerdelingsdiens is verskillende eindpunte op dieselfde boks, en die een kan verbindings aanvaar terwyl die ander deur die gasheer-firewall, die diensopset of ’n deletoestemming geblokkeer word. ’n Toestel wat met ’n weiering antwoord, het die eerste twee voorwaardes reeds bewys, wat die derde aansienlik vernou.
Toets met die rekening wat werklik die lêers nodig het, nie die administrateurrekening wat tydens die opstel gebruik is nie, want administratiewe regte kan nie ’n ontbrekende roete herstel nie en ’n roete kan nie ’n deletoestemming gee nie. Name hoort ook hier: ’n NAS-naam wat by die huis ontdek word, hang dikwels van plaaslike multicast af, wat ’n gerouteerde tonnel nie dra nie, so probeer die verskaffer se gedokumenteerde private gasheernaam of die adres self om naamgewing van toegang te skei.
Toets van buite die NAS-netwerk, en brei dan stadig uit
’n Toets wat op dieselfde LAN gedoen word, verberg elke onvolledige deel van die remote roete, en daarom verdien die eerste geslaagde remote poging ’n nota in die veranderingsrekord. Voer die kontroles uit vanaf ’n kliënt wat die NAS slegs deur die tonnel bereik, en hou die oorspronklike foutteks van elke poging.
nc -vz 10.40.7.25 445
smbclient -L 10.40.7.25 -U guestSodra die roete werk, dra ’n onskadelike lêer oor en bevestig die lees- of skryfgedrag wat jy werklik nodig het. As groot oordragte vasval terwyl klein een slaag, is die oorblywende probleem pakketgrootte-hantering of verbindingstabiliteit eerder as adressering.
Moenie lêerdeling- of administrasiepoorte na die internet publiseer om ’n onverklaarde fout te omseil nie. Herstel die private roete, hou die NAS-sagteware ondersteun, en toets die herstel van enigiets wat jy daaroor rugsteun voordat jy op daardie rugsteun staatmaak.