Site NGINX réservé au VPN : listener, pare-feu et liste d'autorisation HTTP

Un site NGINX privé a besoin d'un socket VPN lié, d'une règle d'entrée d'hôte limitée et d'une liste d'accès HTTP intacte. Testez les trois, pas un seul bloc serveur.

Trois décisions indépendantes séparent un site privé d'Internet : quel socket accepte la connexion, quel chemin peut la livrer et à quels clients HTTP le serveur choisi répond. Un bloc serveur ne prend que la première décision. Traitez les deux autres comme des contrôles distincts, sinon le site paraîtra privé alors qu'une ancienne entrée reste ouverte. La plupart des pannes NGINX réservées au VPN viennent du fait de ne tester que la première couche.

L'exemple utilise une passerelle Linux OpenVPN à 10.90.0.1 sur tun0, des clients dans 10.90.0.0/24, des sources préservées et TCP 8443 réservé à cette entrée. Ajustez les valeurs, gardez les couches.

Commencez par le socket, pas par le nom d'hôte

Liez le listener HTTPS à l'adresse du tunnel et à un port dédié. Une adresse précise est plus facile à raisonner qu'un socket générique plus une vérification de nom, car le noyau ne cédera pas le port à une autre adresse locale.

server {
    listen 10.90.0.1:8443 ssl;
    server_name admin.corp.example;

    ssl_certificate     /etc/nginx/tls/admin-fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/admin-key.pem;

    root /srv/private-site;

    allow 10.90.0.0/24;
    deny all;

    location / {
        try_files $uri $uri/ =404;
    }
}

Le certificat doit nommer l'hôte du service que les clients saisissent, et la vue DNS privée doit résoudre cet hôte vers l'adresse liée. server_name ne choisit qu'un hôte virtuel ; il n'authentifie personne. Une entrée DNS absente produit une erreur de certificat qui ressemble à une panne TLS. Vérifiez le nom avant de remplacer le certificat.

Lisez la configuration effective avant d'ajouter le fichier. Les inclusions et les listeners génériques peuvent servir la même racine ailleurs, et un serveur par défaut peut répondre à des requêtes que le nouveau bloc ne voit jamais.

Fermez tous les autres listeners pour ce contenu

Listez les directives listen et comparez les racines qu'elles servent. Un bloc ajouté pour une autre application peut faire proxy vers le même upstream, et un ancien serveur par défaut peut continuer à répondre une fois le nouveau en place. Cette sortie est l'inventaire réel, pas le fichier que vous venez de modifier. Comparez chaque racine qui sert le même contenu.

sudo nginx -T | grep -n "listen\|server_name\|root\|proxy_pass"

Vérifiez les deux familles d'adresses. Une liaison IPv4 laisse un socket IPv6 intact, et un nouvel enregistrement A ne retire pas une ancienne réponse AAAA qui pointe encore vers un chemin public.

Retirez l'ancien hôte virtuel comme un changement distinct. Supprimer le jumeau public du nouveau bloc est généralement l'étape qui ferme réellement l'entrée ; le listener privé n'ajoute que celle prévue.

Limitez le chemin entrant sur l'hôte

L'adresse d'écoute limite le socket, pas l'interface d'entrée. Un paquet routé vers cette adresse depuis ailleurs arrive quand même en entrée locale, c'est pourquoi le pare-feu de l'hôte a besoin de sa propre déclaration sur l'origine autorisée de la connexion. C'est pourquoi une simple liaison satisfait rarement un audit.

Avec une politique d'entrée refusée par défaut et sans autorisation plus large pour ce service, une règle limitée nomme ensemble le tunnel, la plage source, la destination et le port :

sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 8443

Lisez l'ordre effectif du pare-feu avant de l'appliquer. Une acceptation large antérieure peut annuler la restriction, et un rejet terminal antérieur peut empêcher cette autorisation d'être atteinte. Ne videz pas de règles sans rapport et ne désactivez pas le pare-feu pour faire coller l'exemple.

Cette règle est une entrée d'hôte, pas une route vers une autre machine du LAN, et le listener OpenVPN externe de la passerelle reste un service distinct. Si le site était public auparavant, planifiez comment l'ancienne entrée est retirée et comment les sessions existantes sont traitées.

Gardez la liste HTTP intacte quand les emplacements changent

NGINX évalue les entrées allow et deny dans l'ordre, et la liste au niveau serveur ci-dessus admet l'ensemble déclaré avant le deny final. Le module d'accès enregistre aussi qu'un emplacement définissant une entrée d'accès utilise sa propre liste plutôt que la liste parente. L'ordre compte autant que les entrées elles-mêmes.

Cette réinitialisation est la régression habituelle. Un nouvel emplacement d'envoi, d'API ou de santé qui ajoute une entrée remplace silencieusement la restriction au niveau serveur, et le site s'élargit sur le chemin ajouté le plus récemment.

Passez en revue chaque emplacement, alias et bloc alternatif dans le cadre de la même politique. Si les contrôles IP sont combinés à l'authentification NGINX, comprenez satisfy : un réglage any peut admettre un client par un mécanisme alors que l'autre n'a pas réussi. Mettez la liste d'accès dans la liste de vérification des emplacements.

Un refus HTTP intervient après que la connexion TCP a atteint NGINX. Il complète la restriction réseau, et l'autorisation propre à l'application s'applique toujours à chaque utilisateur.

Vérifiez le chemin actif et le cas d'échec

Lancez l'analyseur de configuration, inspectez les sockets en écoute, puis faites une nouvelle requête nommée depuis un client prévu. Confirmez que le certificat valide, que le nom DNS résout vers l'adresse liée et que la réponse vient de la racine attendue.

Testez ensuite une source exclue et une entrée alternative. Une requête autorisée qui fonctionne ne dit rien des chemins que vous vouliez fermer, et c'est dans le test exclu qu'apparaît un listener résiduel ou une acceptation large du pare-feu.

Répétez le cas de démarrage ou de récupération VPN. Si NGINX démarre avant que l'adresse du tunnel existe, la liaison peut échouer même avec un fichier parfait. Coordonnez la disponibilité de l'adresse et gardez un chemin de récupération local avant de modifier un serveur web partagé.

Notez le socket, le port, la plage source et la liste HTTP qui ont fonctionné. Le prochain changement VPN ou DNS peut déplacer l'un d'eux, et quatre valeurs nommées sont plus faciles à comparer qu'un onglet de navigateur qui marche.

Articles similaires