Když musí klient pro vzdálený přístup fungovat jako pobočková brána

Přenosný počítač připojený k VPN dosáhne ústředí. Tiskárna a souborový server na stejném stole ne, protože nic nepředává jejich pakety do toho tunelu ani nevrací odpovědi. Přeměna klienta na pobočkovou bránu je rozhodnutí o směrování a odpovědnosti dřív než rozhodnutí o konfiguraci. Název protokolu na krabici neodpovídá na to, zda je tato role podporovaná.

Co vám štítek protokolu neřekne

OpenVPN dokumentuje návrh typu lokalita-lokalita, v němž konektor předává celou podsíť, a Access Server jej provádí s rolí brány a explicitním směrováním. Jiný produkt prodávaný jako SSL VPN může nabízet jen funkce vzdáleného uživatele, bez podporovaného způsobu, jak ohlásit síť za klientem. Na verzi také záleží, protože funkce přítomná v jednom vydání není slibem o jiném. Čtěte implementaci, kterou skutečně provozujete, a recept napsaný pro jiný produkt berte jako vodítko, ne jako návrh.

Otázka, kterou je třeba vyřešit nejdřív, je, zda vlastník VPN roli předávání vůbec podporuje. Pokud ne, žádné směrování na straně klienta ji podporovanou neudělá.

Smlouva má dvě strany: pobočku a ústředí

Na straně pobočky vlastní předávání, filtrování a obnovu jeden hostitel. Potřebuje promyšlenou cestu od každého pobočkového zařízení a vnější připojení VPN musí zůstat dosažitelné přes podkladovou síť, i když je tunel mimo provoz. Na straně ústředí musí někdo definovat pobočkovou podsíť, přijmout identitu brány a povolit konkrétní prostředky. Ani jedna polovina nefunguje sama.

Zpáteční cesta je část, která se přeskakuje. Adresa tunelu pro klienta neohlašuje podsíť za ním, takže směrovače v ústředí potřebují trasu, která pro tento prefix ukazuje na VPN bránu.

V směrovaném návrhu koncentrátor předává pakety pro pobočkový prefix a směrování nadřazené LAN ví, jak poslat odpovědi zpět. V překládaném návrhu se zdroj, který ústředí vidí, přepisuje, což může odstranit potřebu jedné zpáteční trasy, ale skrývá, který pobočkový stroj provoz odeslal. Tento kompromis patří do návrhového dokumentu, protože protokoly aplikací a pravidla přístupu ztrácejí identitu jednotlivých zařízení, jakmile vstoupí do hry překlad.

Směrované, nebo překládané: zpáteční cestu vybírejte vědomě

Zvolte směrované, když záleží na identitě každého zařízení a politice pro každého hostitele a můžete zpáteční trasu udržovat na každém příslušném směrovači.

Zvolte překládané, když nemůžete přidávat trasy, ale můžete přijmout, že ústředí vidí jednu zdrojovou adresu. Smíšené návrhy existují a je těžší o nich uvažovat, takže si zapište, které prefixy jsou směrované a které překládané. Pak volbu ověřte zachycením na obou koncích místo toho, abyste věřili stavu tunelu.

Užitečná kontrola je asymetrická: vyžádejte prostředek z pobočkového zařízení a pak potvrďte, že odpověď opouští ústředí směrem k pobočkovému prefixu. traceroute -n 10.60.4.20 z hostitele v ústředí ukazuje, zda tato cesta prochází přes VPN bránu.

Provozujte to jako infrastrukturu, ne jako přihlášení

Rozhodněte, jak se brána spouští, ověřuje, aktualizuje a obnovuje, když nikdo není přihlášen. Obnova přihlašovacích údajů, vícefaktorové výzvy, chování při spánku a to, kdo reaguje, když pobočka ztratí přístup, se stávají provozními otázkami. Několik lidí sdílejících jednu síťovou cestu nesmí zdědit osobní oprávnění uživatele brány, takže autorizace prostředků, rozsah protokolování a politika selhání potřebují jmenovaného vlastníka. Sdílení účtu, aby se obešla registrace každého zařízení, není návrh.

Porovnejte toto uspořádání s podporovanou branou lokality za stejných požadavků, než se zavážete. Opětovné použití starého stolního počítače neodstraňuje práci na údržbě ani obnově a cena z druhé ruky nepopisuje provozní náklady.

Ověřte zamýšlené pobočkové aplikace, jejich zpáteční provoz a jeden zakázaný cíl podle schváleného plánu. Úspěch vypadá jako vlastní síťová služba s pojmenovanou identitou pobočky a explicitní politikou, ne jako okno klienta s nápisem Připojeno.