Connexion bloquée

Symptôme : votre réseau cloud virtuel se connecte à votre réseau sur site existant à l'aide d'un VPN site à site ou d'Oracle Cloud Infrastructure FastConnect. Les hôtes d'un côté de la connexion peuvent envoyer une commande ping aux hôtes de l'autre côté, mais le trafic normal sur la connexion se bloque. Par exemple :

• Vous pouvez accéder à un hôte via SSH sur la connexion, mais après vous être connecté à l'hôte, la connexion se bloque.
• Vous pouvez démarrer une connexion VNC (Virtual Networking Computing), mais la session se bloque.
• Vous pouvez démarrer un téléchargement SFTP, mais il se bloque.

Problème général : le repérage d'unité de transmission maximale de chemin (PMTUD) ne fonctionne probablement pas sur l'un des côtés de la connexion ou les deux. Il doit fonctionner des deux côtés de la connexion afin que les deux côtés puissent savoir s'ils essaient d'envoyer des paquets trop volumineux pour la connexion et ainsi procéder à un ajustement en conséquence. Pour une brève présentation de l'unité de transmission maximale (MTU) et du repérage d'unité de transmission maximale de chemin (PMTUD), reportez-vous à Présentation de l'unité de transmission maximale (MTU) et à Présentation du repérage d'unité de transmission maximale de chemin (PMTUD).

Solutions de correction du PMTUD :

Le schéma suivant présente un exemple de scénario avec le réseau sur site connecté au réseau cloud virtuel via un VPN site à site et comporte des légendes représentant chaque partie de la solution.

1. Assurez-vous que les hôtes utilisent le PMTUD : si les hôtes du réseau sur site n'utilisent pas le PMTUD (c'est-à-dire s'ils ne définissent pas l'indicateur Ne pas fragmenter dans les paquets), ils ne peuvent pas repérer s'ils envoient des paquets trop volumineux pour la connexion. Vos instances côté Oracle de la connexion utilisent le PMTUD par défaut. Ne modifiez pas cette configuration sur les instances. Assurez-vous également que les serveurs disposent d'une règle de pare-feu autorisant ICMP de type 3 et de code 4.

2. Assurez-vous que les listes de sécurité du réseau cloud virtuel et les pare-feu de l'instance autorisent les messages ICMP de type 3 et de code 4 : lorsque le PMTUD est utilisé, les hôtes émetteurs reçoivent un message ICMP spécial s'ils envoient des paquets trop volumineux pour la connexion. A la réception du message, l'hôte peut mettre à jour de façon dynamique la taille des paquets en fonction de la connexion. Toutefois, afin que vos instances reçoivent ces messages ICMP importants, vous devez configurer à la fois les listes de sécurité pour le sous-réseau du réseau cloud virtuel et les pare-feu de l'instance pour les accepter.

   Conseil
   
   Si vous utilisez des règles de liste de sécurité avec conservation de statut (pour le trafic TCP, UDP ou ICMP), vous n'avez pas besoin de vous assurer que la liste de sécurité contient une règle explicite autorisant les messages ICMP de type 3 et de code 4, car le service Networking suit les connexions et autorise automatiquement ces messages. Les règles sans conservation de statut nécessitent une règle explicite dans la liste de sécurité entrante pour les messages ICMP de type 3 et de code 4. Vérifiez que les pare-feu d'instance sont correctement configurés.

   Pour vérifier si un hôte reçoit les messages, reportez-vous à Recherche de l'emplacement de l'endommagement du PMTUD.

3. Assurez-vous que votre routeur sur site respecte l'indicateur Ne pas fragmenter : si le routeur ne respecte pas l'indicateur et ignore donc l'utilisation du PMTUD, il envoie des paquets fragmentés aux instances du réseau cloud virtuel. Ce n'est pas ce que vous voulez voir (reportez-vous à Pourquoi éviter la fragmentation ?). Les listes de sécurité du réseau cloud virtuel sont probablement configurées de telle sorte qu'elles reconnaissent uniquement le fragment initial et suppriment les autres, entraînant un blocage de la connexion. Au lieu de cela, votre routeur doit utiliser le PMTUD et prendre en compte l'indicateur Ne pas fragmenter pour déterminer la taille correcte des paquets non fragmentés à envoyer via la connexion.

