Tunneler kommer opp, klienter får en adresse, og NAS-en svarer ikke i det hele tatt. Det ene symptomet dekker tre uavhengige feil, og rekkefølgen du tester dem i avgjør hvor lang reparasjonen blir. Adresseringen kommer først, fordi et overlappende subnett kan sende forespørselen din til en fremmed enhet. Returveien kommer på andreplass, fordi en forespørsel som ankommer uten svar ser identisk ut med en lukket tjeneste. Tjeneste og tillatelse kommer til slutt, og først etter at de to første er bevist.

Tre feil som alle leses som utilgjengelig

Adressevalg, returruting og tjenesteautorisasjon gir samme synlige melding: ingenting skjer. De har ulike bevis, ulike eiere og ulike rettelser, så å skille dem er hele oppgaven. En ping som mislykkes beviser lite i seg selv, og en vellykket TCP-avvisning er faktisk gode nyheter.

ObservationMost likely conclusion
Route to the NAS address leaves the wrong interfaceOverlapping or missing private route
Request visible on the server, no reply seenReturn path, gateway forwarding or translation
TCP connection refused rather than droppedReachable host, service not listening or filtered
TCP works, login or file access failsShare permission, account or protocol version

Les tabellen som en rekkefølge av tester snarere enn en liste over årsaker. Hver rad begrenser den neste, fordi en avvisning allerede beviser at adressering og returvei virker. Å bruke tjue minutter inne i brannmurregler før du sjekker hvilket grensesnitt ruten valgte, er den vanligste måten å miste en ettermiddag. Arbeid ovenfra og ned, og stopp ved første rad som passer.

Betingelse én: er den adressen riktig enhet?

Skriv ned NAS-subnettet og området VPN-en deler ut til klienter, og sammenlign begge med nettverket laptopen din er på akkurat nå. I denne gjennomgangen ligger NAS-en på 10.40.7.25 og VPN-poolen er 10.40.9.0/24, to separate private områder innenfor én nettplan; en husstand som bruker 192.168.0.0/24 eller 10.0.0.0/24 har mye større sjanse for å kollidere med ett av dem.

Når det lokale nettverket og NAS-nettverket overlapper, sender klienten den trafikken til sin egen gateway og kan nå en urelatert enhet som tilfeldigvis har samme adresse. Verifiser veien før du skriver inn påloggingsinformasjon i det som måtte svare.

ip -4 route get 10.40.7.25
traceroute -n -m 5 10.40.7.25

Den første kommandoen navngir grensesnittet og gatewayen kjernen ville bruke, og den andre viser de første hoppene som faktisk svarer. Hvis de to er uenige, tro på oppslaget, fordi det er veien pakken vil ta. En hoppliste som stopper ett hopp før NAS-en er også et funn og ikke en feil. Et oppslag som løses til den fysiske adapteren i stedet for tunnelen avslutter undersøkelsen på dette punktet.

Betingelse to: kommer svaret tilbake?

Klienten trenger en rute mot NAS-en, og NAS-nettverket trenger en returvei mot VPN-poolen. Gateway-videresending, brannmurregler og bevisst oversettelse påvirker hver for seg det paret. strongSwans notater om videresending beskriver valgene for returrute og oversettelse for et privat subnett bak en gateway.

Når forespørselen ankommer og svaret går ut via en annen gateway, reparerer ingen DNS-endring asymmetrien. Et opptak på begge sider avgjør det i ett forsøk, og det viser også om oversettelsen skrev om kilden NAS-en svarte til. Administratoren eier den grensen: tillat bare tjenestene som trengs og VPN-klientområdet, og skriv ned om ruting eller oversettelse ble valgt.

Betingelse tre: finnes tjenesten og er den tillatt?

En administrasjonsside og en fildelingstjeneste er ulike endepunkter på samme boks, og den ene kan ta imot tilkoblinger mens den andre blokkeres av vertens brannmur, tjenestekonfigurasjonen eller en delingstillatelse. En enhet som svarer med en avvisning, har allerede bevist de to første betingelsene, noe som snevrer inn den tredje betraktelig.

Test med kontoen som faktisk trenger filene, ikke administratorkontoen fra oppsettet, siden administratorrettigheter ikke kan reparere en manglende rute, og en rute ikke kan gi en delingstillatelse. Navn hører også hjemme her: et NAS-navn som oppdages hjemme avhenger ofte av lokal multicast, som en rutet tunnel ikke bærer, så prøv leverandørens dokumenterte private vertsnavn eller selve adressen for å skille navngivning fra tilgang.

Test utenfra NAS-nettverket, og utvid deretter sakte

En test utført på samme LAN skjuler enhver ufullstendig del av fjernveien, og derfor fortjener det første vellykkede fjernforsøket et notat i endringsloggen. Kjør kontrollene fra en klient som bare når NAS-en gjennom tunnelen, og ta vare på den opprinnelige feilteksten fra hvert forsøk.

nc -vz 10.40.7.25 445
smbclient -L 10.40.7.25 -U guest

Når veien virker, overfør en uskyldig fil og bekreft lese- eller skriveatferden du faktisk trenger. Hvis store overføringer stopper mens små lykkes, er det gjenværende problemet håndtering av pakkestørrelse eller tilkoblingsstabilitet og ikke adressering.

Ikke publiser fildelings- eller administrasjonsporter til internett for å omgå en uforklart feil. Reparer den private veien, hold NAS-programvaren støttet, og test gjenoppretting av alt du sikkerhetskopierer over den før du stoler på sikkerhetskopien.

Relaterte artikler