Cette page fournit des consignes aux opérateurs de réseau pour s'assurer que les applications de réseau privé virtuel (VPN) grand public et d'entreprise offrent une bonne expérience utilisateur finale sur leurs réseaux. Android fournit la classe VpnManager pour permettre aux développeurs de créer des solutions VPN, qui sont 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 consignes:
- Acceptez les paquets du protocole ESP (Encapsulating Security Payload) IPv6 (En-tête suivant 50) sur votre réseau, afin de vous assurer que ce trafic présente des performances comparables à celles des connexions TCP (User Datagram Protocol) ou UDP. Les sessions ESP doivent être autorisées à entrer dans les appareils, ou définies sur des délais avant expiration très élevés, et transférées au débit de la ligne.
- Définissez la traduction d'adresse réseau (NAT) et des délais avant expiration du pare-feu avec état de 600 secondes minimum pour les connexions UDP sur le port 4500 afin de garantir que les solutions VPN peuvent maintenir une connectivité fiable sans encourir des coûts d'énergie excessifs.
Prise en charge des paquets du protocole ESP IPv6 (en-tête suivant 50)
Encapsulating Security Payload (ESP) est le format de paquet défini dans l'ensemble de protocoles Internet Protocol Security (IPsec) pour chiffrer et authentifier les paquets dans une solution VPN. L'OS Android implémente ce protocole de sécurité standard dans sa solution VPN intégrée.
Sur les réseaux compatibles avec IPv6, les paquets ESP sont transmis directement dans des paquets IPv6 avec un champ "Next Header" de 50. Si un réseau n'accepte pas correctement ces types de paquets, cela peut entraîner un manque de connectivité pour les solutions VPN qui utilisent ce protocole sans encapsuler davantage les paquets. Le réseau peut supprimer ces paquets en raison de la configuration du pare-feu. Les paquets ESP peuvent également rencontrer des chemins lents sur le réseau, avec des performances de débit nettement dégradées par rapport aux connexions TCP ou UDP.
L'IETF (Internet Engineering Task Force) recommande d'autoriser IPsec via 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é par 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, il le supprime. Par conséquent, l'appareil n'a pas besoin d'envoyer de paquets keepalive pour maintenir la connectivité VPN, ce qui économise la durée de vie de la batterie. Nous recommandons aux réseaux d'autoriser les paquets ESP sur les appareils en permanence ou de ne les laisser expirer que 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 en-tête suivant de 50) sur leurs réseaux et de les transférer dans le matériel au débit de ligne. Cela garantit que les solutions VPN ne rencontrent pas de problèmes de connectivité et fournissent des performances comparables à celles des connexions UDP ou TCP.
Définir des délais de connexion NAT et de pare-feu avec état suffisants
Pour assurer la fiabilité de la connexion, une solution VPN doit maintenir une connexion durable au serveur VPN qui fournit une connectivité sortante et entrante (par exemple, pour recevoir des notifications push entrantes, des messages de chat et des appels audio ou vidéo). La plupart des applications VPN IPsec utilisent ESP encapsulé dans des paquets UDP IPv4 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 avant expiration du NAT et du pare-feu imposés par l'opérateur réseau. Les messages keepalive fréquents consomment beaucoup d'énergie côté client et ont un impact majeur sur l'autonomie de la batterie. Elles génèrent également un trafic de signalisation important sur le réseau, même si l'appareil est inactif.
Nous recommandons aux opérateurs d'augmenter suffisamment les délais avant expiration de la NAT et du pare-feu avec état pour éviter tout impact sur la batterie. Le délai avant expiration recommandé pour l'encapsulation UDP IPsec (port 4500) est de 600 secondes ou plus.
Dans les réseaux mobiles, les délais avant expiration NAT UDP sont souvent faibles, car la rareté des adresses IPv4 impose des facteurs de réutilisation de port élevés. Toutefois, lorsqu'un VPN est établi, le réseau de l'appareil 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. Par conséquent, le nombre de connexions de longue durée que le réseau doit prendre en charge est le même ou inférieur lorsqu'un VPN est en cours d'exécution par rapport à lorsqu'il ne l'est pas.