Deux reverse proxies peuvent-ils partager les ports 80 et 443 sur un même serveur domestique ?

Pas sur la même adresse IP et le même protocole en même temps, sauf si un proxy est la porte d'entrée unique et transmet le trafic sélectionné à l'autre, ou si chacun se lie à une adresse IP différente.

Cela devient une véritable question de compatibilité lorsque deux conteneurs proxy publient tous deux les ports hôtes 80 et 443 pour des piles d'applications distinctes sur une même machine. Commencez par un chemin ou un compte jetable, conservez l'ancien état fonctionnel, et évaluez la conception à partir de la charge de travail d'origine plutôt qu'avec un test de connexion ponctuel.

Identifiez le propriétaire de la ressource partagée

La branche prise en charge est celle d'un seul écouteur par paire adresse IP-port, avec le routage effectué derrière celui-ci. La branche concurrente est celle de deux écouteurs indépendants qui se disputent le même socket. Notez les versions, les identités, les adresses, les chemins de montage, les permissions et l'état observable actuel avant de modifier l'une ou l'autre branche.

Les règles de liaison des sockets pertinentes définissent la première limite de compatibilité. Utilisez-les pour encadrer l'affirmation, puis vérifiez le même comportement sur ce serveur domestique précis au lieu de considérer une fonctionnalité documentée comme la preuve que toute la conception fonctionne.

Écrivez la règle de décision avant le test : la réussite doit produire uniquement la situation où le proxy frontal prévu possède chaque socket public et où chaque nom d'hôte atteint le serveur en amont approprié avec le certificat attendu ; l'échec inclut un message de démarrage indiquant que l'adresse est déjà utilisée, un trafic qui atteint le mauvais proxy ou une terminaison TLS avec le certificat d'un autre site. Cela empêche de prendre une connexion partielle ou une sortie de commande normale pour une compatibilité de bout en bout.

Ne modifiez qu'un écouteur ou une route à la fois

Utilisez un seul élément discriminant contrôlé : répertoriez les écouteurs actuels, liez chaque proxy à une adresse IP de test distincte ou placez-en un derrière l'autre, puis testez le routage par Host, SNI, WebSocket et certificat. Gardez le client, la charge de travail, l'ensemble de fichiers, le compte et le calendrier constants afin que le composant modifié soit la seule explication plausible.

Utilisez le comportement des ports publiés pour choisir la seconde observation importante pour ce chemin. Capturez les deux côtés de la transaction : résolveur ou route, protocole négocié, identité du processus, état de sortie, latence, octets transférés et tout événement de récupération.

Répétez le test après l'événement du cycle de vie mentionné dans le titre - recréation, reconnexion, remontage, redémarrage, basculement ou changement de client. Une conception qui ne fonctionne que tant que d'anciens sockets, caches ou identifiants restent actifs n'a pas réussi.

ss -ltnp '( sport = :80 or sport = :443 )'
docker ps --format '{{.Names}} {{.Ports}}'

Utilisez des preuves de routage observables pour décider

RÉUSSITE : seul le proxy frontal prévu possède chaque socket public et chaque nom d'hôte atteint le serveur en amont approprié avec le certificat attendu. Enregistrez les versions exactes et la topologie qui ont produit cet état, car la conclusion s'applique à ces conditions et non à toutes les implémentations du protocole.

ÉCHEC : le démarrage indique que l'adresse est déjà utilisée, le trafic atteint le mauvais proxy ou TLS se termine avec le certificat d'un autre site. Vérifiez les dépendances partagées telles que le DNS, la MTU, l'identité, l'état du pare-feu, la latence du stockage et les sessions mises en cache avant d'attribuer la responsabilité à l'une ou l'autre branche principale.

EXCEPTION : arrêtez la seconde liaison publique, restaurez le dernier écouteur fonctionnel et choisissez une seule porte d'entrée ou des adresses hôtes distinctes. N'élargissez pas les privilèges, ne supprimez pas les données sources, n'affaiblissez pas la sécurité du transport et ne remplacez pas le stockage fonctionnel avant qu'une observation reproductible n'identifie la limite qui a échoué.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Revérifiez l'isolation avant le retour du trafic de production

Appliquez uniquement l'action correspondant à la branche observée, puis relancez la charge de travail d'origine. Ne conservez la conception que lorsque seul le proxy frontal prévu possède chaque socket public et que chaque nom d'hôte atteint le serveur en amont approprié avec le certificat attendu pendant deux cycles de vie pertinents et sous la charge simultanée attendue.

Utilisez les réseaux proxy dédiés pour vérifier le flux de travail dépendant le plus proche. Son comportement en matière d'accès, de temps et de récupération doit rester inchangé pendant l'activation de la nouvelle conception.

Arrêtez-vous et revenez à l'état enregistré si le démarrage indique que l'adresse est déjà utilisée, si le trafic atteint le mauvais proxy ou si TLS se termine avec le certificat d'un autre site. Faites remonter le problème avec les horodatages, les versions exactes, les éléments de preuve liés aux routes ou aux montages et la reproduction la plus réduite possible, plutôt que d'ajouter une autre solution de contournement.

Comparez le résultat aux surcharges DNS des proxys inverses afin que le risque ne soit pas simplement déplacé vers une autre couche réseau, d'identité, de sauvegarde ou de stockage.

Pour la possession des ports par deux proxys inverses, la réponse nuancée est donc le jugement d'ouverture - et non un oui inconditionnel. L'état observable de réussite constitue la ligne d'acceptation ; l'état d'échec constitue la ligne de retour arrière.

FAQ

SO_REUSEPORT permet-il à des proxys indépendants de partager le port 443 ?

Ce n'est pas une conception sûre pour le routage par nom d'hôte entre des proxys indépendants ; utilisez une seule porte d'entrée TLS ou des adresses IP distinctes.

Un proxy peut-il transmettre TLS au second ?

Oui, lorsque le routage repose sur SNI et que le proxy en aval prend en charge la terminaison du certificat pour ce nom d'hôte.

Les écouteurs IPv4 et IPv6 sont-ils en conflit ?

Ils peuvent l'être, selon le comportement des sockets à double pile et les adresses de liaison ; inspectez explicitement les deux familles de protocoles.