Windows VPN-gateway: tre oppgaver, tre eiere

Tre funksjoner slås sammen hver gang noen sier VPN-server: å avslutte den krypterte tunnelen, flytte pakker mellom nettverk og eventuelt skrive om adresser. På Windows bor de i forskjellige deler av stakken, selv når én maskin utfører alle tre. Hver har sine egne innganger og sin egen feilmodus, og hver kan overlates til et annet produkt. Å skille dem på papiret er den billigste måten å holde en liten utrulling forståelig på.

Et lesbart design navngir eieren av hver strøm i stedet for å beskrive maskinen som en rolle.

Avslutt, videresend, oversett

RRAS håndterer tunnelen for det Windows-opprinnelige tilfellet: det autentiserer brukeren, tildeler en adresse fra en pool og avgjør hvilke destinasjoner som er tillatt. Et annet VPN-produkt kan i stedet eie lytteren og den virtuelle adapteren, og la Windows videresende de dekrypterte pakkene. Microsofts Remote Access-dokumentasjon skiller VPN-, site-til-site- og rutingroller, og installasjon av rutingrollen oppretter ikke en andre VPN-identitet. Å legge til enda et VPN-program gir heller ikke adapteren til alle eksisterende gatewayfunksjoner.

Oversettelse er den tredje og mest valgfrie oppgaven. Den kommer etter videresendingen og endrer kildeadressen som det fjerne nettverket ser. Om du trenger den, avhenger av hva destinasjonsnettverket godtar som kilde, ikke av at maskinen kalles en VPN-gateway.

Hvem eier adapteren og poolen

Når flere produkter deler verten, trenger fire ting hver sin eneste eier: lytteporter, adapterens levetid, klientadressepoolen og rutene. Adapteren er den vanskelige, fordi en VPN-tjeneste kan opprette den dynamisk og ødelegge den ved frakobling. Å behandle det grensesnittet som et permanent navngitt nettverkskort og skrive regler mot navnet virker til neste gjenoppkobling. Bruk produktets støttede integrasjonspunkt i stedet for å hardkode et grensesnittnavn.

Adressepoolen er den andre kollisjonen. To produkter som deler ut overlappende områder, gir ruting som ser riktig ut og leverer ingenting. Hold poolene i samme dokument som rutene, slik at en endring i den ene er synlig mot den andre.

Bevar kilden eller skriv den om

Å bevare klientens kildeadresse holder synligheten per bruker: logger, kvoter og brannmurregler kan skille én bruker fra en annen. Prisen er at destinasjons-LAN-et trenger en returrute tilbake mot gatewayen, og noen må vedlikeholde den. Å skrive om kilden med NAT fjerner det kravet og fjerner synligheten med det. Velg bevisst, og skriv ned hvilken informasjon omskrivingen skjuler.

Tilgang til privat nettverk, internett-utgang og tilkoblinger som avsluttes på selve gatewayen, er tre forskjellige veier. De trenger ikke alle samme behandling.

Beskriv strømmen i én setning

Én setning skal beskrive designet: hvilke klienter denne tjenesten slipper inn, hvilke ressurser den videresendingspolicyen gir, og hvordan returveien fullfører strømmen. Hvis setningen trenger enda et NAT-lag for å være sann, er det vanligvis et tegn på at de tidligere delene ikke var avklart. Verten er også en delt feil- og tillitsgrense, så en rutingendring kan påvirke både brukertilgang og administrasjon. Behold en uavhengig gjenopprettingsvei for sistnevnte.

Hold en rolleoversikt ved siden av konfigurasjonen: hvilket produkt avslutter, hvilket videresender, hvilket oversetter, og hvem som kan endre hver. Den listen er det som gjør den neste endringen reviderbar.

Når setningen blir uklar, gjør enda et oversettelseslag den sjelden klarere. Å fjerne ett gjør det vanligvis.