Windows VPN-gateway: tre uppgifter, tre ägare

Tre funktioner slås ihop varje gång någon säger VPN-server: att avsluta den krypterade tunneln, flytta paket mellan nätverk och eventuellt skriva om adresser. På Windows bor de i olika delar av stacken, även när en enda maskin utför alla tre. Var och en har sina egna indata och sitt eget felläge, och var och en kan lämnas till en annan produkt. Att skilja dem åt på papperet är det billigaste sättet att hålla en liten driftsättning begriplig.

En läsbar design namnger ägaren till varje flöde i stället för att beskriva maskinen som en roll.

Avsluta, vidarebefordra, översätt

RRAS hanterar tunneln i det Windows-inhemska fallet: det autentiserar användaren, tilldelar en adress från en pool och avgör vilka destinationer som är tillåtna. En annan VPN-produkt kan i stället äga lyssnaren och den virtuella adaptern och låta Windows vidarebefordra de dekrypterade paketen. Microsofts Remote Access-dokumentation skiljer på VPN-, site-till-site- och routingroller, och installation av routingrollen skapar ingen andra VPN-identitet. Att lägga till ännu ett VPN-program ger inte heller dess adapter till alla befintliga gatewayfunktioner.

Översättning är den tredje och mest valfria uppgiften. Den kommer efter vidarebefordran och ändrar den källadress som fjärrnätverket ser. Om du behöver den beror på vad destinationsnätverket accepterar som källa, inte på att maskinen kallas VPN-gateway.

Vem äger adaptern och poolen

När flera produkter delar värden behöver fyra saker var sin enda ägare: lyssnarportar, adapterns livstid, klientadresspoolen och rutterna. Adaptern är den besvärliga, eftersom en VPN-tjänst kan skapa den dynamiskt och förstöra den vid frånkoppling. Att behandla det gränssnittet som ett permanent namngivet nätverkskort och skriva regler mot dess namn fungerar till nästa återanslutning. Använd produktens stödda integrationspunkt i stället för att hårdkoda ett gränssnittsnamn.

Adresspoolen är den andra kollisionen. Två produkter som delar ut överlappande intervall ger routing som ser korrekt ut och levererar ingenting. Håll poolerna i samma dokument som rutterna, så att en ändring i den ena syns mot den andra.

Bevara källan eller skriv om den

Att bevara klientens källadress håller synligheten per användare: loggar, kvoter och brandväggsregler kan skilja en användare från en annan. Priset är att destinations-LANet behöver en returrutt tillbaka mot gatewayen, och någon måste underhålla den. Att skriva om källan med NAT tar bort det kravet och tar bort synligheten med det. Välj medvetet och skriv ned vilken information omskrivningen döljer.

Åtkomst till privata nätverk, internetutgång och anslutningar som avslutas på själva gatewayen är tre olika vägar. De behöver inte alla samma behandling.

Beskriv flödet i en mening

En mening bör beskriva designen: vilka klienter den här tjänsten släpper in, vilka resurser den vidarebefordringspolicyn ger och hur returvägen fullbordar flödet. Om meningen behöver ett andra NAT-lager för att vara sann är det oftast ett tecken på att de tidigare delarna inte var avgjorda. Värden är också en delad fel- och tillitsgräns, så en routingändring kan påverka både användaråtkomst och administration. Behåll en oberoende återställningsväg för det senare.

Håll en rollförteckning bredvid konfigurationen: vilken produkt avslutar, vilken vidarebefordrar, vilken översätter och vem som kan ändra varje. Den listan är det som gör nästa ändring granskningsbar.

När meningen blir otydlig gör ännu ett översättningslager den sällan tydligare. Att ta bort ett gör det vanligtvis.