Nextcloud tylko przez VPN: najpierw zinwentaryzuj wszystkie wejścia

Plan Nextcloud tylko przez VPN zawodzi, gdy chroni przeglądarkę, a zapomina o kliencie synchronizacji. Strona internetowa, silnik synchronizacji na komputerze, przesyłanie z urządzeń mobilnych, narzędzia WebDAV i odbiorcy udostępnionych linków wszyscy potrzebują ścieżki do tej samej usługi, a każde z nich może ujawnić inne wejście. Zinwentaryzuj je, zanim cokolwiek zamkniesz. Ta lista to prawdziwy obwód.

Przejdź listę kontrolną po kolei. Pierwszy punkt określa, co oznacza prywatne w tym wdrożeniu; kolejne punkty sprawdzają, czy wdrożenie naprawdę odpowiada tej definicji.

Zdefiniuj prywatne, zanim zmienisz obwód

Zapisz wymaganie w jednym zdaniu: każdy użytkownik musi dołączyć do VPN, zanim dotrze do aplikacji, albo aplikacja może pozostać publiczna, a jej źródło pozostaje prywatne. To różne projekty, a publiczne proxy odwrotne, które przekazuje do prywatnego tunelu, spełnia tylko drugi.

Prywatny adres backendu nie czyni aplikacji prywatną. Jeśli publiczne mapowanie, druga nazwa hosta lub odbiornik IPv6 nadal docierają do tej samej instancji Nextcloud, wejście istnieje niezależnie od tego, gdzie znajduje się backend. Przetestuj każdą nazwę z zewnątrz, zanim ogłosisz usługę prywatną. Brakujący rekord DNS to nie to samo co zamknięty port.

Uzgodnij też grupę docelową: pracownicy, gospodarstwo domowe, organizacja partnerska albo podzbiór kont. Odpowiedź decyduje, czy publiczny link do udostępniania jest funkcją, czy sprzecznością. Zapisz tę grupę w planie dostępu. To test każdego wyjątku, który nastąpi.

Zinwentaryzuj każde wejście i każdą nazwę

Wymień publiczne mapowania adresów, proxy odwrotne, alternatywne nazwy hostów, odbiorniki IPv6 i każdy adres tunelu lub sieci mesh, który dociera do usługi. Uwzględnij nazwy, które rozwiązują się na te adresy, bo zapomniany rekord DNS to wejście z przyjazną etykietą.

Sprawdź konfigurację proxy pod kątem przekazywanych nagłówków i alternatywnych bloków serwera. Proxy dodane dla innej aplikacji może ujawnić ten sam upstream przez ścieżkę albo pozostały host wirtualny. Czytaj rzeczywistą konfigurację, a nie zamierzony diagram. Oba najczęściej się rozchodzą po przeniesieniu aplikacji.

Następnie zablokuj wejścia, których nie wybrałeś. Prywatny backend z publicznym frontem to nie projekt tylko przez VPN, a reguła zapory obejmująca tylko IPv4 pozostawia odbiornik IPv6 otwarty. Zamknij obie rodziny i obie nazwy w tej samej zmianie.

Daj każdemu klientowi jedną nazwę usługi

Wskaż prywatny DNS na usługę, przeprowadź tę nazwę przez VPN i wystaw dla niej certyfikat. Nazwa musi rozwiązywać się przez prywatną ścieżkę i być weryfikowana bez ostrzeżenia. Klient, który dociera bezpośrednio do adresu IP, nadal potrzebuje działającej nazwy.

Klienci łączący się przez niepowiązany adres IP nie powinni musieć odrzucać błędów certyfikatu, aby projekt działał. Stabilna nazwa powstrzymuje też klienty synchronizacji przed tworzeniem zduplikowanych wpisów serwera, gdy adres się zmienia. To różnica między prywatną usługą a prywatnym adresem IP.

Zostaw włączoną weryfikację certyfikatów. Prywatna sieć zmniejsza ekspozycję, ale nie czyni niezweryfikowanego połączenia TLS akceptowalnym, a klient przyzwyczajony do ignorowania ostrzeżeń będzie je ignorował także w innych sieciach.

Ogranicz dostęp sieciowy, a nie całą sieć LAN

Pozwól zarejestrowanym użytkownikom docierać do usługi Nextcloud i jej niezbędnych zależności, a administrację serwera trzymaj na osobnej ścieżce. VPN, które wpuszcza klienta do całej sieci domowej lub biurowej daje temu klientowi znacznie więcej, niż wymaga aplikacja.

Dostęp przez VPN nie zastępuje kont, uprawnień ani dodatkowego uwierzytelniania Nextcloud. Aplikacja nadal decyduje, który użytkownik może czytać który plik, a warstwa sieciowa nie powinna być jedyną kontrolą.

Zapisz zatwierdzony zakres źródłowy i porty usługi. Właściciel celu potrzebuje obserwowanego źródła, a NAT lub proxy mogą je przepisać, zanim żądanie dotrze do aplikacji.

Przejrzyj każdy przepływ pracy poza przeglądarką

Synchronizacja na komputerze i przesyłanie z urządzeń mobilnych otwierają własne połączenia w swoich momentach. Potrzebują zatwierdzonej prywatnej ścieżki, gdy się łączą, i mogą zachowywać się inaczej, gdy brakuje VPN: ponawiać, wstrzymywać lub pokazywać błąd. Przetestuj każdy z nich, nie tylko przeglądarkę.

Narzędzia WebDAV oraz klienty kalendarza lub kontaktów to osobne integracje z własną konfiguracją. Klient, który buforuje publiczny URL, nadal próbuje tego URL po zmianie obwodu, a błąd wygląda jak problem aplikacji.

Udostępnione linki zasługują na wyraźną decyzję. Link nie daje odbiorcy dostępu do VPN, więc w projekcie naprawdę tylko przez VPN zewnętrzny odbiorca nie może go użyć, nawet jeśli link jest ważny. Jeśli udostępnianie na zewnątrz jest konieczne, to świadomy wyjątek z własną ścieżką dostępu, a nie przeoczenie odkryte później.

Federacja i integracje serwer-serwer wymagają takiego samego traktowania. To relacje osiągalności między instalacjami, a wdrożenie tylko prywatne musi powiedzieć, czy są obsługiwane.

Zaakceptuj zarówno przypadek dozwolony, jak i odrzucony

Od zatwierdzonego klienta sprawdź interfejs sieciowy oraz zwykłe wysłanie lub pobranie pliku. Następnie sprawdź klienta synchronizacji i jeden przepływ pracy poza przeglądarką. Sukces tylko w przeglądarce nie jest akceptacją.

Z niezatwierdzonej ścieżki potwierdź, że aplikacja jest nieosiągalna przez każde wejście z inwentarza. Przetestuj alternatywną nazwę hosta i adres IPv6, nie tylko główny URL.

Na koniec przejrzyj ustawienia aplikacji, które łatwo pomylić z polityką sieciową. trusted_domains wymienia nazwy akceptowane przez instancję; to nie jest lista dozwolonych adresów IP klientów. Jeśli proxy odwrotne dostarcza informacje o adresie, trusted_proxies musi wskazywać rzeczywiste proxy, a przekazywane nagłówki powinny być akceptowane tylko od niego.

Kontynuuj zwykłe utwardzanie równolegle ze zmianą sieci: trzymaj dane i kopie zapasowe poza niezamierzonymi ścieżkami sieciowymi, poprawiaj aplikację, chroń dostęp administratora i utrzymuj odzyskiwanie w użytecznym stanie. VPN usuwa jedną powierzchnię wejścia; nie czyni zarejestrowanego klienta godnym zaufania.