Lisez la totalité de cette rubrique pour en savoir plus sur la MTU et le PMTUD, et sur la façon de vérifier si le PMTUD fonctionne des deux côtés de la connexion réseau.

Vous vous demandez peut-être pourquoi il faut éviter la fragmentation. Tout d'abord, elle a un impact négatif sur les performances de votre application. La fragmentation requiert le réassemblage des fragments et la retransmission des fragments perdus. Le réassemblage et la retransmission exigent du temps et des ressources d'UC.

Ensuite, seul le premier fragment contient les informations de port source et de destination. Cela signifie que les pare-feu ou les listes de sécurité de votre VCN abandonnent les autres paquets, car ils sont généralement configurés pour évaluer les informations de port. Pour que la fragmentation fonctionne avec les pare-feu et les listes de sécurité, vous devez les configurer de sorte qu'ils soient plus permissifs que d'habitude, ce qui n'est pas souhaitable.

Les communications entre deux hôtes sur un réseau IP (Internet Protocol) utilisent des paquets. Chaque paquet possède une adresse IP source et de destination, ainsi qu'une charge utile. Chaque segment de réseau entre les deux hôtes possède une unité de transmission maximale (MTU) qui représente le nombre d'octets qu'un seul paquet peut transporter.

La taille MTU Internet standard est de 1 500 octets. Elle s'applique également à la plupart des réseaux domestiques et à de nombreux réseaux d'entreprise (et à leurs réseaux Wi-Fi). Certains centres de données, y compris ceux d'Oracle Cloud Infrastructure, peuvent avoir une MTU plus importante. Toutes les instances de calcul OCI utilisent une MTU de 9000 par défaut. Sur un hôte Oracle Linux 8, vous pouvez utiliser la commande ip address show pour afficher la MTU de la connexion réseau de cet hôte (ou utiliser ip link sur Red Hat Linux). Par exemple, voici la sortie d'une instance Oracle Linux 8 (la MTU est mise en évidence en rouge et en italique) :

ip address show <interface-x>
<interface-x>: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 01:00:5E:90:10:10 brd ff:ff:ff:ff:ff:ff
    ... 

Pour comparaison, voici la sortie d'un hôte Oracle Linux 8 connecté à un réseau d'entreprise :

ip address show <interface-y>
<interface-y>: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 01:00:5E:90:10:20 brd ff:ff:ff:ff:ff:ff
    ...

Cette MTU de 1 500 octets est la plus courante.

Si l'hôte se connecte par le biais d'un VPN d'entreprise, la MTU est encore plus petite car le tunnel VPN doit encapsuler le trafic dans un paquet IPSec et l'envoyer sur le réseau local. Par exemple :

ip address show <interface-z>
<interface-z>: flags=81d1<UP,POINTOPOINT,RUNNING,NOARP,PROMISC,MULTICAST> mtu 1300 
... 

Comment les deux hôtes déterminent-ils la taille des paquets qu'ils peuvent s'envoyer ? Pour de nombreux types de trafic réseau (HTTP, SSH et FTP, par exemple), les hôtes utilisent le protocole TCP pour établir les nouvelles connexions. Lors de la procédure d'établissement de liaison tridirectionnelle initiale entre deux hôtes, chacun envoie la taille de segment maximale (MSS) correspondant à la taille possible de sa charge utile. Cette taille est inférieure à la MTU. (TCP s'exécute à l'intérieur du protocole IP, ce qui explique pourquoi il est appelé TCP/IP. Les segments sont à TCP ce que les paquets sont à IP.)

A l'aide de l'application tcpdump, vous pouvez visualiser la valeur MSS partagée pendant la procédure d'établissement de la liaison. Voici un exemple provenant de tcpdump (avec la valeur MSS mise en évidence en rouge et en italique) :

