När en fjärråtkomstklient måste fungera som filialgateway

En bärbar dator ansluten till ett VPN kan nå huvudkontoret. Skrivaren och filservern på samma skrivbord kan inte, eftersom ingenting vidarebefordrar deras paket in i den tunneln eller hämtar tillbaka svaren. Att göra klienten till en filialgateway är ett beslut om routing och ägarskap innan det är ett konfigurationsbeslut. Protokollnamnet på lådan svarar inte på om den rollen stöds.

Vad protokolletiketten inte berättar

OpenVPN dokumenterar en design från plats till plats där en anslutning vidarebefordrar ett helt subnät, och Access Server implementerar den med en gatewayroll och explicit routing. En annan produkt som marknadsförs som SSL VPN kan bara erbjuda fjärranvändarfunktioner, utan något stött sätt att annonsera ett nätverk bakom klienten. Versionen spelar också roll, eftersom en funktion i en utgåva inte är ett löfte om en annan. Läs den implementering du faktiskt kör och behandla ett recept skrivet för en annan produkt som en ledtråd, inte som en design.

Frågan som först måste avgöras är om VPN-ägaren överhuvudtaget stöder vidarebefordringsrollen. Om inte gör ingen routing på klientsidan den stödd.

Avtalet har två sidor: filial och huvudkontor

På filialsidan äger en värd vidarebefordran, filtrering och återställning. Den behöver en medveten väg från varje filialenhet, och den yttre VPN-anslutningen måste förbli nåbar via det underliggande nätverket även när tunneln ligger nere. På huvudkontorets sida måste någon definiera filialsubnätet, acceptera gatewayens identitet och tillåta specifika resurser. Ingen av halvorna fungerar ensam.

Returvägen är den del som hoppas över. En tunneladress för klienten annonserar inte subnätet bakom den, så huvudkontorets routrar behöver en rutt som pekar på VPN-gatewayen för det prefixet.

I en routad design vidarebefordrar koncentratorn paket för filialprefixet och routingen i det överordnade LAN-et vet hur svaren skickas tillbaka. I en översatt design skrivs källan som huvudkontoret ser om, vilket kan ta bort behovet av en returrutt men döljer vilken filialmaskin som skickade trafiken. Den avvägningen hör hemma i designdokumentet, eftersom applikationsloggar och åtkomstregler förlorar identiteten per enhet när översättningen kommer in.

Routad eller översatt: välj returvägen medvetet

Välj routad när identitet per enhet och policy per värd spelar roll och du kan underhålla returrutten på varje relevant router.

Välj översatt när du inte kan lägga till rutter men kan acceptera att huvudkontoret ser en enda källadress. Blandade designer finns och är svårare att resonera om, så skriv ned vilka prefix som är routade och vilka som är översatta. Verifiera sedan valet med en inspelning i båda ändar i stället för att lita på tunnelstatusen.

En användbar kontroll är asymmetrisk: begär en resurs från en filialenhet och bekräfta sedan att svaret lämnar huvudkontoret mot filialprefixet. traceroute -n 10.60.4.20 från en värd på huvudkontoret visar om den vägen går genom VPN-gatewayen.

Driv det som infrastruktur, inte som en inloggning

Bestäm hur gatewayen startar, autentiserar, uppdaterar och återställer när ingen är inloggad. Förnyelse av autentiseringsuppgifter, multifaktorfrågor, sömnbeteende och vem som svarar när filialen förlorar åtkomst blir alla operativa frågor. Flera personer som delar en nätverksväg får inte ärva gatewayanvändarens personliga privilegier, så resursauktorisering, loggomfång och felpolicy behöver en namngiven ägare. Att dela ett konto för att undvika registrering av varje enhet är inte en design.

Jämför upplägget med en stödd platsgateway under samma krav innan du binder dig. Återanvändning av en gammal stationär dator tar inte bort underhålls- eller återställningsarbete, och begagnatpriset beskriver inte driftkostnaden.

Validera de avsedda filialapplikationerna, deras returtrafik och en nekad destination enligt en godkänd plan. Framgång ser ut som en egen nätverkstjänst med en namngiven filialidentitet och en explicit policy, inte ett klientfönster som säger Ansluten.