Quelle adresse mettre dans le DNS pour un serveur connecté par VPN ?
Un serveur hébergé détient trois adresses et elles ne sont pas interchangeables. Choisissez la valeur dont chaque service a besoin, puis confirmez-la depuis l’extérieur de la machine.
Un serveur hébergé avec un VPN installé finit par détenir trois adresses, et une seule d’entre elles a sa place à chaque endroit que vous vous apprêtez à configurer. Copier le numéro d’un tableau de bord de fournisseur dans le DNS, dans un écouteur ou dans une liste d’autorisations, c’est ainsi qu’un tunnel qui fonctionnait devient un service que personne ne peut joindre. Ce guide ordonne le travail pour que chaque adresse soit choisie pour un usage énoncé. Il liste aussi les commandes qui confirment ce que vous avez réellement publié.
Cartographiez les trois adresses avant de publier quoi que ce soit
Nommez-les par fonction. L’adresse de sous-couche est celle que la machine utilise pour joindre le point de terminaison VPN sur internet, et elle est souvent privée derrière le NAT du fournisseur. L’adresse de tunnel vit à l’intérieur du VPN, attribuée par le serveur ou par le client selon le produit. La sortie publique est l’adresse qu’un site distant enregistre après la traduction, et elle n’a pas besoin d’exister sur une interface que vous pouvez interroger.
Un tableau de bord qui affiche une seule adresse publique pour une machine vous dit très peu de chose sur les deux autres rôles. La joignabilité de la sous-couche est une exigence, pas un achat : un ordinateur portable derrière un routeur domestique peut joindre un point de terminaison VPN hébergé sans posséder d’adresse IPv4 publique. Ce que vous ne pouvez pas faire, c’est inventer un chemin entrant en écrivant un nom qui résout vers une adresse que personne ne redirige.
Choisissez l’adresse d’après le service, pas d’après l’étiquette
Notez ce que le serveur doit faire avant de choisir un numéro. Les appels d’API sortants ont besoin d’une sortie stable quand la partie distante tient une liste d’autorisations. L’accès privé a besoin d’une adresse de tunnel vers laquelle les clients peuvent router et d’un écouteur lié à celle-ci. L’hébergement public a besoin d’une correspondance entrante que le fournisseur propose réellement, et l’adresse de sortie seule ne la fournit pas.
Une seule machine peut servir les trois usages et utiliser malgré tout trois adresses différentes. Ce qui casse, c’est l’hypothèse qu’une valeur les couvre toutes :
| Requirement | Value that belongs there | What you see when the roles are swapped |
|---|---|---|
| Outbound allowlisting | Public exit | Requests reach the service but are rejected |
| Private client access | Tunnel address | Client connects, nothing answers |
| Inbound web service | Provider mapping | Name resolves, connection times out |
La ligne entrante est celle dont les gens discutent. Un enregistrement qui pointe vers l’adresse de sortie ne crée ni écouteur, ni ouverture de pare-feu, ni redirection de port, et attendre n’y change rien. Quand le fournisseur vend une adresse dédiée avec une règle entrante, ce lot est la capacité que vous avez achetée ; l’adresse seule n’est pas le droit.
Des commandes qui montrent quelle adresse est laquelle
Lisez la machine, pas le tableau de bord. Les noms d’interface diffèrent selon les systèmes, alors associez les adresses aux périphériques au lieu de faire confiance à une étiquette.
La première ligne liste chaque adresse IPv4 et son périphérique, et la seconde demande au noyau quel périphérique il utiliserait pour une destination extérieure connue :
ip -brief -4 addr show
ip -4 route get 198.51.100.10
curl -4 -s https://ifconfig.me
ss -lntp | grep -E ':(443|1194)'Si la recherche de route répond avec un périphérique de tunnel pour le trafic public, votre tunnel complet est en vigueur. La vérification de l’écouteur compte autant, car un processus lié seulement à 127.0.0.1 ne répondra jamais sur l’adresse de tunnel, quel que soit le nom que vous publiez.
Publiez-la, puis vérifiez depuis l’extérieur
Publiez la valeur dont le service a besoin et rien de plus : un enregistrement A ou AAAA pour l’hébergement, une entrée de liste d’autorisations pour les appels sortants, un profil client pour l’accès privé. Testez ensuite depuis la position qui compte, et ce n’est jamais la machine que vous venez de modifier.
Deux vérifications couvrent l’essentiel, et toutes deux sont assez bon marché pour rester dans un script :
dig +short vpn.example.net A
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/healthUne réponse DNS qui prouve que votre enregistrement existe n’est pas la preuve qu’une requête arrive, et une requête réussie prouve seulement qu’un chemin fonctionne depuis un réseau. Répétez la vérification depuis une connexion mobile quand une liste d’autorisations est en jeu, car la sortie que vous observez peut dépendre de la famille d’adresses et de la route suivie. Notez quelle famille vous avez vérifiée ; un chemin IPv4 fonctionnel ne dit absolument rien d’IPv6.
Si le service est entrant, l’adresse de sortie ne suffit pas
L’accès entrant exige quatre choses alignées : un nom ou une adresse qu’un client peut joindre, une route qui livre le paquet à la machine, un écouteur qui l’accepte et une politique qui ne le rejette pas. Un VPN change le deuxième élément et parfois le premier, et il ne fait rien pour le troisième et le quatrième. Quand le tunnel est le chemin de livraison, les clients se connectent à l’adresse de tunnel, pas à la sortie.
Consignez de quelle adresse chaque service dépend, puis revoyez cette note chaque fois que le fournisseur change son modèle de routage. Un serveur qui répond en privé et échoue en public n’est généralement pas cassé ; il répond sous la mauvaise identité, et la réparation est une décision de correspondance plutôt qu’un changement de pare-feu.