Dlaczego Twoja prywatna chmura działa przez Wi-Fi, ale nie działa na danych mobilnych?

Prywatna chmura może działać idealnie w domowej sieci Wi-Fi, a mimo to zawodzić na danych mobilnych. Zwykle nie oznacza to, że aplikacja prywatnej chmury jest uszkodzona. Oznacza to, że telefon korzysta z innej ścieżki sieciowej.

W domu telefon może dotrzeć do lokalnego adresu IP, lokalnej nazwy hosta lub usługi wykrywania dostępnej tylko w LAN. Na danych mobilnych telefon musi dotrzeć do twojej prywatnej chmury przez domenę publiczną, publiczny adres IP, VPN, tunel lub inną zdalną ścieżkę dostępu. Jeśli DNS, routing, certyfikaty, zaufane domeny, reguły zapory lub zachowanie operatora są błędne, Wi-Fi działa, a dane mobilne zawodzą.

Wi-Fi i dane mobilne łączą się z twoją prywatną chmurą na różne sposoby

Objaw jest znany: aplikacja prywatnej chmury działa w domowej sieci Wi-Fi, kopia zapasowa zdjęć działa normalnie, synchronizacja plików łączy się, a interfejs webowy otwiera się na telefonie. Następnie przełączasz się na 5G lub LTE i pojawia się błąd czasu oczekiwania, brak połączenia, nieudane logowanie, błąd certyfikatu lub aplikacja ciągle się ładuje.

W sieci Wi-Fi telefon i prywatna chmura znajdują się w tej samej sieci LAN. Połączenie może korzystać z lokalnego adresu takiego jak 192.168.1.50adres lokalny, lokalna nazwa hosta lub automatyczne wykrywanie. Na danych mobilnych telefon jest w sieci operatora. Musi dotrzeć do twojego serwera domowego przez zdalną ścieżkę, a nie tę samą lokalną trasę.

Sukces na Wi-Fi dowodzi tylko, że lokalna ścieżka działa. Niepowodzenie na danych mobilnych oznacza, że ścieżka zewnętrzna jest nieobecna, zablokowana, źle skonfigurowana lub niekompatybilna z siecią mobilną. Rozwiązywanie problemów powinno oddzielać dostęp wewnętrzny od zewnętrznego, zamiast traktować je jako jedno połączenie.

Aplikacja może korzystać z lokalnego adresu, który działa tylko w domu

Najczęstszą i najprostszą przyczyną jest to, że aplikacja prywatnej chmury może być zapisana z adresem URL takim jak http://192.168.1.50:8080, https://cloud.local, https://nas.locallub nazwa urządzenia przypisana przez router. Te adresy mogą działać w domu, ale zawodzić wszędzie indziej.

Prywatne zakresy IPv4, takie jak 10.x.x.x, 172.16–31.x.x oraz 192.168.x.x, są przeznaczone dla sieci prywatnych. Adres prywatny dostępny tylko lokalnie nie jest publicznym adresem internetowym, więc twój telefon nie może się do niego bezpośrednio połączyć, gdy korzysta z danych mobilnych.

Jeśli aplikacja mobilna korzysta z adresu URL dostępnego tylko w sieci LAN, nie zaczynaj od przypadkowej zmiany ustawień zapory sieciowej. Najpierw zdecyduj, czy dostęp mobilny powinien korzystać z domeny publicznej, VPN lub mesh VPN, czy tunelu. Bez jednej z tych ścieżek telefon próbuje dotrzeć do adresu, który istnieje tylko w twoim domu.

Wewnętrzny URL i zewnętrzny URL są często mylone

Wiele konfiguracji prywatnej chmury kończy z dwoma tożsamościami. Wewnętrzny URL działa w domu, na przykład http://192.168.1.50:8080. Zewnętrzny URL ma działać z zewnątrz, na przykład https://cloud.example.com lub nazwy hosta tunelu.

Te dwie nazwy mogą wskazywać na tę samą usługę, ale nie są tym samym projektem dostępu. Wewnętrzny URL może używać prywatnego IP, lokalnego DNS lub certyfikatu samopodpisanego. Zewnętrzny URL może wymagać publicznego DNS, HTTPS, reverse proxy, przekierowania portów, routingu VPN lub tunelu.

Problemy pojawiają się, gdy zakładki, aplikacje mobilne, klienci synchronizacji i skróty przeglądarki mieszają te tożsamości. Dla danych mobilnych używaj zewnętrznego URL, jeśli usługa ma być dostępna z zewnątrz. Jeśli chcesz zachować wszystko prywatne, najpierw połącz się przez VPN, a potem użyj adresu LAN.

