VPN z telefonu do domu: uczyń z zapory bramę wyjściową do internetu
Dotarcie do domowej sieci LAN to nie to samo co wyjście przez domowy uplink. Zdecyduj o przekazywaniu, resolverze, IPv6 i stanie rozłączenia na telefonie.
Podłączenie telefonu do domowego tunelu i otwarcie udostępniania plików w LAN dowodzi, że tunel działa. Nie dowodzi, że żądania internetowe telefonu wychodzą przez dom. Różnicą między tymi dwoma wynikami jest polityka przekazywania plus trasa, a nie kolejne pole wyboru na telefonie. To także różnica, którą większość ludzi zakłada, że już skonfigurowała.
Trzy decyzje tworzą ścieżkę wyjścia: co telefon wysyła do tunelu, dokąd przekazuje to brama domowa i co się dzieje, gdy tunelu nie ma. Każda ma tryb awarii, który z ekranu telefonu wygląda jak pozostałe.
Dwa skoki, dwie polityki
Połączenie zewnętrzne kończy się na domowym odbiorniku VPN. Wewnętrzny pakiet to osobny obiekt, który trzeba gdzieś przekazać, a przekazywanie to inna decyzja zapory niż zaakceptowanie tunelu na początku.
phone app -> encrypted tunnel -> home listener
-> decrypted packet -> forward policy -> home uplink -> destination
Na typowym routerze domowym te elementy żyją w różnych zestawach reguł. Akceptacja tunelu to polityka wejściowa na interfejsie VPN; wysłanie ruchu telefonu do internetu to polityka przekazywania plus tłumaczenie źródła, którego potrzebuje uplink. Router, który akceptuje tunel i nic nie przekazuje, daje telefon wyświetlający połączenie i nieładujący żadnej strony.
Jeśli usługa VPN działa na osobnym komputerze w domu, dodaj skok. Router widzi teraz ruch przychodzący z tego komputera, więc jego reguły dotyczą adresu serwera, a nie adresu tunelu telefonu, a tłumaczenie źródła może sprawić, że każdy telefon wygląda jak jeden host.
Odbiornik to nie filtr
Zdecyduj, gdzie odbywa się egzekwowanie, dopóki potrzebna informacja jeszcze istnieje. Na routerze adres tunelu telefonu jest widoczny i można go dopasować bezpośrednio. Za drugim tłumaczeniem już go nie ma, a reguły napisane dla adresu telefonu po cichu do niczego nie pasują.
To zwykły powód, dla którego polityka działa dla laptopa, a nie dla telefonu. Laptop łączy się z routerem bezpośrednio, telefon łączy się z serwerem, który przekazuje przez router, i tylko pierwsza ścieżka zachowuje adres, którego oczekuje reguła. Reguła nie jest błędna; dopasowuje wartość, która w tym punkcie już nie istnieje.
Zapisz ścieżkę z adresem źródłowym tak, jak wygląda w każdym punkcie egzekwowania. Ten jeden diagram rozwiązuje większość takich przypadków, zanim zostanie zmieniona jakakolwiek reguła.
Co telefon naprawdę musi wysyłać
Telefon, który otrzymuje tylko trasę do domowej podsieci, wysyła do tunelu tylko ruch tej podsieci. Wszystko inne wychodzi przez sieć komórkową, dlatego udostępnianie plików działa, a żądania internetowe nigdy nie docierają do domu.
Pełne pokrycie tunelem to decyzja o routingu po stronie klienta i trzeba ją ustawić mechanizmem obsługiwanym przez platformę, a nie zakładać na podstawie instalowanego profilu. Po ustawieniu trasa powrotna do samego serwera VPN musi pozostać poza tunelem, inaczej klient nie może utrzymać własnego transportu.
DNS zasługuje na własną decyzję, bo to część najbardziej skłonna do odejścia od reszty ruchu. Adres resolvera w profilu to sugestia, którą klienci traktują różnie, a aplikacja z własnym szyfrowanym resolverem może pójść całkowicie osobną ścieżką. Jeśli domowa polityka zależy od tego, czy zapytania dotrą do określonego resolvera, egzekwuj ją tam, gdzie ruch naprawdę przechodzi, albo zaakceptuj, że niektóre zapytania tego nie zrobią. Zapytanie, które omija twój resolver, nigdy nie dotrze do reguły napisanej dla niego.
IPv6 należy do tego samego akapitu co DNS, nie do aneksu. Pełny tunel IPv4 nic nie mówi o ruchu AAAA, a telefon w sieci komórkowej z podwójnym stosem chętnie użyje do tego ścieżki natywnej. Wybierz przenoszenie albo blokowanie wyraźnie.
Co zapora może, a czego nie może zobaczyć
Brama może działać na tym, co ujawnia jej punkt egzekwowania: adresy, porty, protokół, interfejs i metadane połączenia. Przekazane żądanie HTTPS nie oddaje treści strony ani hasła tylko dlatego, że przechodzi przez domowy tunel.
Tę granicę warto wypowiedzieć, bo sformułowanie „poprowadź to przez zaporę” sugeruje więcej inspekcji, niż wykonuje router domowy. Reguła celu, polityka DNS i proxy warstwy aplikacji to trzy różne mechanizmy kontroli o trzech różnych kosztach wdrożenia.
Nie zakładaj, że funkcja skonfigurowana dla klientów domowego LAN dotyczy interfejsu VPN. Przynależność do strefy to wybór konfiguracji, a interfejs VPN, który nie jest we właściwej strefie, nie dziedziczy żadnej z reguł testowanych z kanapy.
Zdecyduj o stanie rozłączenia
Gdy tunel jest niedostępny, telefon albo wraca do sieci komórkowej, albo odmawia wysłania ruchu. Oba są rozsądne, a tylko jeden z nich odpowiada temu, co większość ludzi uważa, że skonfigurowała.
Powrót jest wygodny i z definicji przecieka: moment, w którym tunel pada, jest momentem, w którym żądania wychodzą ścieżką operatora. Blokowanie jest silniejsze i uzależnia telefon od osiągalności domu, co jest realnym kosztem dostępności dla osoby w podróży. Żadne z zachowań nie jest błędem; oba są produktami, a ty wybierasz między nimi, czy to powiesz, czy nie.
Przetestuj wybór, zamiast go zakładać. Zatrzymaj usługę domową, a potem spróbuj jednego żądania z przeglądarki telefonu i jednego z aplikacji działającej w tle. Późniejsze ponowne połączenie nie cofa żądań, które już wyszły.
Zakończ dwoma kontrolowanymi sprawdzeniami z samego telefonu: jedna dozwolona operacja, która powinna przejść przez dom, i jeden odmowa, którą domowa polityka powinna wymusić. Potwierdź, że brama zalogowała oczekiwany przepływ w oczekiwanej rodzinie adresów po ponownym połączeniu. Telefon pokazujący Połączono to początek tej weryfikacji, nigdy koniec.