Teie Magento ümbersuunamistsükkel pole tõenäoliselt VPN-i süü

Näete juurdepääsulogis 302, pood ei laadi VPN-i kaudu ja järeldus kirjutab end ise. See järeldus on tavaliselt huvitaval viisil vale. Ümbersuunamisvastus salvestab sihtkoha, kuhu brauseril kästi minna, ega ütle midagi selle kohta, kas probleemi tekitas tunnel, sertifikaat või rakendus. Logirida on uurimise algus, mitte selle tulemus.

302 ütleb kuhu, mitte miks

Juurdepääsulogi kirje salvestab päringu, oleku ja suuruse ning jätab tavaliselt välja olulise Location-päise. Üks ümbersuunamine võib olla täiesti tavaline: kanooniline hostinimi, lõpu-kaldkriipsu normaliseerimine, üleminek HTTPS-ile. Vaja on järjestust, sest üks hüpe ja tsükkel on erinevad rikked erinevate omanikega. Korduvad hüpped skeemide vahel viitavad URL-i ja skeemi käsitlemisele. Hüpe nimele, mida brauser ei suuda lahendada, viitab hoopis mujale.

Miski sellest ei ole tõend VPN-i kohta. Tunnel on tee; ümbersuunamine on juhis, mille rakendus kirjutas.

Jäädvustage ahel, mitte logirida

Kasutage brauseri võrguvaadet ja märkige iga hüppe kohta neli välja: päritud URL, olek, Location-päis ja aeg. Lõpetage kas lõpliku vastuse või ühenduse veaga, sest huvitav juhtum on hüpe, mis kunagi ei lõpe. Tehke seda üks kord töötaval teel ja üks kord nurjuval teel, sama kontoga ja sama navigatsiooniga. Kahe ahela võrdlemine on väärtuslikum kui ükski üksik rida logis.

Hoidke see kirje privaatsena. URL-id kannavad sessioonitunnuseid ja salvestatud brauseriarhiiv kannab rohkem, kui ootate. Enne pileti kleebimist eemaldage päringustringid.

Rakenduse ettekujutus omaenda URL-ist

Magento genereerib absoluutsed URL-id konfiguratsioonist, ulatusega veebisaidi või poevaate kaupa. bin/magento config:show web/secure/base_url prindib väärtuse, mida rakendus usub, ja see on tihti ehitamisest või migratsioonist jäänud hostinimi, mitte see, mida brauser kasutas. Kui seal on nimetatud sisemine host, saadetakse brauser sinna, kuhu ta ei pääse, ja ükski tunnelimuudatus ei paranda seda.

Võrrelge turvalist ja ebaturvalist baas-URL-i ees olevate avalike nimedega. Erinevus kummaski neist tekitab täpselt selle ümbersuunamise, mida vaatate.

Usaldusväärse puhverserveri päised on leping

Kui TLS lõpeb koormusjaoturis, näeb rakendus tavalist HTTP-d ja talle tuleb öelda teisiti. Offloaderi päise säte nimetab päise, mille puhverserver seab, näiteks edastatud protokolli, ja rakendus usaldab seda skeemiotsuste tegemisel.

See usaldus on leping ühe puhverserveriga, mitte üldine luba. Päise vastuvõtmine suvalistelt klientidelt lubab kõigil skeemi väita, seetõttu kuulub see ainult sinna, kus selle seab määratud puhverserver. Kui päise nimi ja puhverserveri käitumine ei ühti, genereerib rakendus ümbersuunamisi skeemile, mida brauser kunagi ei kasutanud, ja tsükkel sulgub. Kontrollige puhverserveri konfiguratsiooni ja rakenduse sätet koos, seejärel tühjendage konfiguratsioonivahemälu, et muudatus jõustuks.

Kui tsükkel on sessioon, mitte marsruut

Ahel, mis naaseb alati sisselogimise juurde, on tavaliselt küpsise probleem. Kontrollige, kas sessiooniküpsis väljastati hostinimele, mida brauser tegelikult kasutas, ja kas see märgiti turvaliseks ühendusel, mida brauser peab turvaliseks. Vale domeeniga seotud küpsis tekitab sisselogimistsükli, mis näeb täpselt välja nagu marsruutimise rike.

Parandage tõestatud erinevus selle omaniku juures, olgu selleks baas-URL, küpsise domeen või puhverserveri leping, ja testige seejärel kogu navigatsiooni uuesti, selle asemel et vaadata, kuidas üks 302 kaob. HTTPS-i nõuete väljalülitamine tsükli murdmiseks vahetab ümbersuunamise halvema probleemi vastu. Kui muudatus on tehtud, kontrollige tunnelit eraldi: küsige tuntud privaatset ressurssi ja kinnitage, et see kohale jõuab, et järgmisel ümbersuunamisel oleks puhas võrdlusalus.