Uw Magento-doorverwijslus is waarschijnlijk niet de VPN

U ziet 302 in het toegangslog, de winkel laadt niet via de VPN, en de conclusie schrijft zichzelf. Die conclusie is meestal op een interessante manier onjuist. Een doorverwijsantwoord legt een bestemming vast waarheen de browser is gestuurd, en het zegt niets over de vraag of de tunnel, het certificaat of de applicatie het probleem heeft veroorzaakt. De logregel is het begin van het onderzoek, niet de uitkomst.

Een 302 zegt waar, niet waarom

Een regel in het toegangslog legt de aanvraag, de status en de grootte vast, en laat meestal de Location-header weg die ertoe doet. Eén doorverwijzing kan volkomen normaal zijn: een canonieke hostnaam, een normalisatie van de afsluitende schuine streep, een overstap naar HTTPS. Wat u nodig hebt is de volgorde, want één sprong en een lus zijn verschillende fouten met verschillende eigenaren. Herhaalde sprongen tussen schema's wijzen op de omgang met URL en schema. Een sprong naar een naam die de browser niet kan oplossen wijst ergens heel anders heen.

Geen van beide is bewijs over de VPN. De tunnel is een pad; de doorverwijzing is een instructie die de applicatie heeft geschreven.

Leg de keten vast, niet de logregel

Gebruik de netwerkweergave van de browser en noteer vier velden per sprong: de opgevraagde URL, de status, de Location-header en de tijd. Eindig met het eindantwoord of met de verbindingsfout, want het interessante geval is de sprong die nooit wordt voltooid. Doe dit één keer op een werkend pad en één keer op het falende, met hetzelfde account en dezelfde navigatie. Twee ketens vergelijken is meer waard dan welke enkele regel in een log dan ook.

Houd die vastlegging privé. URL's dragen sessie-identificaties, en een opgeslagen browserarchief draagt meer dan u verwacht. Verwijder querystrings voordat u iets in een ticket plakt.

Het beeld dat de applicatie van zijn eigen URL heeft

Magento genereert absolute URL's uit de configuratie, met een bereik per website of winkelweergave. bin/magento config:show web/secure/base_url drukt de waarde af die de applicatie gelooft, en dat is vaak een hostnaam die overblijft van een build of een migratie in plaats van degene die de browser gebruikte. Als daar een interne host wordt genoemd, wordt de browser ergens heen gestuurd waar hij niet kan komen, en geen enkele tunnelwijziging lost dat op.

Vergelijk de beveiligde en onbeveiligde basis-URL met de openbare namen voor u. Een afwijking in een van beide levert precies de doorverwijzing op waar u naar staart.

Headers van een vertrouwde proxy zijn een contract

Wanneer TLS eindigt bij een loadbalancer, ziet de applicatie gewone HTTP en moet haar iets anders worden verteld. De instelling voor de offloader-header noemt de header die de proxy zet, zoals het doorgestuurde protocol, en de applicatie vertrouwt daarop bij beslissingen over het schema.

Dat vertrouwen is een contract met één proxy, geen algemene toestemming. De header van willekeurige clients accepteren laat iedereen een schema opeisen, en daarom hoort hij alleen daar waar een aangewezen proxy hem zet. Als de headernaam en het gedrag van de proxy niet overeenkomen, genereert de applicatie doorverwijzingen naar een schema dat de browser nooit heeft gebruikt, en de lus sluit zich. Controleer de proxyconfiguratie en de applicatie-instelling samen, en leeg daarna de configuratiecache zodat de wijziging ingaat.

Wanneer de lus een sessie is, geen route

Een keten die altijd terugkeert naar inloggen is meestal een cookieprobleem. Onderzoek of de sessiecookie is uitgegeven voor de hostnaam die de browser werkelijk gebruikte, en of die als beveiligd is gemarkeerd op een verbinding die de browser als beveiligd beschouwt. Een cookie die aan het verkeerde domein is gekoppeld, levert een inloglus op die er precies als een routeringsfout uitziet.

Los de aangetoonde afwijking op bij de eigenaar, of dat nu de basis-URL, het cookiedomein of het proxycontract is, en test daarna de hele navigatie opnieuw in plaats van te kijken hoe één 302 verdwijnt. HTTPS-vereisten uitschakelen om de lus te doorbreken ruilt een doorverwijzing voor een erger probleem. Als de wijziging klaar is, controleer de tunnel dan apart: vraag een bekende privéresource op en bevestig dat die aankomt, zodat de volgende doorverwijzing een schone basislijn heeft om mee te vergelijken.