Lokale enheter forsvinner på VPN: tre separate feil
Enheten kan fortsatt svare på adressen sin etter at den har forsvunnet fra listen. Oppdagelse, navneoppslag og tilgjengelighet svikter hver for seg, så test dem én om gangen.
En skriver som forsvinner fra enhetslisten når VPN-en kommer opp, kan fortsatt svare på adressen sin. Listen fylles av oppdagelse, navnet kan komme fra en resolver, og selve tjenesten nås over en socket, og de tre kan svikte uavhengig av hverandre. Å sammenligne hva som virker på hvert lag forteller deg hvilken funksjon du skal endre. Slår du først på alle unntak for lokal tilgang, fjerner du bevisene.
Det er forskjellen på en enhet som mangler og en enhet som bare ikke annonseres.
Oppdagelse, navn og tilgjengelighet er tre lag
Oppdagelsesprotokoller er avhengige av multicast eller broadcast, og disse krysser ikke en rutet tunnel som standard, og derfor kan en enhet forsvinne fra en liste mens den fortsatt er fullt tilgjengelig. Navneoppslag er et andre lag: en VPN kan bytte resolver, og et navn som det lokale nettet tidligere svarte på, kan nå besvares andre steder eller ikke i det hele tatt. Tilgjengelighet er det tredje: en rute, en brannmurregel og en lyttende tjeneste. Hvert lag kan bryte sammen mens de to andre er i orden.
Test dem nedenfra og opp. En enkelt tilgjengelighetstest gjør oppdelingen tydelig: nc -vz 192.168.1.20 443 enten lykkes, som betyr at veien og tjenesten er i orden og navnet er den mistenkte, eller mislykkes, som flytter spørsmålet til ruting og policy. Spør så etter navnet. Den første feilen du treffer, er laget du skal jobbe med, og lagene over kan ikke kompensere for den.
Spør først etter adressen, deretter etter vertsnavnet
Hvis adressen svarer og navnet ikke, er problemet oppslag og ikke ruting. En VPN-klient som installerer sin egen resolver, kan endre hvilken server som svarer på lokale navn, og en som ikke videresender det lokale domenet, lar navnet stå ubesvart. Hvis adressen også svikter, er det veien som er problemet: en standardrute gjennom tunnelen, en blokkering av lokal trafikk på klientsiden eller en brannmurregel som bare tillater det fysiske grensesnittet.
Hvis begge virker, men automatisk oppdagelse ikke gjør det, annonserer enheten seg rett og slett ikke gjennom tunnelen. Det er forventet atferd for multicast-basert oppdagelse, ikke en konfigurasjonsfeil. Å legge til enheten via adresse er vanligvis den ærlige løsningen.
Hva bryteren for lokal tilgang egentlig endrer
En innstilling for lokalnettilgang tillater vanligvis at trafikk til det direkte tilkoblede subnettet går utenom tunnelen, og den gjør forskjellige ting i forskjellige klienter. Den konfigurerer ikke videresending til et fjernkontor og endrer ikke vertens brannmur eller applikasjonens egne tillatelser. Den gjør heller ikke et overlappende subnett entydig. Les klientens dokumentasjon for hva innstillingen dekker, før du slår den på bredt.
Et smalt unntak for én klarert enhet er bedre enn en generell tillatelse, særlig på et gjestenett der blokkeringen kan være bevisst. En privat adresse er ikke en identitetskontroll, så valget avhenger av nettet du er på.
Når nettene overlapper
Hvis hjemmenettet og fjernnettet bruker samme område, blir rutingen tvetydig, og verken en bryter for lokal tilgang eller et unntak løser det. To tjenester på samme adresse kan ikke begge nås, og hvilken som vinner avhenger av rutespesifisitet og rekkefølge, ikke av hensikt. Løsningen er adresseplanlegging, ikke en klientinnstilling. Kontroller områdene før du bruker en kveld på skriveren.
For en enhet bak fjernporten eier operatøren videresending, vertspolicy og returruten. En lokal avkrysningsboks i klienten kan ikke levere noen av dem, og å be om det er mer produktivt enn å eksperimentere med brytere.
Noter hvilket lag som feilet og hva du endret. Den neste enheten vil feile ett av de samme tre stedene.