Lokala enheter försvinner på VPN: tre separata fel
Enheten kan fortfarande svara på sin adress efter att den försvunnit från listan. Upptäckt, namnutslagning och nåbarhet misslyckas var för sig, så testa dem en i taget.
En skrivare som försvinner från enhetslistan när VPN:en startar kan fortfarande svara på sin adress. Listan fylls av upptäckt, namnet kan komma från en resolver, och själva tjänsten nås via en socket, och de tre kan misslyckas oberoende av varandra. Att jämföra vad som fungerar på varje lager berättar vilken funktion du ska ändra. Om du först slår på alla undantag för lokal åtkomst tar du bort bevisen.
Det är skillnaden mellan en enhet som saknas och en enhet som bara inte annonseras.
Upptäckt, namn och nåbarhet är tre lager
Upptäcktsprotokoll förlitar sig på multicast eller broadcast, och dessa korsar inte en routad tunnel som standard, vilket är varför en enhet kan försvinna från en lista medan den fortfarande är fullt nåbar. Namnutslagning är ett andra lager: en VPN kan byta resolver, och ett namn som det lokala nätverket tidigare svarade på kan nu besvaras någon annanstans eller inte alls. Nåbarhet är det tredje: en rutt, en brandväggsregel och en lyssnande tjänst. Varje lager kan gå sönder medan de andra två är i ordning.
Testa dem nedifrån och upp. En enda nåbarhetskontroll gör uppdelningen tydlig: nc -vz 192.168.1.20 443 antingen lyckas, vilket betyder att vägen och tjänsten är i ordning och namnet är den misstänkta, eller misslyckas, vilket flyttar frågan till routing och policy. Fråga sedan efter namnet. Det första felet du stöter på är lagret att arbeta med, och lagren ovanför kan inte kompensera för det.
Fråga först efter adressen, sedan efter värdnamnet
Om adressen svarar och namnet inte, är problemet uppslagning och inte routing. En VPN-klient som installerar sin egen resolver kan ändra vilken server som svarar på lokala namn, och en som inte vidarebefordrar den lokala domänen lämnar namnet obesvarat. Om adressen också misslyckas är vägen problemet: en standardrutt genom tunneln, en blockering av lokal trafik på klientsidan eller en brandväggsregel som bara tillåter det fysiska gränssnittet.
Om båda fungerar men automatisk upptäckt inte gör det, annonserar enheten helt enkelt inte sig genom tunneln. Det är förväntat beteende för multicastbaserad upptäckt, inte ett konfigurationsfel. Att lägga till enheten via adress är oftast den ärliga lösningen.
Vad reglaget för lokal åtkomst faktiskt ändrar
En inställning för lokal nätverksåtkomst tillåter vanligtvis att trafik till det direkt anslutna subnätet går runt tunneln, och den gör olika saker i olika klienter. Den konfigurerar inte vidarebefordran till ett fjärrkontor och ändrar inte värdens brandvägg eller programmets egna behörigheter. Den gör inte heller ett överlappande subnät entydigt. Läs klientens dokumentation om vad inställningen omfattar innan du slår på den brett.
Ett smalt undantag för en betrodd enhet är bättre än ett allmänt tillstånd, särskilt på ett gästnätverk där blockeringen kan vara avsiktlig. En privat adress är inte en identitetskontroll, så valet beror på nätverket du är på.
När näten överlappar
Om hemnätverket och fjärrnätverket använder samma intervall blir routingen tvetydig och varken ett reglage för lokal åtkomst eller ett undantag löser det. Två tjänster på samma adress kan inte båda nås, och vilken som vinner beror på ruttspecificitet och ordning, inte på avsikt. Lösningen är adressplanering, inte en klientinställning. Kontrollera intervallen innan du lägger en kväll på skrivaren.
För en enhet bakom fjärrporten äger operatören vidarebefordran, värdpolicy och returrutten. En lokal kryssruta i klienten kan inte leverera någon av dem, och att be om det är mer produktivt än att experimentera med reglage.
Notera vilket lager som misslyckades och vad du ändrade. Nästa enhet kommer att misslyckas på en av samma tre platser.