Nettverksdelinger vises ikke på en VPN? Oppdagingen stopper
En tunnel bærer ruter, ikke broadcast-oppdaging. Åpne delingen ved navn, bekreft adressen og porten, og skill deretter tilgangsnekt fra en tom liste.
Delingen åpnes når du skriver inn banen, og nettleseren for nettverk viser ingenting i det hele tatt. Den kombinasjonen er vanlig over en tunnel og som regel ikke en feil. Oppdaging spør det lokale segmentet; tilgjengelighet spør én vert. En rutet tunnel bærer det andre og ikke det første.
Oppdaging og tilgjengelighet er adskilt
En nettleserliste produseres av protokoller som annonserer tjenester til et lokalt segment og lytter etter annonseringene. Å åpne en deling ved navn er en direkte forbindelse til én vert. Det første trenger et broadcast- eller multicast-domene; det andre trenger en rute og en port.
Over en tunnel kan det andre fungere perfekt mens det første returnerer et tomt vindu. Behandler du det tomme vinduet som feilen, sendes du ut for å lete etter en ødelagt tunnel som gjør jobben sin.
Hvorfor nettleserlisten blir stående tom
Windows avviklet Computer Browser-tjenesten og deaktiverte SMB versjon 1 som standard, noe som fjernet maskineriet bak den gamle Network Neighborhood. Erstatninger som WS-Discovery, SSDP og multicast-DNS adresserer broadcast- eller multicast-grupper som bare finnes på en lokal lenke. En punkt-til-punkt-tunnel har ikke en slik lenke, og rutere videresender ikke disse gruppene som standard. Hver vert kan være tilgjengelig, og listen kan fortsatt være tom.
Noen programmer legger til sin egen oppdagingshjelper. Når den hjelperen virker, er det en funksjon i programmet, ikke en egenskap ved tunnelen.
Bruk eksplisitte navn, og bekreft deretter tilgang
En UNC-bane, en tilordnet stasjon eller en Finder-tilkobling til en SMB-adresse virker over tunnelen når navnet er løst opp og porten er åpen. Oppslaget kan komme fra DNS, fra et søketillegg som VPN-en leverer, eller fra en sentralt administrert hosts-oppføring. I et domene kan en katalogspørring liste opp datamaskinobjekter, og den listen er vanligvis den nærmeste erstatningen for en nettleservisning på et rutet nettverk. En portskanning av kjente prefikser er bare akseptabel på nettverk du drifter eller er uttrykkelig autorisert til å teste.
En vert som svarer lover ikke at delingen åpnes. En NAS kan ha en tillatelsesliste begrenset til sitt eget subnett, som avviser adresser fra VPN-poolen. Brannmurregelen til en filserver nevner kanskje bare det lokale subnettet. Kontoen du oppgir for delingen, kan være en lokal konto som aldri ble opprettet på den serveren, og å koble til via VPN oppretter den ikke.
Noen bedriftsprogrammer blokkerer bevisst lokal trafikk og trafikk fra virtuelle maskiner mens tunnelen er oppe. Den manglende tilgangen er policy, og rettelsen hører til administratoren, ikke til programmets rutetabell.
En diagnostisk rekkefølge som er verdt å gjenta
Gå gjennom lagene i rekkefølge: nå adressen, løs opp navnet, åpne port 445, autentiser, og les deretter delingstillatelsene. Hvert svar er separat, og å hoppe framover gir en selvsikker feil konklusjon. Først når alle er bestått, er oppdagingen verdt å undersøke.
nslookup fileserver.example.com
nc -vz fileserver.example.com 445
smbclient -L //fileserver.example.com -U EXAMPLE/jdoe
Legg igjen et notat med servernavnet, delingens bane, adressen den ble løst opp til og kontoen som virket. Hvis nettleserlisten senere fylles ut etter en tjenesterestart, må du behandle det som en oppdagingssærhet og ikke som bevis på at den tidligere ruten var feil. Notatet er det som lar neste person hoppe over det tomme vinduet.