DNS może poprawnie rozwiązywać na Wi-Fi, ale zawodzić na sieci komórkowej

Domena może działać w domu, a zawodzić w danych mobilnych, ponieważ telefon pyta inny system DNS. W domu twój router, Pi-hole, AdGuard Home lub lokalny serwer DNS może rozwiązywać cloud.example.com na adres IP wewnętrzny. W danych mobilnych DNS operatora lub publiczny DNS mogą zwrócić inną odpowiedź lub wcale jej nie zwrócić.

Jest to powszechne w konfiguracjach split DNS. W sieci LAN domena wskazuje na prywatny adres dla szybkości i prostoty. Poza siecią LAN musi wskazywać na publiczne IP, nazwę dostępną przez VPN lub punkt końcowy tunelu. Jeśli rekord zewnętrzny jest brakujący lub przestarzały, telefon nie może znaleźć usługi.

Nie zakładaj, że domena jest poprawna tylko dlatego, że działa w sieci Wi-Fi. Przetestuj tę samą domenę w danych mobilnych i potwierdź, gdzie jest rozwiązywana. Jeśli wyniki DNS wewnętrzne i zewnętrzne są celowo różne, udokumentuj ten projekt, aby ustawienia aplikacji nie używały przypadkowo niewłaściwej nazwy.

Zaufane domeny, podstawowe URL i reverse proxy mogą odrzucać dostęp mobilny

Czasami żądanie z urządzenia mobilnego dociera do serwera, ale aplikacja nadal nie działa. Możesz zobaczyć ostrzeżenie o niezaufanej domenie, błąd nieprawidłowego hosta, niepowodzenie logowania, pętlę przekierowań lub problem z synchronizacją WebDAV. Zazwyczaj oznacza to, że ścieżka dotarła do prywatnej chmury, ale aplikacja nie ufa nazwie lub nagłówkom proxy, które otrzymała.

Oprogramowanie prywatnej chmury często wymaga wyraźnych ustawień nazwy hosta i adresu URL. Referencja konfiguracji Nextcloud zawiera ustawienia zaufanej domeny i podstawowego URL, a dokumentacja dotycząca reverse proxy obejmuje wykrywanie URL reverse proxy, gdy automatyczne wykrywanie nazwy hosta, protokołu lub katalogu głównego zawiedzie.

Jeśli dane mobilne ładują stronę logowania, ale logowanie, przekierowania, synchronizacja lub linki do udostępniania nie działają, sprawdź konfigurację aplikacji. Zewnętrzna nazwa hosta powinna być zaufana, publiczny URL powinien odpowiadać temu, co wpisują użytkownicy, nagłówki proxy powinny być poprawne, a przekierowania HTTP na HTTPS nie powinny kierować aplikacji z powrotem na prywatny adres LAN.

Certyfikaty HTTPS często ujawniają błędny sposób dostępu

Dostęp Wi-Fi może działać z certyfikatem samopodpisanym, wewnętrzną nazwą hosta lub ostrzeżeniem przeglądarki, które zaakceptowałeś ręcznie miesiące temu. Aplikacje mobilne mogą być bardziej rygorystyczne, zwłaszcza podczas synchronizacji plików, zdjęć, kalendarzy lub danych WebDAV w tle.

Certyfikaty HTTPS są powiązane z nazwami. Jeśli aplikacja łączy się z 192.168.1.50, cloud.local, lub inna nazwa hosta niż w certyfikacie, klienci mobilni mogą odrzucić połączenie. Jeśli reverse proxy niepoprawnie zmienia nazwę hosta lub protokół, aplikacja może również nie działać po zalogowaniu.

Czysta konfiguracja zewnętrzna używa jednej stabilnej publicznej domeny z ważnym certyfikatem i dopasowaną konfiguracją reverse proxy. Czysta konfiguracja prywatna używa najpierw VPN lub mesh VPN, a następnie dostępu wewnętrznego. Mieszanie adresów IP, nazw lokalnych, nazw publicznych i niezgodnych certyfikatów powoduje, że dostęp mobilny jest zawodny.

Przekierowanie portów, VPN lub tunel muszą zapewnić ścieżkę mobilną

Prywatna chmura nie staje się automatycznie dostępna z danych mobilnych tylko dlatego, że działa w Wi-Fi. Ruch z zewnątrz wymaga świadomej ścieżki do sieci domowej lub punktu końcowego usługi.

Istnieją trzy typowe wzorce. Przekierowanie portów kieruje określony ruch publiczny przez router do prywatnej chmury. VPN lub mesh VPN pozwala telefonowi najpierw dołączyć do prywatnej sieci. Tunel odwrotny pozwala serwerowi na nawiązanie połączenia wychodzącego do publicznego punktu końcowego, a następnie urządzenia mobilne łączą się przez ten punkt.

