Windows VPN-gateway: tre oppgåver, tre eigarar

Tre funksjonar blir slått saman kvar gong nokon seier VPN-tenar: å avslutte den krypterte tunnelen, flytte pakkar mellom nettverk og eventuelt skrive om adresser. På Windows bur dei i ulike delar av stakken, sjølv når éin maskin gjer alle tre. Kvar har sine eigne inngangar og sin eigen feilmodus, og kvar kan overlatast til eit anna produkt. Å skilje dei på papiret er den billegaste måten å halde ein liten utrulling forståeleg på.

Eit lesbart design namngir eigaren av kvar straum i staden for å skildre maskina som ei rolle.

Avslutt, videresend, omset

RRAS handterer tunnelen for det Windows-opphavlege tilfellet: det autentiserer brukaren, tildeler ei adresse frå ein pool og avgjer kva destinasjonar som er tillatne. Eit anna VPN-produkt kan i staden eige lyttaren og den virtuelle adapteren, og la Windows videresende dei dekrypterte pakkane. Microsoft si Remote Access-dokumentasjon skil VPN-, nettstad-til-nettstad- og rutingsroller, og installasjon av rutingsrolla opprettar ikkje ein andre VPN-identitet. Å leggje til endå eit VPN-program gir heller ikkje adapteren til alle eksisterande gatewayfunksjonar.

Omsetjing er den tredje og mest valfrie oppgåva. Ho kjem etter videresendinga og endrar kjeldeadressa som det fjerne nettverket ser. Om du treng ho, avheng av kva destinasjonsnettverket godtek som kjelde, ikkje av at maskina blir kalla ein VPN-gateway.

Kven eig adapteren og poolen

Når fleire produkt deler verten, treng fire ting kvar sin einaste eigar: lyttarportar, levetida til adapteren, klientadressepoolen og rutene. Adapteren er den vanskelege, fordi ei VPN-teneste kan opprette han dynamisk og øydeleggje han ved fråkopling. Å handsame det grensesnittet som eit permanent namngitt nettverkskort og skrive reglar mot namnet verkar til neste attilkopling. Bruk det støtta integreringspunktet til produktet i staden for å hardkode eit grensesnittnamn.

Adressepoolen er den andre kollisjonen. To produkt som deler ut overlappande område, gir ruting som ser riktig ut og leverer ingenting. Hald poolane i same dokument som rutene, slik at ei endring i den eine er synleg mot den andre.

Bevar kjelda eller skriv ho om

Å bevare kjeldeadressa til klienten held synlegheita per brukar: loggar, kvotar og brannmurreglar kan skilje ein brukar frå ein annan. Prisen er at destinasjons-LAN-et treng ei returrute tilbake mot gatewayen, og nokon må vedlikehalde ho. Å skrive om kjelda med NAT fjernar det kravet og fjernar synlegheita med det. Vel medvite, og skriv ned kva informasjon omskrivinga skjuler.

Tilgang til privat nettverk, internett-utgang og tilkoplingar som blir avslutta på sjølve gatewayen, er tre ulike vegar. Dei treng ikkje alle same handsaming.

Skildre straumen i éi setning

Éi setning skal skildre designet: kva klientar denne tenesta slepp inn, kva ressursar den videresendingspolicyen gir, og korleis returvegen fullfører straumen. Viss setninga treng endå eit NAT-lag for å vere sann, er det vanlegvis eit teikn på at dei tidlegare delane ikkje var avklarte. Verten er også ein delt feil- og tillitsgrense, så ei rutingsendring kan påverke både brukartilgang og administrasjon. Hald ein uavhengig attopprettingsveg for sistnemnde.

Hald ei rolleoversikt ved sida av konfigurasjonen: kva produkt avsluttar, kva som videresender, kva som omset, og kven som kan endre kvar. Den lista er det som gjer den neste endringa reviderbar.

Når setninga blir uklar, gjer endå eit omsetjingslag ho sjeldan klarare. Å fjerne eitt gjer det vanlegvis.