Faire tourner un VPN et un site web sur un seul hôte sans collisions

Partager un hôte entre un site public et un VPN vous fait hériter de deux questions, pas d’une : ce qui écoute où, et qui authentifie qui. Répondez aux deux avant de toucher à un fichier de configuration, car les valeurs par défaut sont fausses de manières qui n’apparaissent que sous charge. Une page qui se charge en HTTPS prouve que l’écouteur web répond et rien sur l’écouteur des pairs. Ce qui suit est un ordre de décisions qui empêche les deux de se dévorer.

Décidez ce qui écoute sur quelle adresse et quel transport

Écrivez un tableau à trois colonnes, adresse, transport et port, et une ligne par service, y compris l’interface d’administration. TCP 443 pour le site et UDP 443 pour le VPN ne sont pas un conflit même si les numéros correspondent, parce que le transport diffère. Deux services sur la même adresse, le même transport et le même port ont besoin d’un arrangement que la mise en œuvre documente, pas d’un que vous inventez pendant une panne. Ce tableau est aussi l’artefact qui rend le changement suivant vérifiable.

Des adresses séparées ou un second port rendent la propriété visible dans une capture de paquets, ce qui vaut mieux que l’élégance. Certaines mises en œuvre de VPN permettent de partager un port avec un serveur web, mais le mécanisme est spécifique : le démon inspecte les premiers octets et achemine le trafic qui n’est pas son propre protocole. Un proxy inverse HTTP générique ne fait pas cela, et réécrire les en-têtes ne le fera pas comprendre une poignée de main de tunnel chiffré. Lisez les notes de déploiement du protocole, comme la documentation de l’écouteur OpenVPN, et suivez l’arrangement qu’elle décrit.

Décidez quelle identité appartient à quel service

Un certificat de navigateur et un justificatif de pair VPN sont des objets différents avec des modèles de confiance différents. Le certificat web est validé par une autorité publique et nomme un nom d’hôte, tandis que le justificatif de pair authentifie un appareil ou un utilisateur auprès du concentrateur et peut être auto-signé ou émis en interne. Réutiliser l’un comme l’autre fonctionne dans des cas étroits et vaut rarement le couplage. Désactiver la vérification pour qu’un certificat partagé s’adapte n’est pas un plan de séparation ; cela supprime la vérification qui donnait son sens au justificatif.

Gardez les deux magasins indépendants et notez quelle autorité émet chacun. Quand l’un est renouvelé, l’autre ne devrait pas avoir besoin de changer, et s’il en a besoin, le couplage est ce qu’il faut corriger.

Décidez où vit l’administration

L’interface d’administration du VPN appartient à un chemin de gestion, jamais à l’écouteur public, même quand l’hôte sert déjà internet. Un serveur web sur 443 n’implique pas que la console des pairs doive être joignable de partout, et la console est généralement la cible de plus grande valeur. Liez-la à une adresse de bouclage ou de gestion, restreignez-la par source et gardez un chemin de récupération qui ne dépend pas du fait que le tunnel soit monté. Le chemin de récupération compte parce que la défaillance courante est de s’enfermer dehors en réparant le verrou.

Écrivez des règles de pare-feu étroites, une par écouteur, en nommant l’interface ou le compte de service là où la plateforme le permet. Les règles larges qui ouvrent l’hôte parce que le site a besoin de 443 sont la façon dont les interfaces d’administration finissent dans les index des scanners.

Revoyez ces règles par rapport au tableau des écouteurs chaque fois qu’un service est ajouté. La revue est bon marché et elle attrape la règle que quelqu’un a ajoutée à deux heures du matin.

Décidez quoi faire quand les deux se disputent

Partager un hôte signifie partager le processeur, la mémoire, les descripteurs de fichiers et la bande passante, et la ressource disputée n’est pas toujours l’évidente. Un site occupé peut remplir la table des connexions, épuiser les emplacements de travail ou pousser la file du disque assez fort pour que la journalisation du VPN cale. Regardez l’usage par service plutôt que les totaux de l’hôte, car une moyenne cache quel processus est affamé. Si une charge de travail perturbe régulièrement l’autre, isolez-les au lieu de régler autour du symptôme.

L’isolement peut être un conteneur, une limite de cgroup, une file séparée ou un second hôte, et le bon choix dépend de la ressource qui se dispute. Un changement de port ne corrige rien ici, et une instance plus grande ne corrige rien si la limite est une file saturée. Décidez avec une mesure : nommez la ressource, chargez-la, puis choisissez le plus petit isolement qui supprime la concurrence.

Vérifiez de l’extérieur, puis de nouveau après un redémarrage

Testez depuis un appareil qui n’est pas sur le réseau de l’hôte : chargez le site, montez le tunnel et atteignez une ressource qui l’exige. Redémarrez ensuite chaque service séparément et répétez l’autre test, car un redémarrage est le moment où un arrangement d’écouteur partagé perd son ordre. Si le VPN démarre avant le serveur web qui possède le port partagé, le mécanisme de partage peut ne jamais s’attacher, et le symptôme est un tunnel qui fonctionnait hier. Rendez la dépendance explicite dans l’ordre des unités.

Confirmez ensuite les frontières : le site répond sur son port, le VPN répond sur le sien, et l’interface d’administration répond uniquement depuis le chemin de gestion. Notez le résultat à côté du tableau des écouteurs avec la date. Un hôte qui passe les trois contrôles après un redémarrage est un hôte que vous pouvez remettre à quelqu’un d’autre sans briefing.