Do osobistego dostępu do prywatnej chmury VPN lub mesh VPN jest zwykle bezpieczniejszym pierwszym wyborem. Do bezpośredniego udostępniania usługi innym może być odpowiednia publiczna domena z HTTPS, reverse proxy i staranną kontrolą dostępu. W przypadku CGNAT lub zablokowanych routerów tunel może być bardziej praktyczny niż przekierowanie portów.

CGNAT może sprawiać, że przekierowanie portów wygląda na poprawne, ale nadal zawodzi

CGNAT jest frustrujący, ponieważ konfiguracja domowa może wyglądać poprawnie. Prywatna chmura działa na Wi-Fi. Zapora serwera zezwala na port. Router ma regułę przekierowania. Ale dane mobilne nadal nie mogą dotrzeć do usługi.

Problem polega na tym, że twój router może nie mieć prawdziwego publicznego adresu IPv4. RFC 6598 rezerwuje 100.64.0.0/10 jako współdzieloną przestrzeń adresową używaną dla CGNAT. Gdy twój ISP umieszcza router za NAT klasy operatorskiej, ruch z zewnątrz może nigdy nie dotrzeć do twojego routera domowego, więc reguła przekierowania portów nie ma nic do przekazania.

Porównaj adres WAN wyświetlany na routerze z publicznym adresem IP pokazanym przez zewnętrzną stronę do sprawdzania IP. Jeśli się nie zgadzają lub jeśli adres WAN mieści się w zakresach współdzielonych lub prywatnych, klasyczne przekierowanie portów prawdopodobnie nie jest właściwym rozwiązaniem. Zamiast tego użyj opcji publicznego IP od ISP, VPN typu mesh lub tunelu odwrotnego.

Sieci mobilne mogą dodawać problemy związane z IPv6 i specyficzne dla operatora

Niektóre problemy pojawiają się tylko na danych mobilnych. Ta sama prywatna chmura może działać z innej sieci Wi-Fi, ale zawodzić na 5G lub LTE. Albo jeden operator działa, a inny nie. To wskazuje na problem poza routerem domowym.

Sieci mobilne mogą używać projektów tylko IPv6, NAT64, CGNAT, DNS operatora, polityk APN, filtrowania lub zachowania proxy. Wskazówki Apple dotyczące kompatybilności sieci mobilnych tylko IPv6 przypominają, że sieci mobilne mogą nie działać jak zwykła dwupasmowa sieć domowa, zwłaszcza jeśli aplikacja lub serwer zakładają zachowanie tylko IPv4.

Jeśli jedyną ścieżką, która zawodzi, są dane mobilne, przetestuj to z różnych stron. Spróbuj tego samego adresu URL w przeglądarce mobilnej, przetestuj innego operatora lub hotspot, sprawdź rekordy DNS A i AAAA, potwierdź, czy serwer obsługuje używaną rodzinę adresów, i wypróbuj VPN przez dane mobilne. Jeśli VPN działa, prawdopodobnie prywatna chmura jest w porządku; problem leży w publicznej ścieżce mobilnej.

Aplikacje mobilne mogą zachowywać się inaczej niż przeglądarki

Przeglądarka na telefonie i aplikacja mobilna nie zawsze działają tak samo. Przeglądarka może otworzyć stronę logowania, podczas gdy aplikacja nie synchronizuje się. Albo aplikacja działa na Wi-Fi, ponieważ lokalnie wykrywa serwer, ale nie działa na danych mobilnych, ponieważ wykrywanie nie jest już dostępne.

Aplikacje mobilne mogą przechowywać w pamięci stary URL serwera, wymagać HTTPS, odrzucać niezgodności certyfikatów, używać punktu końcowego WebDAV lub API innego niż strona przeglądarki, ograniczać dane w tle lub inaczej obsługiwać przekierowania. Niektóre aplikacje przechowują też oddzielne adresy serwera wewnętrznego i zewnętrznego, nie ujawniając tego wprost.

Zawsze testuj obie ścieżki. Otwórz zewnętrzny URL w przeglądarce telefonu podczas korzystania z danych mobilnych, a następnie przetestuj aplikację. Jeśli przeglądarka również zawiedzie, problemem prawdopodobnie są DNS, routing, TLS, CGNAT lub konfiguracja tunelu. Jeśli przeglądarka działa, a aplikacja nie, skup się na ustawieniach URL aplikacji, zaufanych domenach, certyfikatach, ścieżkach WebDAV/API oraz pamięci podręcznej aplikacji.

