VM GCP à plusieurs NIC : pourquoi les réponses sortent par la mauvaise interface

Attacher une seconde interface à une VM Compute Engine lui donne un autre rattachement réseau, pas un chemin de retour symétrique. L’invité choisit toujours une interface et une adresse source à partir de ses propres routes et règles. Google Cloud applique ensuite le routage VPC et la politique de pare-feu autour de l’interface par laquelle le paquet est sorti. Quand ces deux décisions ne concordent pas, les requêtes arrivent par une NIC et les réponses sortent par l’autre, et la branche voit une conversation à moitié ouverte.

Parcourez le chemin en cinq étapes et la divergence apparaîtra avant que vous n’écriviez une règle de politique.

Étape 1 : associez les NIC du cloud aux périphériques de l’invité

Le cloud nomme les interfaces nic0, nic1 et ainsi de suite, et l’invité voit des noms de périphériques qui n’ont pas à correspondre. Résolvez la correspondance à partir des métadonnées de l’instance ou de l’adresse propre de l’interface avant toute autre chose. La route par défaut ordinaire fournie par DHCP est associée à nic0, ce qui explique pourquoi le chemin vers internet l’emporte si souvent par accident. Écrire une politique contre un nom de périphérique supposé est la façon dont une règle correcte atterrit sur la mauvaise interface.

Notez les adresses, les noms de périphériques et le VPC auquel chacun appartient. Cette table à trois colonnes est l’entrée de chaque étape suivante.

Étape 2 : nommez les deux décisions de routage

La première décision appartient à l’invité : quelle interface et quelle adresse source pour ce paquet. La seconde appartient au cloud : ce que les routes du VPC et la politique de pare-feu permettent autour de cette interface.

Une route visible dans le VPC orienté VPN ne devient pas une route de l’invité qui sélectionne cette NIC. La route du cloud décrit ce que le réseau peut livrer, tandis que la route de l’invité décide ce que fait le paquet.

Étape 3 : choisissez une politique de chemin de retour

Pour un ensemble petit et stable de préfixes de branche, les routes de destination explicites dans l’invité sont l’expression la plus simple : les réponses vers ces préfixes sortent par l’interface orientée VPN. Quand plusieurs services utilisent volontairement des adresses source locales différentes, les règles basées sur la source qui choisissent une table par interface gardent chaque réponse dans le bon contexte. La documentation sur les interfaces multiples décrit le nommage des NIC et le comportement de la route par défaut sur lesquels ces conceptions s’appuient.

Chaque table a besoin de routes connectées valides et de sauts suivants, plus des destinations qui lui seront demandées. Une règle pointant vers une table incomplète n’est pas une conception de chemin de retour. Utilisez la passerelle documentée pour cette NIC au lieu d’inventer une passerelle Ethernet à partir de l’apparence du sous-réseau.

Étape 4 : vérifiez les filtres propres à l’invité

Vérifiez où le serveur écoute et quelle source locale la réponse porte. Un écouteur générique ne passe pas outre la politique de routage, donc se lier à toutes les adresses ne change rien à l’interface par laquelle la réponse sort.

Sous Linux, examinez la validation du chemin inverse par rapport à la conception prévue. La désactiver globalement comme premier geste échange un bogue de routage contre une exposition à l’usurpation, et masque l’asymétrie que vous cherchiez à trouver.

Étape 5 : testez un flux par chemin

Vérifiez séparément une requête de branche autorisée et une requête internet sans rapport, chacune avec sa source et sa destination réelles. Capturez sur les deux interfaces quand vous le pouvez, car la preuve utile est quelle interface a transporté la réponse. Confirmez ensuite que la politique côté cloud a respecté le chemin que vous avez conçu. Une requête réussie prouve un flux, pas une conception symétrique.

Gardez les deux tests séparés dans vos notes, car ils empruntent des routes différentes et des règles de pare-feu différentes.

Ce qu’une seconde NIC ne vous donne pas

Une seconde interface ajoute un rattachement réseau et une autre adresse. Elle n’ajoute pas de routage symétrique automatique et ne contourne pas la politique de pare-feu. La traiter comme un correctif de routage est la raison pour laquelle les conceptions multi-NIC accumulent des règles que personne ne peut expliquer plus tard.

Si la VM doit transférer le trafic d’autres machines, planifiez ce rôle de routeur explicitement, y compris le réglage cloud qui autorise le transfert et les filtres de l’invité qui l’accompagnent.