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.
Operatorom sieci zalecamy:
- Obsługuj w swojej sieci pakiety protokołu IPv6 Encapsulating Security Payload (Next Header 50), co zapewnia, że wydajność tego ruchu będzie porównywalna z wydajnością protokołu Datagram użytkownika (UDP) lub połączeń z 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 na 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 implementuje ten standardowy protokół zabezpieczeń we wbudowanym rozwiązaniu 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 pomijać 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 przepuszczanie 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 odrzuci pakiet. Dzięki temu urządzenie nie musi wysyłać pakietów keepalive, aby utrzymać połączenie z siecią 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 napotkają problemów z połączeniem i zapewniają wydajność porównywalną do wydajności połączeń 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 połączenia wychodzące i wchodzące (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 dokumencie RFC 3948.
Aby utrzymać to połączenie, urządzenie musi okresowo wysyłać pakiety do serwera. Te pakiety muszą być wysyłane z większą częstotliwością niż limity NAT i limity czasu zapory sieciowej nałożone 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 czasu zapory NAT i zapory stanowej, aby uniknąć wpływu na czas pracy baterii. Zalecana wartość limitu czasu dla szyfrowania UDP IPsec (port 4500) to co najmniej 600 sekund.
W sieciach komórkowych limity czasu UDP NAT są często utrzymywane na niskim poziomie, ponieważ niedostateczne adresy IPv4 narzucają wysokie współczynniki ponownego wykorzystania portów. 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.