VPN lub Mesh VPN często rozwiązuje problem, przywracając ścieżkę LAN

Jeśli prywatna chmura działa przez Wi-Fi, ale nie przez dane mobilne, VPN może być czystym rozwiązaniem, ponieważ zmienia pozycję telefonu. Zamiast łączyć się z prywatną chmurą jako losowy klient z zewnątrz, telefon najpierw dołącza do prywatnej sieci.

Narzędzia Mesh VPN mogą używać ścieżek bezpośrednich lub pośrednich w zależności od sieci. Tailscale dokumentuje prywatny dostęp przez połączenia bezpośrednie lub pośrednie, co jest przydatne, gdy urządzenie mobilne musi dotrzeć do serwera domowego bez bezpośredniego wystawiania prywatnej chmury na internet.

Dla dostępu osobistego jest to zazwyczaj najmniej mylący model. Aplikacja może używać wewnętrznego adresu LAN lub prywatnej nazwy DNS po połączeniu VPN. Prywatna chmura pozostaje poza otwartym internetem, a urządzenie mobilne uwierzytelnia się przed dostępem do usług wewnętrznych.

Tunel odwrotny pomaga, gdy potrzebujesz zewnętrznego URL bez otwierania portów

Tunel odwrotny jest przydatny, gdy nie możesz lub nie chcesz otwierać portów przychodzących na routerze. Jest to powszechne przy CGNAT, zablokowanych routerach ISP, internecie w mieszkaniach lub u użytkowników, którzy wolą nie wystawiać routera domowego bezpośrednio.

Cloudflare Tunnel używa tunelu wychodzącego do zdalnego dostępu, gdzie łącznik wewnątrz twojej sieci inicjuje połączenie na zewnątrz. Urządzenia mobilne następnie uzyskują dostęp do publicznej nazwy hosta, która kieruje ruch z powrotem przez tunel.

To może ułatwić dostęp do danych mobilnych, ale nadal powinno być skonfigurowane ostrożnie. Używaj polityk dostępu, HTTPS, ograniczonej ekspozycji usług oraz oddziel interfejsy administracyjne od publicznych usług dla użytkowników. Tunel rozwiązuje problem dostępności; nie rozwiązuje automatycznie uprawnień ani konfiguracji aplikacji.

Praktyczna kolejność rozwiązywania problemów

Problem staje się skomplikowany, gdy jednocześnie zmienia się DNS, reguły routera, certyfikaty, ustawienia aplikacji i sieci mobilne. Lepszym podejściem jest testowanie jednej warstwy na raz.

Zacznij od zapisania dokładnego adresu URL, który działa w Wi-Fi. Określ, czy jest to prywatny adres IP, lokalna nazwa hosta czy domena publiczna. Następnie wyłącz Wi-Fi i przetestuj ten sam adres URL na danych mobilnych. Potem przetestuj zamierzoną domenę publiczną, sprawdź publiczny DNS, porównaj adres WAN routera z publicznym IP, potwierdź, czy używasz przekierowania portów, VPN czy tunelu, a następnie sprawdź certyfikat TLS i ustawienia zaufanej domeny.

Wynik zwykle wskazuje na warstwę. Jeśli przeglądarka i aplikacja zawiodą, skup się na DNS, ścieżce publicznej, CGNAT, certyfikacie lub tunelu. Jeśli przeglądarka działa, a aplikacja zawodzi, skup się na konfiguracji aplikacji, zaufanych domenach, punktach końcowych WebDAV/API, przekierowaniach i pamięci podręcznej adresów serwera. Jeśli VPN przez dane mobilne działa, prywatna chmura jest zdrowa; problem leży w ścieżce zewnętrznej.

Bezpieczniejszym domyślnym rozwiązaniem jest jeden jasny wzorzec zdalnego dostępu

Dostęp do prywatnej chmury staje się zawodny, gdy jest zbyt wiele częściowo działających wejść: adres LAN, lokalna nazwa hosta, nazwa DDNS, adres tunelu, stary adres URL aplikacji, nazwa hosta reverse proxy i zakładka, której nikt nie pamięta, że utworzył.

Wybierz jeden główny wzorzec. Dla dostępu osobistego najczystsze jest często połączenie lokalne plus VPN. Dla bezpośredniego dostępu do aplikacji z zewnątrz użyj jednej publicznej domeny, ważnego HTTPS, poprawnych ustawień zaufanej domeny oraz bezpiecznego reverse proxy lub tunelu. W przypadku CGNAT używaj tunelu lub VPN typu mesh zamiast walczyć z przekierowaniem portów.

