Heimelab og delt tunnel: rutt berre det du treng, ikkje alt

Rådet om at eit heimelab treng ein full tunnel kjem oftast frå ein rettleiing som hadde ein, ikkje frå eit krav. Delt tunnel er ikkje ein kompromissversjon av ein skikkeleg VPN; det er versjonen der du kan forklare rutetabellen. Eit lab med fem tenester og eit styringsgrensesnitt treng ikkje at kvar pakke som forlèt huset går gjennom ein tunnel. Det han treng, er ein inventar og ei rute for kvar gjenstand på den inventaren.

Myten: delt tunnel er eit kompromiss

Myten lever fordi ein full tunnel er lettare å setje opp éin gong og vanskelegare å feilsøkje seinare. Den byttehandelen er rimeleg for ein berbar PC på offentleg Wi-Fi og galen for eit stativ i kjellaren.

Han skjuler òg ei andre føresetnad, nemleg at adresseringa til laben ikkje har noko til felles med nettet du koplar til frå.

Inventer ressursane før rutene

Skriv ned kvart lab-subnett, tenesta som bur der, namnet du løyser det med, og kven som har løyve til å nå det; notatane om videresending for gatewayen din skildrar returvegen du planlegg mot. Legg til containerområda og LAN-områda som fjernklienten kanskje alt brukar, fordi overlapp er feilen denne inventaren hindrar. Ei rute som dekkjer kvar privat adresse vil før eller sidan kollidere med eit heimenett. Inventaren er òg testplanen, difor er det verdt å gjere han før konfigurasjonen og ikkje etter.

Gi kvar ressurs ein veg: gjennom tunnelen, direkte eller avvist. Ein ressurs utan tildelt veg er den som seinare skaper det forvirra støttespørsmålet.

Fem rader og ein kolonne med avgjerder slår ein rutetabell ingen kan lese.

Gatewayen treng ein returveg

Videresending på gatewayen er berre halvparten. Laben treng ei rute tilbake til klientpoolen, eller ei støtta omsetjingsordning som gjer returen mogleg. Viss svara ikkje finn klienten, ser tunnelen tilkopla ut og kvar førespurnad går ut på tid; det er eit rutingssymptom og ikkje ein VPN-feil. Sjekk returvegen som del av designet, ikkje som eit feilsøkingssteg.

Ein klientpool som overlappar labens eiga adressering er den andre halvdelen av dette problemet, og han feilar på nøyaktig same måte.

Rett opp planen, ikkje symptoma, når dei to områda kolliderer.

Styrings- og internettrollene er åtskilde

Avgjer om berre labtrafikken brukar tunnelen eller om han òg blir ein internettutgang. Ikkje legg til ei standardrute berre fordi ei rettleiing brukte ei, fordi den avgjerda endrar kvar kvar DNS-førespurnad og kvar oppdateringssjekk går. Ta vare på ein utanveg til sjølve VPN-endepunktet, elles vil tunnelen prøve å bere si eiga ytre tilkopling. Hald styringstilgangen smal og tilgjengeleg gjennom ein godkjend gjenopprettingsmetode.

Privat DNS kan veljast for labnamn utan å gå ut frå at kvar offentleg førespurnad treng same løysar. Det er ei avgjerd om løysaren, ikkje ei avgjerd om ruta.

Å halde dei åtskilde er det som gjer feilmodusane skiljande seinare.

Test utanfrå, ikkje frå LAN-et

Bruk ei ekstern godkjend tilkopling i staden for ein test frå same LAN, fordi ein test frå same LAN heilt kan skjule ein manglande returveg. Stadfest ei labadresse, det private vertsnamnet hennar, ein tilsikta direkte destinasjon og den kravde feilåtferda. Feiltilfellet er like viktig som suksesstilfellet: ein ressurs som ikkje skal vere tilgjengeleg, må verkeleg vere utilgjengeleg. Skriv ned alle fire resultata før du kallar designet ferdig.

Lagre så rute- og DNS-konfigurasjonen ved sida av inventaren, med ein namngjeven eigar. Når laben får eit subnett til, oppdater begge og test på nytt.

Ei uforklart rute som overlappar eit eksisterande heimenett er standardresultatet av å hoppe over det steget.

Det ferdige designet er lite, dokumentert og keisamt, og det er nettopp det eit lab vil ha av nettet sitt. Den interessante versjonen er den som bryt medan du er borte heimanfrå.