Czy klient VPN w roamingu może hostować usługę dla biura?

Klient w roamingu może obsługiwać systemy biura tylko wtedy, gdy brama kieruje do niego ruch, polityka hosta na to pozwala, a urządzenie pozostaje osiągalne wystarczająco długo.

Twój służbowy laptop może łączyć się z domu i nadal udostępniać coś, czego biuro potrzebuje, ale tylko wtedy, gdy zbiegną się trzy osobne decyzje. Tunel to transport, adres wewnętrzny to cel, a polityka decyduje, kto może zapukać. Potraktowanie któregokolwiek z nich jako całej odpowiedzi daje znaną skargę: host odpowiada na pingi, ale aplikacja nigdy się nie łączy. Role nie są takie same, a różnica jest dokładnie tam, gdzie leży praca projektowa.

Kierunek połączenia nie mówi nic o kierunku usługi

Gdy klient uruchamia tunel, otwiera ścieżkę, z której oba kierunki mogą korzystać, gdy już istnieje. To, czy nowe połączenie może wejść z koncentratora w stronę tego klienta, jest kwestią polityki bramy, a nie cechą tego, kto się połączył. Na rutowanym koncentratorze OpenVPN serwer potrzebuje na przykład trasy do adresu wewnętrznego klienta i przekazywania, które dopuszcza relację peer.

Wyobraź sobie system inwentaryzacji, który odpytuje agenta na laptopach w roamingu, albo programistę potrzebującego testowego API ze stacji roboczej w domu. Oba chcą, żeby rozmowę rozpoczęła strona biurowa, co jest odwrotnością zwykłego wzorca klient-serwer.

Hostowane produkty dostępu zdalnego różnią się w tym miejscu i ta różnica nie jest błędem. Niektóre zarządzane VPN celowo blokują niepożądane połączenia w stronę podłączonych klientów, ponieważ ich model to klient-do-zasobu, a nie zasób-do-klienta. Przeczytaj udokumentowaną architekturę produktu, zanim obiecasz koledze, że jego laptop może działać jako serwer.

Prześledź ścieżkę powrotną, zanim otworzysz port

Ścieżka ma trzy części: trasę na bramie wskazującą adres wewnętrzny klienta, politykę dopuszczającą konkretnego wywołującego i usługę nasłuchującą na celu. Każda część zawodzi inaczej, dlatego „VPN jest włączony” prawie nic nie mówi.

Dobra wiadomość jest taka, że ścieżka wewnętrzna nie wymaga przekierowania portu na domowym routerze klienta. Właśnie o to chodzi w publikowaniu usługi pod adresem tunelu, a nie pod domowym adresem WAN, gdzie ekspozycja i reguły NAT byłyby zupełnie inne. Domowy router może też odmówić hairpinu połączenia przychodzącego z biura, więc trasa WAN zawodzi z powodów niezwiązanych z twoim VPN. Trzymanie ruchu wewnątrz tunelu unika obu problemów naraz.

Sprawdź także stronę celu. Usługa powiązana tylko z 127.0.0.1 nie może przyjąć połączenia przychodzącego na interfejsie tunelu, niezależnie od tego, jak poprawne są trasy bramy. Reguła firewalla hosta, która dopuszcza port tylko z lokalnej podsieci, również odrzuci ruch biurowy, a ta reguła jest niezależna od polityki VPN powyżej.

Nazwy i adresy to decyzje projektowe

Adres wewnątrz tunelu nie jest automatycznie nazwą. Prywatny rekord DNS, który kontrolujesz, jest jaśniejszy niż nadzieja, że protokół wykrywania przekroczy tunel, ponieważ lokalne rozwiązywanie nazw przez multicast pozostaje w segmencie lokalnym i nie staje się DNS między podsieciami.

Stabilność adresu znaczy tyle samo. Jeśli klienci VPN pobierają adresy z puli z krótkimi dzierżawami, adres wewnętrzny laptopa zmienia się między sesjami i każda zakładka, zakres firewalla i kontrola monitoringu zbudowane na nim cicho się psują. Użyj rezerwacji albo udokumentowanej ścieżki dynamicznej aktualizacji.

Uzgodnij nazwę z tym, kto posiada tożsamość VPN, aby rekord, przydział adresu i polityka dostępu zmieniały się razem, a nie w trzech osobnych zgłoszeniach.

Testuj usługę, nie członkostwo

Z celu potwierdź, co nasłuchuje i pod jakim adresem, a następnie potwierdź widok bramy na ścieżkę powrotną:

$ ss -ltnp | grep 8080
LISTEN 0 128 10.80.0.23:8080 0.0.0.0:*
$ ip -4 addr show tun0 | grep inet
inet 10.80.0.23/24 scope global tun0
$ ip route get 10.80.0.1
10.80.0.1 dev tun0 src 10.80.0.23

Teraz przetestuj ze strony biura prawdziwym żądaniem, a nie echem. Udany curl do usługi dowodzi trasy, polityki i nasłuchującego procesu naraz, podczas gdy udany ping dowodzi tylko, że ICMP jest dozwolony. Jeśli żądanie zawiedzie, cofaj się przez trzy części, zamiast poszerzać firewalla i liczyć na szczęście.

Dostępność należy do tej samej rozmowy. Laptop zasypia, przełącza się między sieciami i rozłącza pod koniec dnia. Usługa, która musi odpowiadać o każdej porze, należy na stale włączony host, natomiast usługa best-effort może pozostać na kliencie z zapisanym tym ograniczeniem.

Publikuj zasób świadomie, z nazwą, listą dozwolonych wywołujących i właścicielem, a zdalne urządzenie staje się wspieraną usługą, a nie przypadkowym serwerem.

Powiązane artykuły