Im mniej punktów dostępu utrzymujesz, tym łatwiejsza staje się konfiguracja telefonu. Prywatna chmura nie powinna wymagać innego tajemniczego adresu URL dla każdej sieci. Stabilne nazewnictwo, dopasowane certyfikaty i jasna metoda dostępu sprawiają, że Wi-Fi i dane mobilne działają spójnie.

Ostateczne wnioski

Jeśli Twoja prywatna chmura działa na Wi-Fi, ale nie na danych mobilnych, sama chmura może być w porządku. Wi-Fi używa lokalnej ścieżki. Dane mobilne potrzebują ścieżki zdalnej. Awaria zwykle wynika z lokalnego URL, niezgodności DNS, braku przekierowania portów, VPN lub tunelu, CGNAT, niezgodności certyfikatu TLS, konfiguracji zaufanej domeny, zachowania IPv6/IPv4 lub różnic w aplikacji mobilnej.

Zacznij od sprawdzenia, jakiego URL używa aplikacja, czy jest on lokalny czy publiczny, czy publiczny DNS rozwiązuje nazwę, czy router ma prawdziwe publiczne IP oraz czy HTTPS i zaufane domeny pasują do nazwy zewnętrznej. Dla dostępu osobistego VPN lub mesh VPN to zazwyczaj najczystsze rozwiązanie. Dla bezpośredniego dostępu zewnętrznego używaj spójnej publicznej domeny, ważnego certyfikatu i starannie zabezpieczonej ścieżki.

Niezawodny prywatny cloud NAS może hostować pliki, zdjęcia, synchronizację, kopie zapasowe i usługi zdalnego dostępu, ale dostęp przez dane mobilne zależy od ścieżki sieciowej, domeny, certyfikatu i konfiguracji aplikacji.

FAQ

Dlaczego moja prywatna chmura działa na Wi-Fi, ale nie na danych mobilnych?

Wi-Fi korzysta z Twojej lokalnej sieci, gdzie prywatne adresy IP i lokalne nazwy hostów mogą działać. Dane mobilne korzystają z sieci operatora, więc potrzebują publicznej domeny, VPN, tunelu lub innej zewnętrznej ścieżki dostępu.

Czy mogę używać 192.168.x.x na danych mobilnych?

Nie. A 192.168.x.x adres jest prywatny i działa tylko w Twojej lokalnej sieci. Aby korzystać z niego przez dane mobilne, najpierw połącz się z domową siecią przez VPN lub mesh VPN.

Dlaczego moja domena działa w domu, ale nie w sieci komórkowej?

Twoje domowe Wi-Fi może używać lokalnego DNS, który wskazuje domenę na prywatny adres IP. W sieci komórkowej telefon korzysta z publicznego lub operatora DNS, który może nie mieć takiego samego rekordu lub wskazywać na niewłaściwy punkt końcowy.

Dlaczego przeglądarka działa, a aplikacja mobilna nie?

Aplikacja może używać innego API lub ścieżki WebDAV, przechowywać w pamięci podręcznej stary URL, wymagać zaufanej domeny, odrzucać certyfikat lub inaczej obsługiwać przekierowania niż przeglądarka.

Czy CGNAT wpływa na dostęp do prywatnej chmury z danych mobilnych?

Tak. Jeśli Twój domowy ISP używa CGNAT, przekierowanie portów może nigdy nie dotrzeć do routera. W takim przypadku użyj opcji publicznego IP, VPN/mesh VPN lub tunelu odwrotnego.

Czy IPv6 może powodować problemy z dostępem przez dane mobilne?

Może tak być. Niektóre sieci mobilne używają tylko IPv6 lub preferują ścieżki IPv6. Jeśli Twoja domena, aplikacja lub serwer domowy obsługuje tylko IPv4 lub ma niepoprawne rekordy DNS, dane mobilne mogą działać inaczej niż Wi-Fi.

Czy VPN jest lepszy niż otwieranie portów dla prywatnej chmury?

Zazwyczaj tak, jeśli chodzi o dostęp osobisty. VPN lub mesh VPN utrzymuje prywatną chmurę z dala od otwartego internetu i pozwala zaufanym urządzeniom uzyskać do niej dostęp tak, jakby były w domowej sieci LAN.

Co powinienem sprawdzić najpierw?

Sprawdź URL zapisany w aplikacji. Jeśli jest to lokalny adres IP lub .local hostname, nie będzie działać na danych mobilnych, chyba że użyjesz VPN. Następnie sprawdź publiczny DNS, CGNAT, HTTPS, zaufane domeny i ustawienia aplikacji.