Lokale einingar forsvinn på VPN: tre separate feil

Ein skrivar som forsvinn frå eininglista når VPN-en kjem opp, kan framleis svare på adressa si. Lista blir fylt av oppdaging, namnet kan kome frå ein resolver, og sjølve tenesta blir nådd over ein socket, og dei tre kan svikte uavhengig av kvarandre. Å samanlikne kva som verkar på kvart lag fortel deg kva funksjon du skal endre. Slår du først på alle unntak for lokal tilgang, fjernar du prova.

Det er skilnaden på ei eining som manglar og ei eining som berre ikkje blir annonsert.

Oppdaging, namn og tilgjenge er tre lag

Oppdagingsprotokollar er avhengige av multicast eller broadcast, og desse kryssar ikkje ein ruta tunnel som standard, og difor kan ei eining forsvinne frå ei liste medan ho framleis er fullt tilgjengeleg. Namneoppslag er eit andre lag: ein VPN kan byte resolver, og eit namn som det lokale nettet tidlegare svara på, kan no bli svara andre stader eller ikkje i det heile. Tilgjenge er det tredje: ei rute, ein brannmurregel og ei lyttande teneste. Kvart lag kan bryte saman medan dei to andre er i orden.

Test dei nedanfrå og opp. Ein einaste tilgjengeprøve gjer oppdelinga tydeleg: nc -vz 192.168.1.20 443 anten lukkast, som tyder at vegen og tenesta er i orden og namnet er den mistenkte, eller mislukkast, som flyttar spørsmålet til ruting og policy. Spør så etter namnet. Den første feilen du treff, er laget du skal jobbe med, og laga over kan ikkje kompensere for han.

Spør først etter adressa, deretter etter vertsnamnet

Viss adressa svarar og namnet ikkje, er problemet oppslag og ikkje ruting. Ein VPN-klient som installer sin eigen resolver, kan endre kva tenar som svarar på lokale namn, og ein som ikkje videresendar det lokale domenet, lèt namnet stå ubesvara. Viss adressa også sviktar, er det vegen som er problemet: ei standardrute gjennom tunnelen, ei blokkering av lokal trafikk på klientsida eller ein brannmurregel som berre tillèt det fysiske grensesnittet.

Viss begge verkar, men automatisk oppdaging ikkje gjer det, annonserer eininga seg rett og slett ikkje gjennom tunnelen. Det er forventa åtferd for multicast-basert oppdaging, ikkje ein konfigurasjonsfeil. Å leggje til eininga via adresse er vanlegvis den ærlege løysinga.

Kva brytaren for lokal tilgang eigentleg endrar

Ei innstilling for lokaltilgang tillèt vanlegvis at trafikk til det direkte tilkopla subnettet går utanom tunnelen, og ho gjer ulike ting i ulike klientar. Ho konfigurerer ikkje videresending til eit fjernkontor og endrar ikkje brannmuren til verten eller dei eigne løyva til programmet. Ho gjer heller ikkje eit overlappande subnett eintydig. Les dokumentasjonen til klienten for kva innstillinga dekkjer, før du slår ho på breitt.

Eit smalt unntak for éi klårert eining er betre enn ei generell løyve, særleg på eit gjestenett der blokkeringa kan vere medviten. Ei privat adresse er ikkje ein identitetskontroll, så valet avheng av nettet du er på.

Når netta overlappar

Viss heimenettet og fjernnettet brukar same område, blir rutinga tveydig, og verken ein brytar for lokal tilgang eller eit unntak løyser det. To tenester på same adresse kan ikkje begge nåast, og kva som vinn avheng av rutespesifisitet og rekkjefølgje, ikkje av hensikt. Løysinga er adresseplanlegging, ikkje ei klientinnstilling. Kontroller områda før du brukar ein kveld på skrivaren.

For ei eining bak fjernporten eig operatøren videresending, vertspolicy og returruta. Ein lokal avkryssingsboks i klienten kan ikkje levere nokon av dei, og å be om det er meir produktivt enn å eksperimentere med brytarar.

Noter kva lag som feila og kva du endra. Den neste eininga vil feile på ein av dei same tre stadene.