Windows VPN-gateway: drie taken, drie eigenaren

Drie functies worden samengevoegd zodra iemand VPN-server zegt: de versleutelde tunnel beëindigen, pakketten tussen netwerken verplaatsen en optioneel adressen herschrijven. Op Windows leven ze in verschillende delen van de stack, zelfs wanneer één machine ze alle drie uitvoert. Elk heeft zijn eigen invoer en zijn eigen faalwijze, en elk kan aan een ander product worden overgedragen. Ze op papier scheiden is de goedkoopste manier om een kleine uitrol begrijpelijk te houden.

Een leesbaar ontwerp noemt de eigenaar van elke stroom in plaats van de machine als een rol te beschrijven.

Beëindigen, doorsturen, vertalen

RRAS verzorgt de tunnel voor het Windows-eigen geval: het authenticeert de gebruiker, wijst een adres uit een pool toe en bepaalt welke bestemmingen zijn toegestaan. Een ander VPN-product kan in plaats daarvan de listener en de virtuele adapter bezitten en Windows de ontsleutelde pakketten laten doorsturen. De Remote Access-documentatie van Microsoft scheidt VPN-, site-to-site- en routeringsrollen, en het installeren van de routeringsrol maakt geen tweede VPN-identiteit aan. Een andere VPN-toepassing toevoegen geeft de adapter ervan ook niet aan elke bestaande gatewayfunctie.

Vertaling is de derde en meest optionele taak. Ze komt na het doorsturen en verandert het bronadres dat het verre netwerk ziet. Of u haar nodig hebt, hangt af van wat het bestemmingsnetwerk als bron accepteert, niet van het feit dat de machine een VPN-gateway heet.

Wie bezit de adapter en de pool

Wanneer meerdere producten de host delen, hebben vier dingen elk één eigenaar nodig: luisterpoorten, de levensduur van de adapter, de clientadrespool en de routes. De adapter is de lastige, omdat een VPN-dienst hem dynamisch kan aanmaken en bij verbreken kan vernietigen. Die interface als een permanent benoemde netwerkkaart behandelen en regels tegen de naam schrijven werkt tot de volgende herverbinding. Gebruik het ondersteunde integratiepunt van het product in plaats van een interfacenaam hard te coderen.

De adrespool is de tweede botsing. Twee producten die overlappende bereiken uitdelen, produceren routering die er correct uitziet en niets aflevert. Houd de pools in hetzelfde document als de routes, zodat een wijziging in de ene zichtbaar is tegen de andere.

De bron behouden of herschrijven

Het bronadres van de client behouden houdt zichtbaarheid per gebruiker: logboeken, quota en firewallregels kunnen de ene gebruiker van de andere onderscheiden. De prijs is dat het bestemmings-LAN een retourroute naar de gateway nodig heeft, en iemand moet die onderhouden. De bron met NAT herschrijven verwijdert die eis en verwijdert de zichtbaarheid ermee. Kies bewust en schrijf op welke informatie het herschrijven verbergt.

Toegang tot een particulier netwerk, internetuitgang en verbindingen die op de gateway zelf eindigen, zijn drie verschillende paden. Ze hebben niet allemaal dezelfde behandeling nodig.

Beschrijf de stroom in één zin

Eén zin zou het ontwerp moeten beschrijven: welke clients deze dienst toelaat, welke resources dat doorstuurbeleid verleent en hoe het retourpad de stroom voltooit. Als de zin een tweede NAT-laag nodig heeft om waar te zijn, is dat meestal een teken dat de eerdere onderdelen niet waren afgerond. De host is ook een gedeelde faal- en vertrouwensgrens, dus een routeringswijziging kan zowel gebruikerstoegang als beheer raken. Houd een onafhankelijk herstelpad voor het laatste.

Houd een rolleninventaris naast de configuratie: welk product beëindigt, welke doorstuurt, welke vertaalt en wie elk kan wijzigen. Die lijst is wat de volgende wijziging controleerbaar maakt.

Wanneer de zin onduidelijk wordt, maakt nog een vertaallaag hem zelden duidelijker. Er één verwijderen meestal wel.