Hjemmelab og delt tunnel: rut kun det, du har brug for, ikke alt

Rådet om, at et hjemmelab har brug for en fuld tunnel, kommer normalt fra en vejledning, der havde en, ikke fra et krav. Delt tunnel er ikke den kompromitterede udgave af en ordentlig VPN; det er den udgave, hvis routingtabel du kan forklare. Et lab med fem tjenester og en administrationsflade har ikke brug for, at hver pakke, der forlader huset, går gennem en tunnel. Det, den har brug for, er en oversigt og en rute for hvert punkt på den oversigt.

Myten: delt tunnel er et kompromis

Myten overlever, fordi en fuld tunnel er lettere at konfigurere én gang og sværere at fejlfinde senere. Den byttehandel er rimelig for en bærbar på offentligt Wi-Fi og forkert for et rack i kælderen.

Den skjuler også en anden antagelse, nemlig at labbets adressering intet har til fælles med det netværk, du forbinder fra.

Lav en oversigt over ressourcerne før ruterne

Skriv hvert lab-subnet ned, den tjeneste, der bor der, det navn, du slår den op med, og hvem der har tilladelse til at nå den; noterne om videresendelse for din gateway beskriver den returvej, du planlægger efter. Tilføj containerområderne og de LAN-områder, som fjernklienten muligvis allerede bruger, fordi overlapning er den fejl, denne oversigt forebygger. En rute, der dækker hver privat adresse, vil før eller siden støde sammen med et hjemmenetværk. Oversigten er også testplanen, og derfor er det værd at gøre det før konfigurationen og ikke efter.

Tildel hver ressource en vej: gennem tunnelen, direkte eller afvist. En ressource uden tildelt vej er den, der senere skaber det forvirrede supportspørgsmål.

Fem rækker og en kolonne med beslutninger slår en routingtabel, som ingen kan læse.

Gatewayen har brug for en returvej

Videresendelse på gatewayen er kun halvdelen. Labbet har brug for en rute tilbage til klientpuljen, eller en understøttet oversættelsesordning, der gør returen mulig. Hvis svar ikke kan finde klienten, ser tunnelen forbundet ud, og hver anmodning løber ud i tid; det er et routing-symptom og ikke en VPN-fejl. Kontroller returvejen som en del af designet, ikke som et fejlfindingsskridt.

En klientpulje, der overlapper labbets egen adressering, er den anden halvdel af dette problem, og den fejler på præcis samme måde.

Ret planen og ikke symptomerne, når de to områder støder sammen.

Administrations- og internetroller er adskilte

Beslut, om kun labtrafik bruger tunnelen, eller om den også bliver en internetudgang. Tilføj ikke en standardrute, blot fordi en vejledning brugte en, fordi den beslutning ændrer, hvor hver DNS-forespørgsel og hver opdateringskontrol går hen. Bevar en udvendig vej til selve VPN-endepunktet, ellers vil tunnelen forsøge at bære sin egen ydre forbindelse. Hold administrationsadgang smal og tilgængelig via en godkendt gendannelsesmetode.

Privat DNS kan vælges til labnavne uden at antage, at hver offentlig forespørgsel har brug for samme resolver. Det er en resolverbeslutning, ikke en rutebeslutning.

Det at holde dem adskilt er det, der gør fejlmønstrene skelnelige senere.

Test udefra, ikke fra LAN'et

Brug en ekstern autoriseret forbindelse i stedet for en test fra det samme LAN, fordi en test fra det samme LAN fuldstændigt kan skjule en manglende returrute. Bekræft en labadresse, dens private værtsnavn, en tilsigtet direkte destination og den krævede fejladfærd. Fejltilfældet er lige så vigtigt som succestilfældet: en ressource, der ikke bør kunne nås, skal virkelig ikke kunne nås. Noter alle fire resultater, før du kalder designet færdigt.

Gem derefter rute- og DNS-konfigurationen ved siden af oversigten med en navngivet ejer. Når labbet får endnu et subnet, skal du opdatere begge og teste igen.

En uforklaret rute, der overlapper et eksisterende hjemmenetværk, er standardresultatet af at springe det trin over.

Det færdige design er lille, dokumenteret og kedeligt, hvilket er præcis, hvad et lab ønsker af sit netværk. Den interessante version er den, der går i stykker, mens du er væk hjemmefra.