NAS utilgængelig over VPN: adresse, returvej eller tjeneste?
En privat tunnel kræver en rute til NAS'en, en svarvej og en tilladt tjeneste. Afgør, hvilken af de tre der fejlede, før du ændrer legitimationsoplysninger.
Tunneller kommer op, klienter får en adresse, og NAS'en svarer slet ikke. Det ene symptom dækker tre uafhængige fejl, og den rækkefølge, du tester dem i, afgør, hvor lang reparationen tager. Adressering kommer først, fordi et overlapende subnet kan sende din anmodning til en fremmed enhed. Returvejen kommer nummer to, fordi en anmodning, der ankommer uden svar, ser identisk ud med en lukket tjeneste. Tjeneste og tilladelse kommer sidst, og først efter at de to første er bevist.
Tre fejl, der alle fremstår som utilgængelighed
Adressevalg, returrutning og tjenestegodkendelse giver samme brugervendte besked: der sker ingenting. De har forskellige beviser, forskellige ejere og forskellige rettelser, så adskillelsen af dem er hele opgaven. En ping, der fejler, beviser lidt i sig selv, og en vellykket TCP-afvisning er faktisk opmuntrende nyt.
| 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 |
Læs tabellen som en rækkefølge af test snarere end en liste af årsager. Hver række begrænser den næste, fordi en afvisning allerede beviser, at adressering og returvej virker. At bruge tyve minutter inde i firewallregler, før du tjekker, hvilken grænseflade ruten valgte, er den mest almindelige måde at miste en eftermiddag. Arbejd oppefra og ned, og stop ved den første række, der passer.
Betingelse et: er den adresse den rigtige enhed?
Skriv NAS'ens subnet ned og det interval, VPN'en udleverer til klienter, og sammenlign begge med det netværk, din bærbare er på lige nu. I denne gennemgang står NAS'en på 10.40.7.25, og VPN-puljen er 10.40.9.0/24, to separate private intervaller inden for én siteplan; en husstand, der bruger 192.168.0.0/24 eller 10.0.0.0/24, har en meget større chance for at kollidere med et af dem.
Når det lokale netværk og NAS-netværket overlapper, sender klienten den trafik til sin egen gateway og kan nå en ubeslægtet enhed, som tilfældigvis har samme adresse. Bekræft ruten, før du skriver legitimationsoplysninger ind i det, der svarer.
ip -4 route get 10.40.7.25
traceroute -n -m 5 10.40.7.25Den første kommando angiver den grænseflade og gateway, som kernen ville bruge, og den anden viser de første hop, der faktisk svarer. Hvis de to er uenige, tro på opslaget, fordi det er den vej, pakken vil tage. En hopliste, der stopper et hop før NAS'en, er også et fund snarere end en fejl. Et opslag, der opløses til den fysiske adapter i stedet for tunnelen, afslutter undersøgelsen på dette punkt.
Betingelse to: kommer svaret tilbage?
Klienten har brug for en rute mod NAS'en, og NAS-netværket har brug for en returvej mod VPN-puljen. Gateway-videresendelse, firewallregler og bevidst oversættelse påvirker hver især det par. strongSwans noter om videresendelse beskriver valgene for returrute og oversættelse for et privat subnet bag en gateway.
Når anmodningen ankommer, og svaret forlader via en anden gateway, reparerer ingen DNS-ændring asymmetrien. En optagelse på begge sider afgør det i ét forsøg, og den viser også, om oversættelse skrev kilden om, som NAS'en svarede til. Administratoren ejer den grænse: tillad kun de nødvendige tjenester og VPN-klientintervallet, og skriv ned, om der blev valgt routing eller oversættelse.
Betingelse tre: er tjenesten der og tilladt?
En administrationsside og en fildelingstjeneste er forskellige endepunkter på samme boks, og den ene kan acceptere forbindelser, mens den anden blokeres af værtens firewall, tjenestekonfigurationen eller en share-tilladelse. En enhed, der svarer med en afvisning, har allerede bevist de to første betingelser, hvilket indsnævrer den tredje betydeligt.
Test med den konto, der faktisk skal bruge filerne, frem for den administratorkonto, der blev brugt under opsætningen, da administrative rettigheder ikke kan reparere en manglende rute, og en rute ikke kan give en share-tilladelse. Navne hører også til her: et NAS-navn, der opdages derhjemme, afhænger ofte af lokal multicast, som en rutet tunnel ikke bærer, så prøv leverandørens dokumenterede private værtsnavn eller selve adressen for at skelne navngivning fra adgang.
Test udefra NAS-netværket og udvid derefter langsomt
En test udført på samme LAN skjuler enhver ufuldstændig del af den eksterne vej, og derfor fortjener det første vellykkede eksterne forsøg et notat i ændringsloggen. Kør kontrollerne fra en klient, der kun når NAS'en gennem tunnelen, og gem den oprindelige fejltekst fra hvert forsøg.
nc -vz 10.40.7.25 445
smbclient -L 10.40.7.25 -U guestNår vejen virker, overfør en harmløs fil, og bekræft den læse- eller skriveadfærd, du faktisk har brug for. Hvis store overførsler går i stå, mens små lykkes, er det resterende problem håndtering af pakkestørrelse eller forbindelsesstabilitet snarere end adressering.
Udgiv ikke fildelings- eller administrationsporte til internettet for at omgå en uforklarlig fejl. Reparer den private vej, hold NAS-softwaren understøttet, og test gendannelsen af alt, hvad du sikkerhedskopierer over den, før du stoler på den sikkerhedskopi.