Brama VPN w Windows: trzy zadania, trzej właściciele

Trzy funkcje są łączone za każdym razem, gdy ktoś mówi serwer VPN: zakończenie szyfrowanego tunelu, przenoszenie pakietów między sieciami i opcjonalne przepisywanie adresów. W Windows żyją one w różnych częściach stosu, nawet gdy jedna maszyna wykonuje wszystkie trzy. Każda ma własne dane wejściowe i własny sposób awarii, i każdą można powierzyć innemu produktowi. Rozdzielenie ich na papierze to najtańszy sposób utrzymania zrozumiałości małego wdrożenia.

Czytelny projekt nazywa właściciela każdego przepływu, zamiast opisywać maszynę jako rolę.

Zakończ, przekaż, przetłumacz

RRAS obsługuje tunel w natywnym przypadku Windows: uwierzytelnia użytkownika, przydziela adres z puli i decyduje, które cele są dozwolone. Inny produkt VPN może zamiast tego posiadać nasłuch i wirtualny adapter, pozostawiając Windowsowi przekazywanie odszyfrowanych pakietów. Dokumentacja Microsoftu dotycząca Remote Access rozdziela role VPN, lokacja-lokacja i routingu, a instalacja roli routingu nie tworzy drugiej tożsamości VPN. Dodanie kolejnej aplikacji VPN również nie przekazuje jej adaptera wszystkim istniejącym funkcjom bramy.

Tłumaczenie to trzecie i najbardziej opcjonalne zadanie. Przychodzi po przekazywaniu i zmienia adres źródłowy, który widzi sieć zdalna. Czy go potrzebujesz, zależy od tego, co sieć docelowa zaakceptuje jako źródło, a nie od tego, że maszyna nazywa się bramą VPN.

Kto jest właścicielem adaptera i puli

Gdy kilka produktów dzieli host, cztery rzeczy potrzebują po jednym właścicielu: porty nasłuchu, czas życia adaptera, pula adresów klientów i trasy. Adapter jest kłopotliwy, ponieważ usługa VPN może tworzyć go dynamicznie i niszczyć przy rozłączeniu. Traktowanie tego interfejsu jako trwale nazwanej karty sieciowej i pisanie reguł przeciw jego nazwie działa do następnego ponownego połączenia. Użyj obsługiwanego punktu integracji produktu, zamiast wpisywać na stałe nazwę interfejsu.

Pula adresów to druga kolizja. Dwa produkty przydzielające nakładające się zakresy tworzą routing, który wygląda poprawnie i nic nie dostarcza. Trzymaj pule w tym samym dokumencie co trasy, aby zmiana w jednej była widoczna względem drugiej.

Zachowaj źródło albo je przepisz

Zachowanie adresu źródłowego klienta utrzymuje widoczność na użytkownika: logi, limity i reguły zapory mogą odróżnić jednego użytkownika od drugiego. Ceną jest to, że docelowa sieć LAN potrzebuje trasy powrotnej do bramy i ktoś musi ją utrzymywać. Przepisanie źródła za pomocą NAT usuwa to wymaganie i usuwa wraz z nim widoczność. Wybierz świadomie i zapisz, jakie informacje ukrywa przepisanie.

Dostęp do sieci prywatnej, wyjście do internetu i połączenia kończące się na samej bramie to trzy różne ścieżki. Nie wszystkie potrzebują takiego samego traktowania.

Opisz przepływ w jednym zdaniu

Jedno zdanie powinno opisywać projekt: jakich klientów dopuszcza ta usługa, jakie zasoby przyznaje ta polityka przekazywania i jak ścieżka powrotna kończy przepływ. Jeśli zdanie wymaga drugiej warstwy NAT, aby było prawdziwe, zwykle oznacza to, że wcześniejsze elementy nie zostały ustalone. Host jest także wspólną granicą awarii i zaufania, więc zmiana routingu może wpłynąć zarówno na dostęp użytkowników, jak i na administrację. Dla tej drugiej zachowaj niezależną ścieżkę odtwarzania.

Prowadź inwentarz ról obok konfiguracji: który produkt kończy, który przekazuje, który tłumaczy i kto może zmienić każdy z nich. Ta lista czyni następną zmianę możliwą do przejrzenia.

Gdy zdanie staje się niejasne, dodanie kolejnej warstwy tłumaczenia rzadko je wyjaśnia. Usunięcie jednej zwykle to robi.