IP fixe sans BGP : exposer son serveur personnel avec un tunnel noBGP

Beaucoup de fournisseurs d'accès grand public (fibre comme 4G/5G box) ne permettent ni IP fixe, ni reverse DNS personnalisé, ni parfois même une vraie IP publique (CGNAT). Pour un serveur mail auto-hébergé, c'est bloquant : sans reverse DNS cohérent avec le nom de domaine d'envoi, la plupart des serveurs destinataires rejettent ou classent en spam les messages sortants (vérifications SPF/PTR). La solution classique — louer un bloc d'IP et monter une session BGP — est disproportionnée pour un usage personnel ou une petite structure. Les services de tunnel type noBGP comblent exactement ce manque.

1. Le principe

Un tunnel noBGP est un tunnel VPN (PPTP ou L2TP selon le fournisseur) sur lequel une ou plusieurs IPv4/IPv6 publiques fixes sont routées directement, sans que vous ayez à gérer la moindre session de routage BGP. Concrètement :

• Vous souscrivez une IP fixe avec reverse DNS configurable auprès du fournisseur du tunnel.
• Votre routeur/pare-feu établit un tunnel L2TP ou PPTP permanent vers leur infrastructure.
• Le trafic sortant du service concerné (typiquement juste votre serveur mail, pas tout votre réseau) est routé sélectivement à travers ce tunnel plutôt que par votre box FAI.
• Les mails sortants portent alors cette IP fixe, dont le reverse DNS pointe vers votre nom de domaine — condition de base pour ne pas être filtré par SPF/PTR côté destinataire.

2. Configuration côté pare-feu (principe général)

La configuration exacte dépend de votre pare-feu (pfSense/OPNsense, Mikrotik, ou un simple client L2TP Linux), mais la logique reste la même partout :

1. Interface PPP/L2TP : créer une interface de tunnel avec les identifiants fournis par le service noBGP, en laissant le "Shared Secret" vide si le chiffrement est désactivé côté fournisseur (choix fréquent pour privilégier la performance sur un tunnel déjà authentifié).
2. MTU : ajuster à 1450 (voire MSS à 1410 en IPv4) pour éviter la fragmentation, symptôme classique de connexions qui "trainent" sans erreur explicite.
3. Routage sélectif (policy routing) : ne faire passer par le tunnel que le trafic de la machine concernée (le serveur mail), pas tout le réseau — la passerelle par défaut du reste du réseau reste votre connexion FAI habituelle.
4. NAT sortant et port forward entrant : NAT en adresse du tunnel pour le trafic sortant du serveur mail ; port forward des ports mail (25, 465, 587, 993...) si vous avez aussi besoin de recevoir du trafic entrant sur cette IP.

3. Vérifier que ça fonctionne

Envoyez un email de test vers une adresse externe et inspectez les en-têtes reçus :

# Vérifier le reverse DNS de l'IP du tunnel
$ python3 -c "import socket; print(socket.gethostbyaddr('VOTRE_IP_TUNNEL'))"

# Dans les en-têtes du mail reçu, chercher :
# - SPF: pass
# - IP source = l'IP du tunnel, pas celle de votre box FAI

4. Un contrainte à connaître

La plupart des offres noBGP exigent qu'un seul tunnel actif à la fois utilise les mêmes identifiants, et que toutes les connexions proviennent du même équipement. Si vous changez de routeur (migration de matériel, par exemple), attendez-vous à un délai de quelques minutes avant que le nouveau tunnel s'établisse : une session "fantôme" peut rester active côté fournisseur le temps que son propre timeout expire.

Pensez à corriger le DKIM en parallèle du reverse DNS : un enregistrement TXT DNS mal nommé (le sélecteur DKIM doit correspondre exactement au domaine d'envoi signé, sous-domaine inclus) provoque un dkim=permerror même quand SPF et le reverse DNS sont corrects.

Conclusion

Un tunnel noBGP est une solution pragmatique pour quiconque veut faire tourner un serveur mail ou tout autre service nécessitant une IP fixe et un reverse DNS propre, sans les contraintes (ni le coût) d'un vrai déploiement BGP. Le point le plus délicat reste le monitoring de la gateway côté pare-feu — une fois ce piège identifié, le tunnel tourne sans intervention pendant des mois.