Hjemmelab og delt tunnel: rut bare det du trenger, ikke alt

Rådet om at en hjemmelab trenger en full tunnel kommer vanligvis fra en veiledning som hadde en, ikke fra et krav. Delt tunnel er ikke kompromissversjonen av en skikkelig VPN; det er versjonen der du kan forklare rutetabellen. En lab med fem tjenester og et administrasjonsgrensesnitt trenger ikke at hver pakke som forlater huset går gjennom en tunnel. Det den trenger, er en oversikt og en rute for hvert element i den oversikten.

Myten: delt tunnel er et kompromiss

Myten lever fordi en full tunnel er lettere å sette opp én gang og vanskeligere å feilsøke senere. Den byttehandelen er rimelig for en bærbar PC på offentlig Wi-Fi og feil for et stativ i kjelleren.

Den skjuler også en andre forutsetning, nemlig at adresseringen til laben ikke har noe til felles med nettet du kobler til fra.

Inventer ressursene før rutene

Skriv ned hvert lab-subnett, tjenesten som bor der, navnet du løser det med, og hvem som har lov til å nå det; notatene om videresending for gatewayen din beskriver returveien du planlegger mot. Legg til containerområdene og LAN-områdene som fjernklienten kanskje allerede bruker, fordi overlapp er feilen denne oversikten hindrer. En rute som dekker hver privat adresse vil før eller siden kollidere med et hjemmenettverk. Oversikten er også testplanen, derfor er det verdt å gjøre den før konfigurasjonen og ikke etter.

Gi hver ressurs en vei: gjennom tunnelen, direkte eller avvist. En ressurs uten tildelt vei er den som senere skaper det forvirrede støttespørsmålet.

Fem rader og en kolonne med beslutninger slår en rutetabell ingen kan lese.

Gatewayen trenger en returvei

Videresending på gatewayen er bare halvparten. Laben trenger en rute tilbake til klientpoolen, eller en støttet oversettelsesordning som gjør returen mulig. Hvis svarene ikke finner klienten, ser tunnelen tilkoblet ut og hver forespørsel går ut på tid; det er et rutingssymptom og ikke en VPN-feil. Sjekk returveien som del av designet, ikke som et feilsøkingstrinn.

En klientpool som overlapper labens egen adressering er den andre halvdelen av dette problemet, og den feiler på nøyaktig samme måte.

Rett opp planen, ikke symptomene, når de to områdene kolliderer.

Administrasjons- og internettrollene er atskilt

Avgjør om bare labtrafikken bruker tunnelen eller om den også blir en internettutgang. Ikke legg til en standardrute bare fordi en veiledning brukte en, fordi den beslutningen endrer hvor hver DNS-spørring og hver oppdateringssjekk går. Behold en utvendig vei til selve VPN-endepunktet, ellers vil tunnelen prøve å bære sin egen ytre tilkobling. Hold administrasjonstilgangen smal og tilgjengelig gjennom en godkjent gjenopprettingsmetode.

Privat DNS kan velges for labnavn uten å anta at hver offentlig spørring trenger samme resolver. Det er en avgjørelse om resolveren, ikke en avgjørelse om ruten.

Å holde dem atskilt er det som gjør feilmodusene skillbare senere.

Test utenfra, ikke fra LAN-et

Bruk en ekstern autorisert tilkobling i stedet for en test fra samme LAN, fordi en test fra samme LAN helt kan skjule en manglende returrute. Bekreft en labadresse, dens private vertsnavn, en tiltenkt direkte destinasjon og den påkrevde feilatferden. Feiltilfellet er like viktig som suksesstilfellet: en ressurs som ikke skal være tilgjengelig, må virkelig være utilgjengelig. Skriv ned alle fire resultatene før du kaller designet ferdig.

Lagre deretter rute- og DNS-konfigurasjonen ved siden av oversikten, med en navngitt eier. Når laben får et subnett til, oppdater begge og test på nytt.

En uforklart rute som overlapper et eksisterende hjemmenettverk er standardresultatet av å hoppe over det trinnet.

Det ferdige designet er lite, dokumentert og kjedelig, og det er nettopp det en lab vil ha av nettverket sitt. Den interessante versjonen er den som brekker mens du er borte hjemmefra.