12:11:58.846890 IP 192.168.0.25.22 > 10.197.176.19.58824: Flags [S.], seq
2799552952, ack 2580095593, win 26844, options [mss 1260,sackOK,TS val
44858491 ecr 1321638674,nop,wscale 7], length 0

Le paquet précédent provient d'une connexion SSH à une instance à partir d'un ordinateur portable connecté à un VPN d'entreprise. Le réseau local utilisé par l'ordinateur portable pour sa connexion Internet possède une MTU de 1 500 octets. Le tunnel VPN applique une MTU de 1 300 octets. Ensuite, lors de la tentative de connexion SSH, le protocole TCP (qui est exécuté dans la connexion IP) indique à l'instance Oracle Cloud Infrastructure qu'il prend en charge les segments TCP dont la taille est inférieure ou égale à 1 260 octets. Avec une connexion de VPN d'entreprise, l'ordinateur portable connecté au VPN possède généralement la MTU et la MSS les plus petites par rapport aux autres éléments avec lesquels il communique sur Internet.

La situation est plus complexe lorsque les deux hôtes disposent d'une MTU plus importante que celle d'une liaison réseau intermédiaire entre eux qui n'est pas directement connectée à l'un d'eux. Le diagramme suivant illustre cet exemple.

L'exemple montre deux serveurs connectés directement à leur propre réseau routé qui prend en charge une MTU de 9 000 octets. Les serveurs se trouvent dans des centres de données différents. Chaque centre de données se connecte à Internet, qui prend en charge une MTU de 1 500 octets. Un tunnel IPSec de VPN site à site connecte les deux centres de données. Ce tunnel franchit Internet : l'intérieur du tunnel possède ainsi une MTU inférieure à celle d'Internet. Dans ce diagramme, cette MTU est de 1 380 octets.

Si les deux serveurs tentent de communiquer (avec SSH, par exemple), ils s'accordent sur une MSS d'environ 8 960 lors de la procédure d'établissement de liaison tridirectionnelle. La connexion SSH initiale peut réussir car la taille maximale des paquets lors de la configuration de cette connexion SSH initiale est généralement inférieure à 1 380 octets. Lorsqu'un côté tente d'envoyer un paquet dont la taille est supérieure à celle de la liaison la plus petite entre les deux adresses, le repérage de MTU de chemin (PMTUD) devient critique.

Le repérage de MTU de chemin est défini dans RFC 1191 et RFC 8899. Il fonctionne en exigeant que les deux hôtes qui communiquent définissent un indicateur Ne pas fragmenter dans les paquets qu'ils envoient. Si un paquet de l'un de ces hôtes atteint un routeur sur lequel l'interface sortante possède une MTU inférieure à la longueur du paquet, le routeur supprime ce paquet. Le routeur renvoie également un message ICMP de type 3 et de code 4 à l'hôte. Ce message indique "Destination inaccessible, la fragmentation est requise mais l'option Ne pas fragmenter a été définie" (message défini dans RFC 792). En réalité, le routeur indique à l'hôte : "Vous avez demandé à ne pas fragmenter les paquets trop volumineux et celui-ci est trop volumineux. Je ne l'envoie pas." Le routeur indique également à l'hôte la taille maximale autorisée pour les paquets via l'interface sortante. L'hôte émetteur ajuste ensuite la taille de ses paquets sortants afin qu'ils soient inférieurs à la valeur fournie par le routeur dans le message.

Cet exemple montre le résultat lorsqu'une instance tente d'envoyer une commande ping à un hôte (203.0.113.2) via Internet avec un paquet de 8 000 octets et l'indicateur Ne pas fragmenter défini (c'est-à-dire avec l'utilisation du PMTUD). Le message ICMP renvoyé est mis en évidence en italique et en rouge :

ping 203.0.113.2 -M do -s 8000

PING 203.0.113.2 (203.0.113.2) 8000(8028) bytes of data.
From 10.0.0.2 icmp_seq=1 

Frag needed and DF set (mtu = 1500)

La réponse est exactement celle attendue. L'hôte de destination est situé sur Internet, dont la MTU est de 1 500 octets. Même si la connexion réseau locale de l'hôte émetteur possède une MTU de 9 000 octets, l'hôte ne peut pas atteindre l'hôte de destination avec un paquet de 8 000 octets. Par conséquent, il reçoit un message ICMP. Le PMTUD fonctionne correctement.

