Cette page fournit des consignes aux opérateurs de réseau pour s'assurer que les applications de réseau privé virtuel (VPN) pour les particuliers et les entreprises offrent une bonne expérience utilisateur finale sur leurs réseaux. Android fournit la classe VpnManager aux développeurs pour 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 réseau de suivre ces consignes :
- Assurez-vous que votre réseau est compatible avec les paquets du protocole IPv6 ESP (Next Header 50), en veillant à ce que ce trafic offre des performances comparables à celles des connexions UDP (User Datagram Protocol) ou TCP (Transmission Control Protocol). Les sessions ESP doivent être autorisées en entrée vers les appareils ou définies sur des délais d'expiration très longs, et transférées à la vitesse de ligne.
- Définissez des délais d'expiration pour la traduction d'adresse réseau (NAT) et le pare-feu avec état d'au moins 600 secondes pour les connexions UDP sur le port 4500. Cela permet aux solutions VPN de maintenir une connectivité fiable sans entraîner de coûts d'alimentation excessifs.
Prise en charge des paquets de 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 transportés directement dans les paquets IPv6 avec un champ "En-tête suivant" défini sur 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 protocole sans encapsulation supplémentaire des paquets. Le réseau peut supprimer ces paquets en raison de la configuration du pare-feu. Les paquets ESP peuvent également emprunter des chemins lents sur le réseau, ce qui entraîne une dégradation importante du débit par rapport aux connexions TCP ou UDP.
L'Internet Engineering Task Force (IETF) recommande d'autoriser IPsec via les pare-feu utilisés par les services d'accès à Internet grand public. Pour obtenir un exemple, consultez la section 3.2.4 du document RFC 6092. Les paquets ESP peuvent être autorisés de manière sécurisée 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 permet d'économiser la batterie. Nous recommandons aux réseaux d'autoriser les paquets ESP sur les appareils à tout moment ou de laisser expirer les sessions ESP uniquement 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 de protocole ESP (paquets IPv6 avec un en-tête suivant de 50) sur leurs réseaux et de transférer ces paquets dans le matériel à la vitesse de ligne. Cela permet de s'assurer que les solutions VPN ne rencontrent pas de problèmes de connectivité et offrent des performances comparables à celles des connexions UDP ou TCP.
Définir des délais d'expiration suffisants pour le pare-feu NAT et 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 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 régulièrement des paquets au serveur. Ces paquets doivent être envoyés à une fréquence supérieure aux délais d'expiration du NAT et du pare-feu imposés par l'opérateur réseau. Les signaux de présence fréquents sont gourmands en énergie côté client et ont un impact majeur sur l'autonomie de la batterie. Ils 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 d'expiration du pare-feu NAT et avec état pour éviter tout impact sur la batterie. Le délai d'expiration recommandé pour l'encapsulation UDP IPsec (port 4500) est de 600 secondes ou plus.
Dans les réseaux mobiles, les délais d'expiration UDP NAT 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 distribuer les notifications entrantes. Le nombre de connexions de longue durée que le réseau doit prendre en charge est donc identique ou inférieur lorsque le VPN est en cours d'exécution par rapport à lorsqu'il ne l'est pas.