Kunnen twee reverseproxy’s poorten 80 en 443 delen op één homeserver?

Eva Wong

IceWhale author

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

Can Two Reverse Proxies Share Ports 80 and 443 on One Home Server? - Zima Store Online

Niet tegelijkertijd op hetzelfde IP-adres en protocol, tenzij één proxy de enige voordeur is en geselecteerd verkeer doorstuurt naar de andere, of beide een ander IP-adres gebruiken.

Dit wordt een echte compatibiliteitskwestie wanneer twee proxycontainers op één machine beide hostpoorten 80 en 443 publiceren voor afzonderlijke app-stacks. Begin met een wegwerptraject of account, houd de vorige werkende toestand beschikbaar en beoordeel het ontwerp aan de hand van de oorspronkelijke werklast in plaats van een eenmalige verbindingstest.

Stel vast wie de gedeelde resource beheert

De ondersteunde variant is één listener per IP-poortcombinatie, met routering erachter. De concurrerende variant is twee onafhankelijke listeners die om dezelfde socket strijden. Leg versies, identiteiten, adressen, mountpaden, machtigingen en de huidige waarneembare toestand vast voordat je een van beide varianten wijzigt.

De relevante regels voor socketbinding bepalen de eerste compatibiliteitsgrens. Gebruik deze om de bewering af te bakenen en verifieer vervolgens hetzelfde gedrag op deze exacte homeserver, in plaats van een gedocumenteerde functie te beschouwen als bewijs dat het volledige ontwerp werkt.

Schrijf de beslisregel op voordat je test: succes betekent dat alleen de bedoelde frontproxy elke openbare socket beheert en elke hostnaam de juiste upstream bereikt met het verwachte certificaat; falen omvat een startupmelding dat het adres al in gebruik is, verkeer dat de verkeerde proxy bereikt of TLS dat eindigt met het certificaat van een andere site. Zo voorkom je dat een gedeeltelijke verbinding of een succesvol beëindigd commando verkeerd wordt geïnterpreteerd als end-to-endcompatibiliteit.

Wijzig één listener of route tegelijk

Gebruik één gecontroleerde onderscheidende factor: vermeld de huidige listeners, bind elke proxy aan een verschillend test-IP-adres of plaats de ene achter de andere en test vervolgens Host-, SNI-, WebSocket- en certroutings. Houd de client, werklast, bestanden, account en timing constant, zodat het gewijzigde onderdeel de enige plausibele verklaring is.

Gebruik het gedrag van gepubliceerde poorten om te bepalen welke tweede observatie voor dit traject van belang is. Leg beide kanten van de transactie vast: resolver of route, onderhandeld protocol, procesidentiteit, afsluitstatus, latentie, overgedragen bytes en eventuele herstelgebeurtenissen.

Herhaal de test na de in de titel genoemde levenscyclusgebeurtenis - opnieuw aanmaken, opnieuw verbinden, opnieuw mounten, herstarten, failover of een andere client. Een ontwerp dat alleen werkt zolang oude sockets, caches of referenties actief blijven, is niet geslaagd.

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

Gebruik waarneembaar routeringsbewijs om te beslissen

GESLAAGD: alleen de bedoelde frontproxy beheert elke openbare socket en elke hostnaam bereikt de juiste upstream met het verwachte certificaat. Bewaar de exacte versies en topologie die deze toestand hebben opgeleverd, omdat de conclusie voor die omstandigheden geldt en niet voor elke implementatie van het protocol.

MISLUKT: de startup meldt dat het adres al in gebruik is, verkeer bereikt de verkeerde proxy of TLS eindigt met het certificaat van een andere site. Controleer gedeelde afhankelijkheden zoals DNS, MTU, identiteit, firewallstatus, opslaglatentie en gecachte sessies voordat je een van beide primaire varianten verantwoordelijk stelt.

UITZONDERING: stop de tweede openbare binding, herstel de laatst werkende listener en kies één voordeur of afzonderlijke hostadressen. Breid machtigingen niet uit, verwijder geen brongegevens, verzwak de transportbeveiliging niet en vervang werkende opslag niet totdat een herhaalbare observatie vaststelt welke grens is overschreden.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

Controleer de isolatie opnieuw voordat productieverkeer terugkeert

Pas alleen de actie toe die bij de waargenomen variant hoort en voer vervolgens de oorspronkelijke werklast opnieuw uit. Behoud het ontwerp alleen wanneer alleen de bedoelde frontproxy elke openbare socket beheert en elke hostnaam de juiste upstream bereikt met het verwachte certificaat gedurende twee relevante levenscycli en onder de verwachte gelijktijdige belasting.

Gebruik de speciale proxynetwerken om de dichtstbijzijnde afhankelijke workflow te verifiëren. De toegang, timing en het herstelgedrag ervan moeten ongewijzigd blijven terwijl het nieuwe ontwerp actief is.

Stop en keer terug naar de opgeslagen toestand als de startup meldt dat het adres al in gebruik is, verkeer de verkeerde proxy bereikt of TLS eindigt met het certificaat van een andere site. Escaleer met tijdstempels, exacte versies, route- of mountbewijs en de kleinst mogelijke reproductie in plaats van nog een workaround toe te voegen.

Controleer het resultaat aan de hand van de DNS-overschrijvingen voor reverse proxies, zodat het risico niet slechts naar een andere netwerk-, identiteits-, back-up- of opslaglaag wordt verplaatst.

Voor dubbel eigenaarschap van reverse-proxypoorten is het gekwalificeerde antwoord daarom het aanvankelijke oordeel - geen onvoorwaardelijk ja. De waarneembare geslaagde toestand is de acceptatiegrens; de mislukte toestand is de terugdraaigrens.