Windows VPN-gateway: tre opgaver, tre ejere

Tre funktioner bliver slået sammen, hver gang nogen siger VPN-server: at afslutte den krypterede tunnel, at flytte pakker mellem netværk og eventuelt at omskrive adresser. På Windows bor de i forskellige dele af stakken, selv når én maskine udfører dem alle. Hver har sine egne input og sin egen fejltilstand, og hver kan overlades til et forskelligt produkt. At adskille dem på papiret er den billigste måde at holde en lille udrulning forståelig på.

Et læsbart design navngiver ejeren af hver strøm i stedet for at beskrive maskinen som en rolle.

Afslut, videresend, oversæt

RRAS håndterer tunnelen i det Windows-native tilfælde: den godkender brugeren, tildeler en adresse fra en pulje og afgør, hvilke destinationer der er tilladt. Et andet VPN-produkt kan i stedet eje lytteren og den virtuelle adapter og lade Windows videresende de dekrypterede pakker. Microsofts Remote Access-dokumentation adskiller VPN-, site-to-site- og routingroller, og installation af routingrollen skaber ikke en anden VPN-identitet. At tilføje endnu et VPN-program giver heller ikke dets adapter til alle eksisterende gatewayfunktioner.

Oversættelse er den tredje og mest valgfrie opgave. Den ligger efter videresendelsen og ændrer den kildeadresse, som det fjerne netværk ser. Om du har brug for den, afhænger af, hvad destinationsnetværket accepterer som kilde, ikke af at maskinen kaldes en VPN-gateway.

Hvem ejer adapteren og puljen

Når flere produkter deler værten, skal fire ting hver have én ejer: lytteporte, adapterens levetid, klientadressepuljen og ruterne. Adapteren er den besværlige, fordi en VPN-tjeneste kan oprette den dynamisk og ødelægge den ved afbrydelse. At behandle det interface som et permanent navngivet netværkskort og skrive regler mod dets navn virker indtil næste genopkobling. Brug produktets understøttede integrationspunkt i stedet for at hardkode et interfacenavn.

Adressepuljen er den anden kollision. To produkter, der udleverer overlappende områder, giver routing, der ser korrekt ud og leverer intet. Hold puljerne i samme dokument som ruterne, så en ændring i den ene er synlig mod den anden.

Bevar kilden eller omskriv den

At bevare klientens kildeadresse holder synlighed pr. bruger: logfiler, kvoter og firewallregler kan skelne én bruger fra en anden. Prisen er, at destinations-LAN’et har brug for en returrute tilbage mod gatewayen, og nogen skal vedligeholde den. At omskrive kilden med NAT fjerner det krav og fjerner synligheden med det. Vælg bevidst, og skriv ned, hvilke oplysninger omskrivningen skjuler.

Adgang til private netværk, internetudgang og forbindelser, der afsluttes på selve gatewayen, er tre forskellige veje. De har ikke alle brug for samme behandling.

Beskriv strømmen i én sætning

Én sætning skal beskrive designet: hvilke klienter denne tjeneste optager, hvilke ressourcer den videresendelsespolitik giver, og hvordan returvejen fuldfører strømmen. Hvis sætningen har brug for endnu et NAT-lag for at være sand, er det normalt et tegn på, at de tidligere dele ikke var afklaret. Værten er også en fælles fejl- og tillidsgrænse, så en ændring af routing kan påvirke både brugeradgang og administration. Behold en uafhængig gendannelsesvej til sidstnævnte.

Hold en rolleoversigt ved siden af konfigurationen: hvilket produkt afslutter, hvilket videresender, hvilket oversætter, og hvem der kan ændre hver. Den liste er det, der gør den næste ændring reviderbar.

Når sætningen bliver uklar, gør endnu et oversættelseslag den sjældent klarere. At fjerne et gør det normalt.