Lokale enheder forsvinder på VPN: tre separate fejl

En printer, der forsvinder fra enhedslisten, når VPN’et kommer op, kan stadig svare på sin adresse. Listen fyldes op af opdagelse, navnet kan komme fra en resolver, og selve tjenesten nås over en socket, og de tre kan fejle uafhængigt. At sammenligne, hvad der virker på hvert lag, fortæller dig, hvilken funktion du skal ændre. Hvis du først slår alle undtagelser for lokal adgang til, fjerner du beviserne.

Det er forskellen på en enhed, der mangler, og en enhed, der blot ikke annonceres.

Opdagelse, navne og tilgængelighed er tre lag

Opdagelsesprotokoller er afhængige af multicast eller broadcast, og de krydser ikke en routet tunnel som standard, og derfor kan en enhed forsvinde fra en liste, mens den fortsat er fuldt tilgængelig. Navneopløsning er et andet lag: en VPN kan skifte resolver, og et navn, som det lokale netværk tidligere svarede på, kan nu besvares andre steder eller slet ikke. Tilgængelighed er det tredje: en rute, en firewallregel og en lyttende tjeneste. Hvert lag kan gå i stykker, mens de to andre er i orden.

Test dem nedefra og op. En enkelt tilgængelighedstest gør opdelingen tydelig: nc -vz 192.168.1.20 443 enten lykkes, hvilket betyder, at stien og tjenesten er i orden, og navnet er den mistænkte, eller fejler, hvilket flytter spørgsmålet til routing og politik. Spørg så efter navnet. Den første fejl, du støder på, er det lag, du skal arbejde på, og lagene ovenover kan ikke kompensere for den.

Spørg først efter adressen, derefter efter værtsnavnet

Hvis adressen svarer, og navnet ikke gør, er problemet opløsning og ikke routing. En VPN-klient, der installerer sin egen resolver, kan ændre, hvilken server der svarer på lokale navne, og en, der ikke videresender det lokale domæne, lader navnet være ubesvaret. Hvis adressen også fejler, er det stien, der er problemet: en standardrute gennem tunnelen, en blokering af lokal trafik på klientsiden eller en firewallregel, der kun tillader den fysiske grænseflade.

Hvis begge virker, men automatisk opdagelse ikke gør, annoncerer enheden simpelthen ikke gennem tunnelen. Det er forventet adfærd for multicastbaseret opdagelse, ikke en konfigurationsfejl. At tilføje enheden via adresse er normalt den ærlige løsning.

Hvad kontakten til lokal adgang egentlig ændrer

En indstilling for adgang til lokalnetværket tillader typisk trafik til det direkte tilsluttede subnet at omgå tunnelen, og den gør forskellige ting i forskellige klienter. Den konfigurerer ikke videresendelse til et fjernkontor og ændrer ikke værtens firewall eller applikationens egne tilladelser. Den gør heller ikke et overlappende subnet entydigt. Læs klientens dokumentation for, hvad indstillingen dækker, før du aktiverer den bredt.

En snæver undtagelse for én betroet enhed slår en generel tilladelse, især på et gæstenetværk, hvor blokeringen kan være bevidst. En privat adresse er ikke en identitetskontrol, så valget afhænger af det netværk, du er på.

Når netværkene overlapper

Hvis hjemmenetværket og fjernnetværket bruger samme område, bliver routing tvetydig, og hverken en kontakt til lokal adgang eller en undtagelse løser det. To tjenester på samme adresse kan ikke begge nås, og hvilken der vinder, afhænger af routespecificitet og rækkefølge, ikke af hensigt. Løsningen er adresseplanlægning, ikke en klientindstilling. Kontroller områderne, før du bruger en aften på printeren.

For en enhed bag fjern-gatewayen ejer operatøren videresendelse, værtspolitik og returruten. En lokal afkrydsningsboks i klienten kan ikke levere nogen af dem, og at bede om det er mere produktivt end at eksperimentere med kontakter.

Noter, hvilket lag der fejlede, og hvad du ændrede. Den næste enhed vil fejle et af de samme tre steder.