Le contrôle source/destination est une porte, pas tout le chemin VPN
Une instance de transfert a besoin d'une autorisation AWS, mais aussi de routes Linux et de règles de pare-feu. Vérifiez la validation source/destination sur l'instance qui transfère.
Le VPN se termine sur une instance EC2, vous pouvez joindre l'adresse de tunnel de cette instance, et le trafic censé la traverser vers un autre hôte privé disparaît. Ce sont deux tests différents, et les mélanger fait perdre des heures. Le premier demande si vous pouvez joindre l'instance ; le second lui demande de transférer du trafic vers une destination qui n'est pas la sienne, ce qui exige le transfert Linux, une politique de pare-feu, une route de l'autre côté et une autorisation au niveau d'AWS sans aucun rapport avec le système d'exploitation invité. Rien dans la console n'attire l'attention sur cette différence. Le symptôme ressemble à une panne de routage, et ce n'est généralement pas le cas.
Séparez les deux tests avant de changer quoi que ce soit
Atteindre la passerelle prouve le tunnel, la route vers son adresse et le groupe de sécurité qui autorise l'échange. Le transfert pour un autre hôte ne prouve rien de tout cela : il sollicite une autre adresse source, une autre destination et une instance dans un rôle pour lequel elle n'a pas forcément été conçue. Écrivez les deux tests séparément et notez lequel échoue, car la correction de chacun se trouve dans une console différente. Une instance de passerelle conçue uniquement pour terminer des tunnels n'a aucune raison de transférer pour autre chose, et ses valeurs par défaut le reflètent. C'est pourquoi le second test exige sa propre configuration plutôt qu'un petit ajustement du premier.
Un ping qui fonctionne vers la passerelle et un ping qui échoue vers l'hôte au-delà ne constituent pas un problème intermittent. C'est le comportement attendu d'une instance à laquelle on n'a pas dit qu'elle pouvait transférer.
Écrivez le chemin avant de toucher à un réglage
Notez le préfixe du client, l'instance ou l'interface réseau de transfert, le sous-réseau cible et la route de retour. Une entrée de la table de routage du VPC pointant vers une instance ne configure pas le système d'exploitation de l'instance pour transférer, et un noyau invité avec le transfert activé ne crée pas de route VPC. Les deux extrémités de cette relation doivent exister, et elles sont modifiées à des endroits différents par des personnes ayant des accès différents.
Examinez ensuite le réglage de contrôle source/destination sur le composant de transfert réel, et non sur chaque instance du VPC. AWS documente pourquoi une instance qui transfère du trafic pour d'autres doit avoir ce contrôle désactivé, et aussi pourquoi le réglage est une décision par instance et non une valeur par défaut pour tout le VPC.
Quatre frontières, et le contrôle n'en est qu'une
Traitez le chemin comme quatre questions et répondez-y dans l'ordre. La première réponse qui échoue indique où se trouve le travail, et aucune des autres ne la compensera.
| Boundary | Question it answers |
|---|---|
| VPC route tables | Do the destinations and replies select the intended gateway? |
| Forwarding instance | Do the AWS check and the guest OS both permit forwarding? |
| Access policy | Do security groups, ACLs and host rules allow the exchange? |
| Destination | Can the service accept that source and return a reply? |
L'ordre compte parce que la vérification est peu coûteuse : les routes tiennent sur une page, le contrôle est un seul attribut, et l'avis de la destination est généralement la dernière chose que l'on demande.
La traduction change la source que voit la destination
Une conception routée préserve l'adresse source du client, la destination a donc besoin d'une route de retour vers le préfixe du client. Une conception traduite présente plutôt l'adresse de la passerelle, ce qui supprime cette exigence et la remplace par une table d'états sur la passerelle. Décidez selon l'architecture visée, au lieu d'ajouter de la traduction parce qu'un exemple sans rapport l'a utilisée et semblait fonctionner.
Si vous traduisez, limitez la règle au préfixe du client et à la destination prévue. Si vous préservez, confirmez que l'autre côté connaît réellement la route au lieu de supposer qu'il en apprendra une.
Testez depuis le client d'origine, puis conservez la modification
Une requête générée sur la passerelle peut réussir alors qu'une requête transférée échoue, car il s'agit d'une autre source et d'un autre cas de transfert. Après une correction ciblée, répétez le test exact client-vers-ressource qui a échoué, depuis le même client, et confirmez que la réponse revient, et pas seulement que la requête est arrivée.
Enfin, placez le réglage dans la configuration gérée de la passerelle pour qu'une instance de remplacement le reçoive. Un test réussi qui dépend d'une exception manuelle est un test qui expire à la prochaine reconstruction, et la personne qui l'a découvert ne sera pas là pour se rappeler pourquoi.