Så åtgärdar du en omvänd proxy som skickar en domän till fel app efter att en catch-all-regel har lagts till

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

En omvänd proxy kan skicka en domän till fel app när en ny catch-all-rutt matchar bredare eller prioriteras högre än den avsedda värdregeln.

Detta är mer specifikt än en generell omdirigering till fel domän eller ett DNS-problem. Det viktiga testet är om den korrekta domänen fortfarande når den förväntade proxy-IP-adressen och det förväntade certifikatet, men proxyn väljer fel backend först efter att den nya standardrutten har skapats. Jämför ruttmatchningar och prioriteringar innan du ändrar DNS, programmets bas-URL:er eller certifikat.

Bevisa att catch-all-regeln ändrade valet av backend

Skicka samma domänförfrågan före och efter att du endast har inaktiverat den nya catch-all- eller standardrutten. Anteckna proxyns åtkomstlogg, vald router eller serverblock, backend-adress, svarmarkör och certifikat.

En praktisk guide till Nginx-standardservrar varnar för att catch-all-regler kan fånga trafik även när flera uttryckliga virtuella värdar redan finns.

Om inaktivering av reservrutten omedelbart återställer den avsedda appen ska du låta DNS och backend-appen vara oförändrade. Nästa steg är att se till att den specifika rutten vinner utan att ta bort ett säkert reservbeteende för okända värdnamn.

Kontrollera om den specifika värdregeln fortfarande matchar exakt

Jämför det begärda värdnamnet med den avsedda ruttregeln tecken för tecken, inklusive underdomän, wildcard-gränser, avslutande punkter i testverktyg och om regeln lyssnar på samma HTTP- eller HTTPS-ingång som catch-all-rutten.

En guide för omvänd proxy med flera appar visar att värdnamnsregler väljer olika backends endast när den inkommande värden matchar regeln som proxyn faktiskt har läst in.

Åtgärda en ofullständig eller felstavad värdmatchare innan du justerar prioriteten. Att höja prioriteten för en regel som aldrig matchar gör bara konfigurationen svårare att förstå.

Jämför ruttprioriteten med catch-all-rutten

För proxyservrar som stöder uttrycklig eller härledd prioritet ska du kontrollera vilken regel som vinner när både den specifika värden och den breda reservrutten kan matcha samma förfrågan. Anteckna den utvärderade regeln, inte bara ordningen i konfigurationsfilen.

Ett Traefik-exempel med catch-all ger medvetet reservrutten lägre prioritet än de riktiga rutterna så att specifika tjänster utvärderas först.

Placera reservrutten under alla avsedda apprutter och testa igen. Lös inte problemet genom att tilldela godtyckligt stora tal till varje router. Använd i stället ett enkelt, dokumenterat prioritetssystem som fungerar även när nya appar läggs till.

-15% OFF
Single board computer zimaboard2

Inspektera standardservern på Nginx-liknande proxyservrar

På Nginx och liknande konfigurationer ska du fastställa vilket serverblock som blir standard för den lyssningsadressen och porten när ingen matchning av värdnamnet hittas. Det första inlästa blocket kan bli reservrutt om ingen uttrycklig standard har definierats.

En fokuserad felsökningsartikel om Nginx förklarar varför omatchade värdar når standardservrar i stället för att avvisas tyst.

Använd ett neutralt standardsvar eller en feltjänst i stället för att göra en riktig app till reservrutt. Då kan ett okänt eller felstavat värdnamn inte oavsiktligt exponera en annan självhostad app.

Kontrollera HTTP- och HTTPS-reservrutter separat

En catch-all-rutt som läggs till för port 80 beter sig inte automatiskt på samma sätt på port 443. TLS-dirigering, SNI, separata ingångar eller en andra catch-all-rutt kan göra att endast HTTPS-förfrågningar når fel app.

Ett felsökningsfall i Caddy beskriver en catch-all-rutt som beter sig olika beroende på protokoll och visar varför den protokollspecifika rutten måste testas direkt.

Skicka både HTTP och HTTPS med samma värdnamn och anteckna vilken hanterare som valdes. Åtgärda reservrutten på den berörda ingången i stället för att ändra den fungerande protokollvägen.

Håll reservrutten neutral och testa alla kända domäner igen

När matchningsomfattningen eller prioriteten har korrigerats ska du låta reservrutten returnera ett neutralt 404-, 421- eller kontrollerat felsvar i stället för att proxiera varje okänt värdnamn till en produktionsapp. Testa sedan varje känd självhostad domän en gång.

En översikt över arkitektur för omvända proxyservrar betonar att proxyn bestämmer backend efter att förfrågan nått proxyn, vilket är anledningen till att korrekt DNS inte ensamt kan bevisa att dirigeringen är korrekt.

Åtgärden är slutförd när varje känt värdnamn når sin avsedda app och ett okänt värdnamn endast når den neutrala reservrutten. Den relaterade ZimaSpace-artikeln om en omvänd proxy som omdirigerar till en annan domän är nästa spår när proxyn väljer rätt backend men appen senare ändrar domän.

Vanliga frågor

Kan DNS göra att en catch-all-rutt vinner?

DNS kan skicka förfrågan till fel proxy-IP-adress, men när den korrekta proxyn tar emot det avsedda värdnamnet är ruttmatchningen ett beslut som proxyn fattar. Kontrollera båda lagren separat.

Bör catch-all-rutten proxiera till en instrumentpanelapp?

Vanligtvis inte. Ett neutralt felmål är säkrare eftersom stavfel och okända värdnamn då inte oavsiktligt kan exponera en riktig administrations- eller medieapp.

Varför når endast HTTPS fel app?

HTTPS kan använda en annan lyssnare, SNI-väg, certifikatplats eller reservregel än HTTP. Testa båda ingångarna separat innan du ändrar den globala dirigeringen.

Support och tips

Mer att läsa

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.