Cette page fournit des directives aux opérateurs de réseau pour garantir que les applications de réseau privé virtuel (VPN) grand public et d'entreprise offrent une bonne expérience à l'utilisateur final sur leurs réseaux. Android fournit la classe VpnManager permettant aux développeurs de créer des solutions VPN, utilisées par les consommateurs et les entreprises pour chiffrer leurs communications ou les acheminer vers différents réseaux.
Nous recommandons aux opérateurs de réseau de suivre ces directives :
- Prend en charge les paquets du protocole ESP (Encapsulated Security Payload) IPv6 (Next Header 50) sur votre réseau , garantissant que ce trafic a des performances comparables à celles du protocole de datagramme utilisateur (UDP) ou des connexions du protocole de contrôle de transmission (TCP). Les sessions ESP doivent être autorisées à entrer sur les appareils, ou définies sur des délais d'attente très élevés, et transférées au débit de ligne.
- Définissez des délais d'expiration de traduction d'adresses réseau (NAT) et de pare-feu dynamique d'au moins 600 secondes pour les connexions UDP sur le port 4500 afin de garantir que les solutions VPN peuvent maintenir une connectivité fiable sans encourir de coûts d'énergie excessifs.
Prise en charge des paquets du protocole IPv6 ESP (Next Header 50)
Encapsulated Security Payload (ESP) est le format de paquet défini dans le cadre de l'ensemble de protocoles Internet Protocol Security (IPSec) pour chiffrer et authentifier les paquets dans une solution VPN. Le système d'exploitation Android implémente ce protocole de sécurité standard dans sa solution VPN intégrée.
Sur les réseaux compatibles IPv6, les paquets ESP sont transportés directement dans des paquets IPv6 avec un champ Next Header de 50. Si un réseau ne prend pas correctement en charge ces types de paquets, cela peut entraîner un manque de connectivité pour les solutions VPN qui visent à utiliser ce type de paquets. protocole sans encapsulation supplémentaire des paquets. Le réseau peut abandonner ces paquets en raison de la configuration du pare-feu. Les paquets ESP peuvent également emprunter des chemins lents sur le réseau, avec des performances de débit gravement dégradées par rapport aux connexions TCP ou UDP.
L'Internet Engineering Task Force (IETF) recommande d'autoriser IPsec à travers les pare-feu utilisés par les services d'accès Internet grand public. Par exemple, consultez la section 3.2.4 de la RFC 6092 . Les paquets ESP peuvent être autorisés en toute sécurité à travers les pare-feu dans les deux sens, car si un appareil reçoit un paquet ESP qui ne fait pas partie d'une association de sécurité existante, l'appareil abandonne le paquet. En conséquence, l'appareil n'a pas besoin d'envoyer des paquets keepalive pour maintenir la connectivité VPN, ce qui permet d'économiser la batterie. Nous recommandons que les réseaux autorisent les paquets ESP vers les appareils à tout moment ou n'interrompent les sessions ESP qu'après de longues périodes d'inactivité (par exemple 30 minutes).
Nous recommandons aux opérateurs réseau de prendre en charge les paquets du protocole ESP (paquets IPv6 avec un Next Header de 50) sur leurs réseaux et de transmettre ces paquets dans le matériel au débit de ligne. Cela garantit que les solutions VPN ne rencontrent pas de problèmes de connectivité et offrent des performances comparables aux connexions UDP ou TCP.
Définir des délais d'expiration suffisants pour le NAT et le pare-feu avec état
Pour maintenir la fiabilité de la connexion, une solution VPN doit maintenir une connexion de longue durée au serveur VPN qui fournit une connectivité sortante et entrante (par exemple, pour recevoir des notifications push entrantes, des messages de discussion et des appels audio/vidéo). La plupart des applications VPN IPsec utilisent ESP encapsulé dans des paquets IPv4 UDP avec le port de destination 4500, comme décrit dans la RFC 3948 .
Pour maintenir cette connexion, l'appareil doit envoyer périodiquement des paquets au serveur. Ces paquets doivent être envoyés à une fréquence supérieure aux délais d'attente NAT et pare-feu imposés par l'opérateur réseau. Les keepalives fréquentes consomment beaucoup d'énergie du côté client et ont un impact majeur sur la durée de vie de la batterie. Ils génèrent également un trafic de signalisation important sur le réseau, même si l'appareil est par ailleurs inactif.
Nous recommandons aux opérateurs d’augmenter suffisamment les délais d’expiration du NAT et du pare-feu dynamique pour éviter tout impact sur la batterie. Le délai d'expiration recommandé pour l'encapsulation IPsec UDP (port 4500) est de 600 secondes ou plus.
Dans les réseaux mobiles, les délais d'expiration UDP NAT sont souvent maintenus à un niveau bas, car la rareté des adresses IPv4 impose des facteurs de réutilisation des ports élevés. Cependant, lorsqu'un VPN est établi, le réseau de périphériques n'a pas besoin de prendre en charge les connexions TCP de longue durée, telles que celles utilisées pour envoyer des notifications entrantes. Ainsi, le nombre de connexions de longue durée que le réseau doit prendre en charge est identique ou inférieur lorsqu'un VPN est en cours d'exécution que lorsqu'un VPN ne fonctionne pas.