De strongSwan à AWS Site-to-Site : pourquoi la Child SA ne sélectionne rien

Un tunnel IKE peut être actif alors que l’association enfant exclut vos sous-réseaux. Comparez d’abord les CIDR local et distant d’AWS avec leftsubnet et rightsubnet.

La console indique up, strongSwan signale une association IKE établie, et les paquets n’arrivent toujours pas. La prochaine chose à comparer n’est pas la clé pré-partagée, mais la paire de préfixes que chaque côté croit protégée par le tunnel. Parcourez les vérifications ci-dessous dans l’ordre, car les deux premières décident si le tunnel peut seulement transporter votre trafic.

Traduisez les noms d’AWS en termes de strongSwan

AWS décrit la connexion côté client : l’adresse de la passerelle client et le CIDR local vous appartiennent, et le CIDR distant appartient au VPC. strongSwan nomme les deux extrémités left et right, avec votre préfixe dans leftsubnet et celui du VPC dans rightsubnet. Inverser une paire produit un tunnel qui négocie et sélectionne le mauvais trafic.

Téléchargez la configuration qu’AWS génère pour la connexion et traitez-la comme la référence de cette connexion précise, y compris les adresses de tunnel et les préfixes. Laisser les deux champs CIDR vides à la création fait utiliser par le service la valeur par défaut 0.0.0.0/0 de chaque côté. Un routeur configuré avec un préfixe étroit ne correspondra alors jamais, donc remplissez les champs ou élargissez le sélecteur délibérément.

Une incohérence ici ressemble à une panne de routage et n’en est pas une.

Figez l’adresse que AWS voit réellement

Un routeur derrière NAT peut émettre IKE depuis une interface que le côté distant n’a jamais connue. L’adresse de passerelle enregistrée dans AWS doit être celle qu’AWS observe sur le réseau, et le routeur doit être épinglé à la même adresse locale au lieu de suivre sa route par défaut.

conn %default
    local_addrs = 203.0.113.10

Dans strongSwan, local_addrs sélectionne l’adresse source pour IKE, et les anciennes configurations OpenSwan écrivent la même idée sous left. Pointez-la vers l’interface qui porte l’adresse publique, puis vérifiez sur l’équipement NAT lui-même que UDP 500 et 4500 atteignent cet hôte, car une règle laissée par un routeur précédent les rejette silencieusement. Une paire de sélecteurs correcte avec la mauvaise adresse source échoue quand même, et le journal accusera la proposition. Ce piège explique pourquoi l’adresse source mérite sa propre vérification.

Confirmez la règle de transfert au lieu de la supposer, car une règle qui était correcte pour le routeur précédent reste souvent en place.

Traitez la phase 1 et la phase 2 séparément

AWS expose les options IKE et ESP sous forme de listes distinctes. Une suite IKE que les deux côtés acceptent ne dit rien de la proposition ESP, car les deux listes sont indépendantes. Lisez les deux dans la configuration générée et comparez-les une par une.

conn aws
    ike = aes256-sha1-modp1024
    esp = aes256gcm16

La syntaxe ne circule pas entre implémentations. Une paire qui fonctionne sous OpenSwan, par exemple phase2alg=aes_gcm avec ike=aes256-sha1;modp1024, doit être traduite dans la forme esp= et ike= de strongSwan, et les noms d’algorithmes diffèrent. Comme GCM authentifie en chiffrant, il n’a pas besoin d’une transformation d’intégrité séparée, contrairement à une suite CBC associée à SHA. Une ligne de phase 2 copiée d’un démon à l’autre sans traduction produit un rejet qui se lit comme une incohérence de sélecteurs.

Vérifiez l’association enfant, pas l’indicateur du tunnel

Si la connexion se charge mais qu’aucune association enfant n’apparaît, c’est la proposition ou les sélecteurs qui ont été refusés. Si un enfant apparaît et que ses sélecteurs excluent vos préfixes, les paquets sont filtrés avant d’atteindre le tunnel. L’indicateur de la console ne couvre que le niveau IKE, il ne peut donc pas vous dire lequel des deux s’est produit.

ipsec statusall

Cherchez l’association de sécurité enfant et lisez les sélecteurs de trafic imprimés à côté, puis comparez-les aux préfixes de la configuration générée.

Testez depuis un hôte du préfixe local vers un hôte du préfixe du VPC, et vérifiez le chemin de retour ainsi que tout groupe de sécurité ou ACL réseau côté AWS. Des sélecteurs corrects n’empêchent pas un paquet d’être rejeté plus tard.

Quand cela échoue encore une fois les sélecteurs concordants

Confirmez que la route des deux côtés pointe vers le tunnel, puis confirmez que l’équipement NAT ne réécrit pas le trafic d’une manière que la politique n’attend pas. Un tunnel basé sur une politique compare les adresses des paquets, donc une traduction appliquée après la décision de politique change le résultat.

Journalisez un paquet entrant et un paquet sortant de chaque côté avant de modifier une autre proposition.

Notez les sélecteurs, les propositions de phase 1 et de phase 2 et l’adresse source dans le ticket. Ces quatre valeurs expliquent la plupart des échecs site-to-site sans appel.

Articles similaires