Når en fjernaksessklient må fungere som en filialgateway

En bærbar PC koblet til en VPN kan nå hovedkontoret. Skriveren og filserveren på samme skrivebord kan ikke, fordi ingenting videresender pakkene deres inn i den tunnelen eller bringer svarene tilbake. Å gjøre klienten til en filialgateway er en beslutning om ruting og eierskap før det er en konfigurasjonsbeslutning. Protokollnavnet på esken svarer ikke på om den rollen støttes.

Hva protokolletiketten ikke forteller deg

OpenVPN dokumenterer et design fra sted til sted der en kobling videresender et helt subnett, og Access Server implementerer det med en gatewayrolle og eksplisitt ruting. Et annet produkt markedsført som SSL VPN kan bare tilby fjernbrukerfunksjoner, uten noen støttet måte å annonsere et nettverk bak klienten. Versjonen betyr også noe, fordi en funksjon i én utgivelse ikke er et løfte om en annen. Les implementasjonen du faktisk kjører, og behandle en oppskrift skrevet for et annet produkt som et hint, ikke et design.

Spørsmålet som må avgjøres først, er om VPN-eieren støtter videresendingsrollen i det hele tatt. Hvis ikke, gjør ingen ruting på klientsiden den støttet.

Kontrakten har to sider: filial og hovedkontor

På filialsiden eier én vert videresending, filtrering og gjenoppretting. Den trenger en bevisst vei fra hver filialenhet, og den ytre VPN-tilkoblingen må forbli tilgjengelig gjennom det underliggende nettverket selv mens tunnelen er nede. På hovedkontorets side må noen definere filialsubnettet, akseptere gatewayens identitet og tillate bestemte ressurser. Ingen av halvdelene virker alene.

Returveien er den delen som hoppes over. En tunneladresse for klienten annonserer ikke subnettet bak den, så hovedkontorets rutere trenger en rute som peker på VPN-gatewayen for det prefikset.

I et rutet design videresender konsentratoren pakker for filialprefikset, og rutingen på det overordnede LAN-et vet hvordan svarene skal sendes tilbake. I et oversatt design skrives kilden hovedkontoret ser om, noe som kan fjerne behovet for én returrute mens det skjuler hvilken filialmaskin som sendte trafikken. Den avveiningen hører hjemme i designdokumentet, fordi applikasjonslogger og tilgangsregler mister identiteten per enhet når oversettelsen kommer inn.

Rutet eller oversatt: velg returveien bevisst

Velg rutet når identitet per enhet og policy per vert betyr noe, og du kan vedlikeholde returruten på hver relevante ruter.

Velg oversatt når du ikke kan legge til ruter, men kan akseptere at hovedkontoret ser én kildeadresse. Blandede design finnes og er vanskeligere å resonnere om, så skriv ned hvilke prefikser som er rutet og hvilke som er oversatt. Bekreft deretter valget med en opptak i begge ender i stedet for å stole på tunnelstatusen.

En nyttig kontroll er asymmetrisk: be om en ressurs fra en filialenhet, og bekreft deretter at svaret forlater hovedkontoret mot filialprefikset. traceroute -n 10.60.4.20 fra en vert i hovedkontoret viser om den veien går gjennom VPN-gatewayen.

Driv det som infrastruktur, ikke som en innlogging

Bestem hvordan gatewayen starter, autentiserer, oppdaterer og gjenoppretter når ingen er logget inn. Fornyelse av legitimasjon, multifaktoroppfordringer, søvnadferd og hvem som svarer når filialen mister tilgang, blir alle operative spørsmål. Flere personer som deler én nettverksvei må ikke arve gatewaybrukerens personlige privilegier, så ressursautorisasjon, loggomfang og feilpolicy trenger en navngitt eier. Å dele en konto for å unngå registrering av hver enhet er ikke et design.

Sammenlign ordningen med en støttet stedsgateway under de samme kravene før du forplikter deg. Gjenbruk av en gammel stasjonær PC fjerner ikke vedlikeholds- eller gjenopprettingsarbeid, og bruktprisen beskriver ikke driftskostnaden.

Valider de tiltenkte filialapplikasjonene, returtrafikken deres og én avvist destinasjon under en godkjent plan. Suksess ser ut som en eid nettverkstjeneste med en navngitt filialidentitet og en eksplisitt policy, ikke et klientvindu som sier Tilkoblet.