Na tej stronie znajdziesz wskazówki dla operatorów sieci, które pomogą im zapewnić użytkownikom końcowym płynne działanie aplikacji VPN dla konsumentów i firm w ich sieciach. Android udostępnia klasę VpnManager, która umożliwia deweloperom tworzenie rozwiązań VPN. Są one używane przez konsumentów i przedsiębiorstwa do szyfrowania komunikacji lub kierowania jej do różnych sieci.
Zalecamy, aby operatorzy sieci przestrzegali tych wskazówek:
- Obsługa pakietów IPv6 Encapsulating Security Payload (ESP) (Next Header 50) w sieci, aby zapewnić temu ruchowi porównywalne osiągiwanie w porównaniu z połączeniami protokołem pakietów użytkownika (UDP) lub protokołem kontroli transmisji (TCP). Sesje ESP powinny być dozwolone dla urządzeń lub mieć bardzo długie limity czasu i przesyłane z prędkością linii.
- Ustaw czas oczekiwania na odpowiedź serwera NAT i zapory sieciowej z uwzględnieniem stanu, który wynosi co najmniej 600 sekund w przypadku połączeń UDP na porcie 4500, aby zapewnić niezawodne połączenie rozwiązań VPN bez nadmiernych kosztów energii.
Obsługa pakietów protokołu ESP IPv6 (następny nagłówek 50)
Encapsulating Security Payload (ESP) to format pakietu zdefiniowany w ramach zestawu protokołów Internet Protocol Security (IPSec) do szyfrowania i uwierzytelniania pakietów w rozwiązaniu VPN. System operacyjny Android wdraża ten standardowy protokół zabezpieczeń w ramach wbudowanego rozwiązania VPN.
W sieciach obsługujących IPv6 pakiety ESP są przenoszone bezpośrednio w pakietach IPv6 z polem Następny nagłówek o wartości 50. Jeśli sieć nie obsługuje prawidłowo tych typów pakietów, może to spowodować brak połączenia w przypadku rozwiązań VPN, które korzystają z tego protokołu bez dalszego opakowania pakietów. Sieć może odrzucić te pakiety z powodu konfiguracji zapory sieciowej. Pakiety ESP mogą też trafiać na wolne ścieżki w sieci, co powoduje znaczne pogorszenie przepustowości w porównaniu z połączeniami TCP lub UDP.
Internet Engineering Task Force (IETF) zaleca zezwalanie na protokół IPsec przez zapory sieciowe używane przez konsumenckie usługi dostępu do internetu. Patrz na przykład RFC 6092, sekcja 3.2.4. Pakiety ESP mogą być bezpiecznie przepuszczane przez zapory w obu kierunkach, ponieważ jeśli urządzenie otrzyma pakiet ESP, który nie jest częścią istniejącego skojarzenia zabezpieczeń, urządzenie odrzuca ten pakiet. Dzięki temu urządzenie nie musi wysyłać pakietów keepalive, aby utrzymać połączenie VPN, co pozwala oszczędzać baterię. Zalecamy, aby sieci zezwalały na wysyłanie pakietów ESP do urządzeń przez cały czas lub aby sesje ESP były przerywane dopiero po długim okresie braku aktywności (np. 30 minut).
Zalecamy, aby operatorzy sieci obsługiwali pakiety protokołu ESP (pakiety IPv6 z nagłówkiem Next Header o wartości 50) w swoich sieciach i przekierowywali te pakiety w sprzęcie z pełną szybkością. Dzięki temu rozwiązania VPN nie będą mieć problemów z połączeniem i będą zapewniać wydajność porównywaną z połączeniami UDP lub TCP.
Ustaw wystarczające limity czasu NAT i zapory sieciowej ze stanem.
Aby zapewnić niezawodność połączenia, rozwiązanie VPN musi utrzymywać długotrwałe połączenie z serwerem VPN, który zapewnia wychodzącą i wchodzącą łączność (np. do odbierania powiadomień push, wiadomości czatu oraz połączeń audio i wideo). Większość aplikacji VPN IPsec używa ESP zakapsułkowanego w pakietach UDP IPv4 z portem docelowym 4500, zgodnie z opisem w RFC 3948.
Aby utrzymać to połączenie, urządzenie musi okresowo wysyłać pakiety do serwera. Pakiety te muszą być wysyłane z większą częstotliwością niż czasy bezczynności NAT i zapory sieciowej narzucone przez operatora sieci. Częste wywołania keepalive zużywają dużo energii po stronie klienta i mają duży wpływ na czas pracy baterii. Generują też znaczny ruch sygnalizacyjny w sieci, nawet jeśli urządzenie jest nieaktywne.
Zalecamy, aby operatorzy zwiększyli limity czasów oczekiwania NAT i zapory sieciowej z uwzględnieniem stanu, aby uniknąć wpływu na zużycie baterii. Zalecana wartość limitu czasu dla szyfrowania UDP IPsec (port 4500) to co najmniej 600 sekund.
W sieciach mobilnych limity czasu NAT UDP są często utrzymywane na niskim poziomie, ponieważ niedobór adresów IPv4 powoduje, że czynniki ponownego użycia portu są wysokie. Jednak po nawiązaniu połączenia VPN sieć urządzenia nie musi obsługiwać długotrwałych połączeń TCP, takich jak te używane do dostarczania przychodzących powiadomień. Oznacza to, że liczba długotrwałych połączeń, które sieć musi obsługiwać, jest taka sama lub mniejsza, gdy VPN działa, niż gdy nie działa.