Hemmalabb och delad tunnel: routa det du behöver, inte allt

Rådet att ett hemmalabb behöver en full tunnel kommer oftast från en guide som hade en, inte från ett krav. Delad tunnel är inte den kompromissade versionen av en korrekt VPN; det är versionen vars routingtabell du kan förklara. Ett labb med fem tjänster och ett administrationsgränssnitt behöver inte att varje paket som lämnar huset går genom en tunnel. Det den behöver är en inventering och en rutt för varje post i den inventeringen.

Myten: delad tunnel är en kompromiss

Myten lever eftersom en full tunnel är lättare att konfigurera en gång och svårare att felsöka senare. Den byteshandeln är rimlig för en laptop på öppet Wi-Fi och fel för ett rack i källaren.

Den döljer också ett andra antagande, nämligen att labbets adressering inte har något gemensamt med nätverket du ansluter från.

Inventera resurserna före rutterna

Skriv ner varje labbsubnät, tjänsten som bor där, namnet du löser det med och vem som får nå det; anteckningarna om vidarebefordran för din gateway beskriver returvägen du planerar mot. Lägg till containerintervallen och LAN-intervallen som fjärrklienten kanske redan använder, eftersom överlappning är det fel som den här inventeringen förhindrar. En rutt som täcker varje privat adress kolliderar förr eller senare med ett hemnätverk. Inventeringen är också testplanen, därför är det värt att göra den före konfigurationen och inte efter.

Ge varje resurs en väg: genom tunneln, direkt eller nekad. En resurs utan tilldelad väg är den som senare skapar den förvirrade supportfrågan.

Fem rader och en kolumn med beslut slår en routingtabell som ingen kan läsa.

Gatewayen behöver en returväg

Vidarebefordran på gatewayen är bara halva. Labbet behöver en rutt tillbaka till klientpoolen, eller en stödd översättningslösning som gör returen möjlig. Om svaren inte hittar klienten ser tunneln ansluten ut och varje begäran tar timeout; det är ett routingsymptom och inte ett VPN-fel. Kontrollera returvägen som en del av designen, inte som ett felsökningssteg.

En klientpool som överlappar labbets egen adressering är den andra halvan av problemet, och den misslyckas på exakt samma sätt.

Rätta planen, inte symptomen, när de två intervallen kolliderar.

Administrations- och internetrollerna är åtskilda

Bestäm om bara labbets trafik använder tunneln eller om den också blir en internetutgång. Lägg inte till en standardrutt bara för att en guide använde en, eftersom det beslutet ändrar vart varje DNS-fråga och varje uppdateringskontroll tar vägen. Behåll en yttre väg till själva VPN-slutpunkten, annars försöker tunneln bära sin egen yttre anslutning. Håll administrationsåtkomsten smal och nåbar via en godkänd återställningsmetod.

Privat DNS kan väljas för labbnamn utan att anta att varje offentlig fråga behöver samma resolver. Det är ett resolverbeslut, inte ett ruttbeslut.

Att hålla dem åtskilda är det som gör fellägena urskiljbara senare.

Testa utifrån, inte från LAN

Använd en extern auktoriserad anslutning i stället för ett test från samma LAN, eftersom ett test från samma LAN helt kan dölja en saknad returrutt. Verifiera en labbadress, dess privata värdnamn, en avsedd direkt destination och det krävda felbeteendet. Felfallet är lika viktigt som framgångsfallet: en resurs som inte ska vara nåbar måste verkligen vara onåbar. Skriv ner alla fyra resultaten innan du kallar designen klar.

Spara sedan rutt- och DNS-konfigurationen bredvid inventeringen, med en namngiven ägare. När labbet får ytterligare ett subnät uppdaterar du båda och testar igen.

En oförklarad rutt som överlappar ett befintligt hemnätverk är standardresultatet av att hoppa över det steget.

Den färdiga designen är liten, dokumenterad och tråkig, och det är precis vad ett labb vill ha av sitt nätverk. Den intressanta versionen är den som går sönder medan du är bortrest.