Jedna maszyna Azure VM potrzebuje tunelu: klient w gościu czy brama VPN?

Jedno obciążenie w jednej maszynie Azure VM musi dotrzeć do sieci prywatnej przez tunel. Pytaniem rozstrzygającym projekt nie jest to, który produkt VPN jest lepszy, ale czy kiedykolwiek inna maszyna będzie potrzebować tej ścieżki. Odpowiedz na to najpierw, a reszta architektury zwykle wybiera się sama. Jeśli się pomylisz, odziedziczysz maszynę, która po cichu stała się routerem, którego nikt nie udokumentował.

Dwa zajęcia, które wyglądają podobnie

Maszyna może być punktem końcowym albo punktem tranzytowym, a różnica nie leży w instalowanym oprogramowaniu, lecz w tym, kto korzysta z tunelu. Jako punkt końcowy gość uruchamia klienta dla własnych procesów. Jako punkt tranzytowy przekazuje pakiety innych obciążeń, przez co staje się częścią topologii sieci.

Większość zgłoszeń dotyczących jednej maszyny to pierwsze zadanie ubrane w język drugiego. Ktoś mówi „maszyna to nasz VPN”, mając na myśli, że jedna aplikacja na niej musi dotrzeć do bazy danych po drugiej stronie.

Warunek pierwszy: czy coś jeszcze potrzebuje drugiej strony?

Jeśli odpowiedź brzmi nie, zainstaluj klienta w gościu i przestań projektować. Nic w tym wyborze nie wymaga zarządzanej bramy i nic nie czyni z maszyny bramy dla jej sąsiadów. Dodajesz trasę wewnątrz jednego systemu operacyjnego.

Jeśli odpowiedź brzmi tak albo prawdopodobnie tak w ciągu roku, potraktuj to teraz jako projekt sieci. Inne maszyny docierają do maszyny tranzytowej tylko wtedy, gdy tabela tras podsieci je tam wyśle, a karta NIC przyjmie przekazywany ruch, więc praca polega na tabelach tras i uprawnieniach do przekazywania, a nie na kolejnej instalacji klienta.

Warunek drugi: czy utrzymasz ścieżkę administracyjną?

Klient VPN, który instaluje szeroką trasę, może przejąć ścieżkę, którą administrujesz maszyną. Jeśli lista celów tunelu pokrywa się z siecią zarządzania, Twoja sesja SSH lub RDP pada w chwili, gdy klient się łączy, a poprawkę trzeba wprowadzić przez konsolę szeregową albo odbudowę.

Sprawdź przed i po. W Linuksie ip route get <management-ip> pokazuje, którego interfejsu i źródła jądro użyłoby teraz; porównaj to z odpowiedzią, gdy tunel jest aktywny. Tunel dzielony z jawną listą celów łatwiej obronić niż trasę domyślną, i zwykle tego obciążenie naprawdę potrzebuje.

Warunek trzeci: kto łata go o północy?

Klient w gościu to Twój system operacyjny, Twoja wersja klienta i Twoje certyfikaty. To w porządku, gdy już prowadzisz maszynę i jej cykl łataninia. To zły interes, gdy maszyna istnieje tylko po to, by utrzymać tunel. Policz godziny łataninia, zanim nazwiesz klienta w gościu tańszym. Aktualizacja klienta wymagająca restartu to przestój, który sam zaplanowałeś dla maszyny istniejącej po to, by tunel działał.

Zarządzana brama przenosi tę konserwację na platformę. Nadal odpowiadasz za tożsamość, autoryzację i ścieżki sieciowe za nią, ale nie restartujesz maszyny, by zastosować aktualizację klienta.

Czego zarządzana brama nie robi

Azure VPN Gateway to usługa łączności VNet z własnymi rozwiązaniami lokacja-lokacja i punkt-punkt. Nie jest regułą zakazującą oprogramowania VPN w gościu ani bezpośrednim zamiennikiem klienta, którego potrzebuje jedna aplikacja.

Daje połączenie w warstwie sieci, osiągalne dla wielu obciążeń przez routing. Nie daje tunelu, z którego korzysta tylko jeden proces na jednej maszynie i który jest ograniczony do tożsamości tego procesu. To ograniczenie nie jest wadą, za którą trzeba przepraszać; właśnie taki jest sens projektu z klientem w gościu. Jedna aplikacja, jedna trasa, jeden zestaw poświadczeń, żadnego wpływu na inne maszyny w podsieci.

Porównanie nie dotyczy więc zarządzanego kontra oprogramowanie. Chodzi o łączność w skali sieci kontra łączność w skali procesu, a ta druga jest uzasadniona, gdy potrzebuje jej tylko jeden proces.

Zaplanuj ścieżkę wzrostu, zanim będzie potrzebna

Jeśli wymaganie rośnie z jednej maszyny do podsieci, zbuduj projekt od nowa, zamiast rozszerzać dozwolone prefiksy klienta. Ponowne użycie wygodnej sesji jako nieudokumentowanego routera wiąże każdego użytkownika z czasem życia tej maszyny, jej poświadczeniami i jej oknem łatanienia.

Właściwym punktem wyjścia, gdy połączenie ma skalę sieci, a nie obciążenia, jest przegląd Azure VPN Gateway.

Zanim wybierzesz, napisz trzy linie: czego potrzebuje druga strona, kto administruje maszyną i kto łata tunel. Jeśli wszystkie trzy odpowiedzi wskazują jedno obciążenie, klient w gościu jest uczciwym projektem. Jeśli którakolwiek wskazuje podsieć, projektuj warstwę sieci teraz.