Het advies dat een thuislab een volledige tunnel nodig heeft, komt meestal uit een tutorial die er een had, niet uit een vereiste. Gesplitste tunneling is niet de compromisversie van een goede VPN; het is de versie waarvan je de routetabel kunt uitleggen. Een lab met vijf diensten en een beheerinterface heeft niet nodig dat elk pakket dat het huis verlaat door een tunnel gaat. Wat het nodig heeft, is een inventaris en een route voor elk item op die inventaris.

De mythe: gesplitste tunneling is een compromis

De mythe houdt stand omdat een volledige tunnel eenmalig makkelijker te configureren en later lastiger te debuggen is. Die ruil is redelijk voor een laptop op openbare Wi-Fi en verkeerd voor een rack in de kelder.

Hij verbergt ook een tweede aanname, namelijk dat de adressering van het lab niets gemeen heeft met het netwerk waar je vandaan verbindt.

Inventariseer de middelen vóór de routes

Schrijf elk lab-subnet op, de dienst die daar woont, de naam waarmee je het oplost en wie er toegang toe mag krijgen; de notities over doorsturen voor je gateway beschrijven het terugpad waartegen je plant. Voeg de containerreeksen en de LAN-reeksen toe die de externe client misschien al gebruikt, want overlap is de fout die deze inventaris voorkomt. Een route die elk privéadres dekt, botst vroeg of laat met een thuisnetwerk. De inventaris is ook het testplan, daarom loont het om hem vóór de configuratie te maken en niet erna.

Wijs elke resource een pad toe: door de tunnel, direct of geweigerd. Een resource zonder toegewezen pad is degene die later de verwarde supportvraag oplevert.

Vijf rijen en een kolom met beslissingen verslaan een routetabel die niemand kan lezen.

De gateway heeft een terugpad nodig

Doorsturen op de gateway is maar de helft. Het lab heeft een route terug naar de clientpool nodig, of een ondersteunde vertaalregeling die de terugkeer mogelijk maakt. Als antwoorden de client niet vinden, lijkt de tunnel verbonden en loopt elk verzoek vast; dat is een routingsymptoom en geen VPN-storing. Controleer het terugpad als onderdeel van het ontwerp, niet als stap voor probleemoplossing.

Een clientpool die de eigen adressering van het lab overlapt, is de andere helft van dit probleem, en hij faalt op precies dezelfde manier.

Repareer het plan, niet de symptomen, wanneer de twee reeksen botsen.

Beheer- en internetrollen zijn gescheiden

Bepaal of alleen labverkeer de tunnel gebruikt of dat hij ook een internetuitgang wordt. Voeg geen standaardroute toe alleen omdat een tutorial er een gebruikte, want die beslissing verandert waar elke DNS-query en elke updatecontrole heen gaat. Behoud een buitenpad naar het VPN-eindpunt zelf, anders probeert de tunnel zijn eigen buitenste verbinding te dragen. Houd beheerstoegang smal en bereikbaar via een goedgekeurde herstelmethode.

Privé-DNS kan voor labnamen worden gekozen zonder aan te nemen dat elke publieke query dezelfde resolver nodig heeft. Dat is een beslissing van de resolver, geen routingsbeslissing.

Ze gescheiden houden is wat de faalmodi later onderscheidbaar maakt.

Test van buiten, niet vanaf de LAN

Gebruik een externe geautoriseerde verbinding in plaats van een test vanaf dezelfde LAN, want een test vanaf dezelfde LAN kan een ontbrekende terugroute volledig verbergen. Controleer een labadres, de privéhostnaam, een bedoelde directe bestemming en het vereiste faalgedrag. Het faalgeval is net zo belangrijk als het succesgeval: een resource die niet bereikbaar hoort te zijn, moet echt onbereikbaar zijn. Leg alle vier resultaten vast voordat je het ontwerp voltooid noemt.

Sla daarna de route- en DNS-configuratie naast de inventaris op, met een benoemde eigenaar. Als het lab er een subnet bij krijgt, werk beide bij en test opnieuw.

Een onverklaarde route die een bestaand thuisnetwerk overlapt, is het standaardresultaat van het overslaan van die stap.

Het voltooide ontwerp is klein, gedocumenteerd en saai, en dat is precies wat een lab van zijn netwerk wil. De interessante versie is degene die breekt terwijl je niet thuis bent.

Gerelateerde artikelen