OpenVPN sur GCE : ajouter une IP alias avant de pousser des routes

Une route poussée ne fait pas de la VM un next hop. Ajoutez la plage d’IP alias, alignez-la sur le pool du serveur et créez la route de retour VPC avant de tester les clients.

Un client se connecte au serveur OpenVPN sur une VM Compute Engine, la fenêtre d’état indique connecté, et un ping vers un hôte du VPC n’arrive toujours nulle part. Le réflexe est d’ajouter une ligne push de plus, et cela ne corrige jamais le problème. Compute Engine décide où vont les paquets d’après sa propre table de routage et d’après les adresses qu’une interface de VM détient réellement, donc un pool de tunnel que la VM ne possède pas est un pool que personne ne dessert.

Suivez le paquet qui échoue plutôt que le fichier de configuration, et les pièces manquantes apparaissent dans l’ordre.

Partir du paquet qui meurt

Le SYN quitte le client, entre dans le tunnel et atteint la VM sous forme de paquet encapsulé vers une destination du VPC. OpenVPN le décapsule et tente de le transmettre par eth0, où la fabrique pose une question avant tout le reste : cette instance possède-t-elle l’adresse de destination. Un pool de tunnel taillé dans le sous-réseau d’un autre échoue à cette question, et le paquet est jeté avant qu’une quelconque route ou règle de pare-feu soit consultée.

Le sens client vers VPC a donc deux exigences distinctes, et aucune n’est une directive push. La VM a besoin d’une plage alias qui couvre le pool de tunnel, et c’est ce qui en fait la propriétaire légitime de ces adresses. Le VPC a besoin d’une route qui désigne la VM comme next hop pour chaque préfixe protégé. Il en manque une et le paquet meurt ailleurs, tandis que le client voit le même silence.

Lisez la panne dans cet ordre, car du côté client les deux conditions sont identiques. Un tunnel qui se dit connecté alors que rien ne répond est la signature d’un problème de topologie, pas d’un mauvais chiffrement.

L’instance possède-t-elle le pool de tunnel

Donnez à la VM une plage secondaire à l’intérieur de son propre sous-réseau, puis faites distribuer par OpenVPN des adresses issues exactement de cette plage. Sur une instance dont l’adresse principale est 10.156.0.10/20, un alias /28 garde le pool séparé des adresses que d’autres instances détiennent déjà :

gcloud compute instances network-interfaces update openvpn-vm \
  --zone=europe-west1-b \
  --aliases=eth0:10.156.1.0/28

La directive server doit alors décrire le même bloc. Sa première adresse devient la passerelle du tunnel, et les adresses restantes sont distribuées aux clients. Deux nombres décrivent ici un bloc, un réseau et un masque, et c’est la syntaxe de pool qu’OpenVPN attend encore.

server 10.156.1.0 255.255.255.240

Vérifiez que l’adresse a réellement atterri sur l’interface et pas seulement dans la configuration OpenVPN. La fabrique transmet ce que la carte réseau déclare, pas ce que le démon croit. Une commande tranche :

ip -4 addr show dev eth0

Une adresse secondaire qui n’atteint jamais eth0, ou un pool qui chevauche un autre sous-réseau, se manifeste plus tard par des coupures intermittentes plutôt que par une erreur au démarrage. Le démon démarre, les clients se connectent, et seules certaines destinations se comportent mal. Gardez la plage alias petite pour que le pool soit facile à reconnaître dans une table de routage. Ne la taillez jamais dans un sous-réseau qu’une autre instance utilise déjà.

Donner un next hop au trafic de retour

Une réponse d’un hôte du VPC est adressée à une adresse client du pool de tunnel, qui n’appartient à aucun sous-réseau connu du VPC. Sans route pour ce pool, la réponse s’arrête au premier saut sans correspondance, et la requête a très bien pu réussir à l’autre bout.

gcloud compute routes create openvpn-return \
  --network=prod-vpc \
  --destination-range=192.168.127.0/24 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b \
  --priority=800

La même route est nécessaire pour tout préfixe qui se trouve derrière un client plutôt qu’à l’intérieur du VPC. Ces préfixes ont aussi besoin d’une entrée iroute dans le fichier ccd de ce client. Cette entrée est de la comptabilité côté serveur : elle indique au serveur quel client possède le préfixe, et elle n’installe rien sur le client lui-même.

Gardez la liste push pour le côté client de la conversation, car elle ne fait qu’ajouter des routes à la machine qui se connecte. Une ligne push pour un sous-réseau du VPC et une route VPC vers le pool sont les deux moitiés d’un même chemin, et chaque moitié seule produit un tunnel qui porte les requêtes mais pas les réponses.

Pare-feux, transmission et les sauts entre les deux

Le pare-feu du VPC évalue le paquet décapsulé, donc une règle d’entrée doit autoriser le pool de tunnel et tout préfixe de site qui atteint la VM par ce chemin. Une posture de refus par défaut échoue silencieusement ici : le paquet est jeté après décapsulation, et le journal OpenVPN affiche une session saine.

Sur tout hôte Linux qui transmet plutôt qu’il ne termine, vérifiez que net.ipv4.ip_forward est activé. La règle de propriété s’y applique aussi : une machine qui transmet pour un sous-réseau qu’elle ne détient pas jette le paquet comme le ferait la VM. Lisez la valeur avant d’accuser le tunnel.

Quand un seul préfixe échoue

La panne partielle est le cas le plus facile à lire, parce que tout le reste du chemin a déjà été prouvé. Commencez par la liste des routes et lisez la plage de destination et le next hop de l’entrée qui devrait couvrir le préfixe, puis lisez la description de l’instance et comparez sa plage alias au pool que le serveur distribue.

gcloud compute routes list --filter=destination-range~10.164.0.0
 gcloud compute instances describe openvpn-vm --format=get(networkInterfaces[0].aliasIpRanges)

Une route absente se manifeste par l’absence de next hop pour le préfixe, tandis qu’un alias absent se manifeste par un paquet jeté à l’interface ; du côté client les deux se ressemblent et dans ces deux sorties ils sont totalement différents. Si les deux sont présents, le suspect restant est l’iroute ccd du client qui revendique le préfixe.

Notez les quatre valeurs à côté du tunnel : plage alias, pool du serveur, préfixes poussés, routes VPC. Un alias périmé casse chaque adresse du pool, une route périmée casse un sens, un push manquant cache le préfixe au client, et un iroute erroné envoie le préfixe au mauvais pair. La prochaine personne qui ajoute un sous-réseau a besoin des quatre au même endroit, et la note coûte moins cher que la soirée.

Articles similaires