Pour comparaison, voici la même commande ping, mais avec un hôte de destination de l'autre côté d'un tunnel IPSec de VPN site à site :

ping 192.168.6.130 -M do -s 8000
PING 192.168.0.130 (192.168.0.130) 8000(8028) bytes of data.
From 192.0.2.2 icmp_seq=1 Frag needed and DF set 

(mtu = 1358)

Ici, le routeur VPN voit que pour envoyer ce paquet à sa destination, il doit utiliser un tunnel VPN comme interface sortante. Ce tunnel passe par Internet, il doit donc s'adapter à la liaison Internet, dont la MTU est de 1 500 octets. Par conséquent, l'intérieur du tunnel autorise uniquement les paquets jusqu'à 1 360 octets (que le routeur a ensuite abaissé à 1 358, ce qui peut rendre les choses plus confuses).

Si le PMTUD ne fonctionne pas quelque part sur la connexion, vous devez déterminer l'emplacement et la raison du problème. En général, il s'agit du paquet ICMP de type 3 et de code 4 (du routeur avec la liaison contrainte qui ne peut accueillir le paquet) qui n'est jamais renvoyé à l'hôte émetteur. Cela peut se produire si quelque chose bloque ce type de trafic entre l'hôte et le routeur, et de chaque côté du tunnel VPN (ou d'une autre liaison avec une MTU contrainte).

-M pmtudisc_opt
Select Path MTU Discovery strategy. pmtudisc_option may be either do
(prohibit fragmentation, even local one), want (do PMTU discovery, fragment
locally when packet size is large), or dont (do not set DF flag).

ping -M do

 -s 1500 192.168.6.130
PING 192.168.0.130 (192.168.0.130) 1500(1528) bytes of data.
From 10.0.0.2 icmp_seq=1 

Frag needed and DF set (mtu = 1358)

Oracle recommande d'utiliser le PMTUD. Toutefois, dans certains cas, il est possible de configurer des serveurs de sorte qu'ils puissent s'en passer. Prenez le cas des instances de votre réseau cloud virtuel qui communiquent sur un VPN site à site avec des hôtes de votre réseau sur site. Vous connaissez la plage d'adresses IP pour votre réseau sur site. Vous pouvez ajouter un routage spécial vers vos instances qui indique la MTU à utiliser lors de la communication avec des hôtes dans cette plage d'adresses. La communication entre instances dans le réseau cloud virtuel utilise toujours une MTU de 9 000 octets.

Les informations suivantes indiquent comment définir ce routage sur une instance Linux.

La table de routage par défaut de l'instance comprend généralement deux routages : le routage par défaut (pour la passerelle par défaut) et un routage local (pour le sous-réseau local). Par exemple :

ip route show
default via 10.0.6.1 dev ens3
10.0.6.0/27 dev ens3  proto kernel  scope link  src 10.0.6.9

Vous pouvez ajouter un autre routage pointant vers la même passerelle par défaut, avec la plage d'adresses du réseau sur site et une MTU plus petite. Par exemple, dans la commande suivante, le réseau sur site est 1.0.0.0/8, la passerelle par défaut est 10.0.6.1 et la taille maximale de MTU est de 1 300 pour les paquets envoyés au réseau sur site.

ip route add 1.0.0.0/8 via 10.0.6.1 mtu 1300

La table de routage mise à jour se présente comme suit :

ip route show
default via 10.0.6.1 dev ens3
1.0.0.0/8 via 10.0.6.1 dev ens3  mtu 1300
10.0.6.0/27 dev ens3  proto kernel  scope link  src 10.0.6.9

Dans le réseau cloud virtuel, la communication entre instances continue à utiliser une MTU de 9 000. Toutefois, la communication avec le réseau sur site utilise une valeur maximale de 1 300. Cet exemple part du principe qu'aucune partie de la connexion entre le réseau sur site et le réseau cloud virtuel n'utilise une MTU inférieure à 1 300.