Kan två reverse proxy-servrar dela portarna 80 och 443 på en hemmaserver?

Inte på samma IP och protokoll samtidigt, såvida inte en proxy är den enda ingången och vidarebefordrar utvald trafik till den andra, eller så binder varje proxy till en annan IP-adress.

Detta blir en verklig kompatibilitetsfråga när två proxycontainrar publicerar värdportarna 80 och 443 för separata appstackar på samma maskin. Börja med en tillfällig sökväg eller ett testkonto, behåll det tidigare fungerande tillståndet tillgängligt och bedöm designen utifrån den ursprungliga arbetsbelastningen snarare än ett anslutningstest som körts en enda gång.

Identifiera vem som äger den delade resursen

Den stödda grenen är en lyssnare per IP-port-par med routning bakom den. Den konkurrerande grenen är två oberoende lyssnare som konkurrerar om samma socket. Dokumentera versioner, identiteter, adresser, monteringssökvägar, behörigheter och det aktuella observerbara tillståndet innan du ändrar någon av grenarna.

De relevanta reglerna för socketbindning definierar den första kompatibilitetsgränsen. Använd dem för att begränsa påståendet och verifiera sedan samma beteende på just den här hemmaservern, i stället för att behandla en dokumenterad funktion som bevis på att hela designen fungerar.

Skriv beslutsregeln innan testningen: godkänt resultat innebär att endast den avsedda frontproxyn äger varje offentlig socket och att varje värdnamn når rätt upstream med det förväntade certifikatet; underkänt resultat omfattar att starten rapporterar att adressen redan används, att trafiken når fel proxy eller att TLS avslutas med certifikatet från en annan webbplats. Detta förhindrar att en partiell anslutning eller ett rent kommandoavslut misstolkas som kompatibilitet från början till slut.

Ändra en lyssnare eller rutt i taget

Använd en kontrollerad särskiljande faktor: lista aktuella lyssnare, bind varje proxy till en separat test-IP eller placera den ena bakom den andra och testa routning för Host, SNI, WebSocket och certifikat. Håll klient, arbetsbelastning, filuppsättning, konto och tidsförlopp konstanta så att den ändrade komponenten är den enda rimliga förklaringen.

Använd beteendet för publicerade portar för att välja den andra observation som är viktig för denna sökväg. Fånga båda sidorna av transaktionen: resolver eller rutt, förhandlat protokoll, processidentitet, avslutningsstatus, fördröjning, överförda byte och eventuella återställningshändelser.

Upprepa testet efter den livscykelhändelse som anges i titeln - återskapande, återanslutning, ommontering, omstart, redundansväxling eller klientbyte. En design som bara fungerar medan gamla sockets, cacheminnen eller autentiseringsuppgifter fortfarande är aktiva har inte klarat testet.

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

Använd observerbara bevis från routningen för att fatta beslut

GODKÄNT: endast den avsedda frontproxyn äger varje offentlig socket och varje värdnamn når rätt upstream med det förväntade certifikatet. Spara de exakta versionerna och den topologi som skapade detta tillstånd, eftersom slutsatsen gäller dessa förhållanden och inte varje implementation av protokollet.

UNDERKÄNT: starten rapporterar att adressen redan används, trafiken når fel proxy eller TLS avslutas med certifikatet från en annan webbplats. Kontrollera delade beroenden som DNS, MTU, identitet, brandväggstillstånd, lagringsfördröjning och cachade sessioner innan du förklarar någon av huvudgrenarna som ansvarig.

UNDANTAG: stoppa den andra offentliga bindningen, återställ den senast fungerande lyssnaren och välj en enda ingång eller separata värdadresser. Utöka inte behörigheter, radera inte källdata, försvaga inte transportsäkerheten och byt inte ut fungerande lagring förrän en upprepningsbar observation identifierar vilken gräns som fallerade.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Kontrollera isoleringen igen innan produktiv trafik återupptas

Tillämpa endast den åtgärd som motsvarar den observerade grenen och kör sedan den ursprungliga arbetsbelastningen igen. Behåll designen endast när endast den avsedda frontproxyn äger varje offentlig socket och varje värdnamn når rätt upstream med det förväntade certifikatet under två relevanta livscykelcykler och vid den förväntade samtidiga belastningen.

Använd de dedikerade proxynätverken för att verifiera det närmast beroende arbetsflödet. Dess åtkomst-, tids- och återställningsbeteende måste förbli oförändrat medan den nya designen är aktiv.

Stoppa och återgå till det sparade tillståndet om starten rapporterar att adressen redan används, trafiken når fel proxy eller TLS avslutas med certifikatet från en annan webbplats. Eskalera med tidsstämplar, exakta versioner, bevis från rutt eller montering och den minsta reproduktionen i stället för att lägga till ännu en lösning.

Jämför resultatet med DNS-överskrivningarna för reverse proxy så att risken inte bara flyttas till ett annat nätverks-, identitets-, säkerhetskopierings- eller lagringslager.

För dubbelt ägarskap av reverse-proxyportar är det kvalificerade svaret därför den inledande bedömningen - inte ett ovillkorligt ja. Det observerbara godkända tillståndet är acceptanslinjen; det underkända tillståndet är återställningslinjen.

Vanliga frågor

Kan SO_REUSEPORT låta oberoende proxyservrar dela 443?

Det är inte en säker design för värdnamnsbaserad routning mellan oberoende proxyservrar; använd en enda TLS-ingång eller separata IP-adresser.

Kan en proxy vidarebefordra TLS till den andra?

Ja, när routningen baseras på SNI och den nedströms placerade proxyn äger certifikatavslutningen för det värdnamnet.

Kolliderar IPv4- och IPv6-lyssnare?

Det kan de göra, beroende på socketbeteendet för dual stack och bindningsadresserna; inspektera båda protokollfamiljerna uttryckligen.