Ваш цыкл перанакіраванняў Magento, хутчэй за ўсё, не звязаны з VPN

Вы бачыце 302 у журнале доступу, вітрына не загружаецца праз VPN, і выснова напрошваецца сама. Звычайна гэтая выснова памылковая, і даволі цікава. Адказ перанакіравання фіксуе месца прызначэння, куды браўзеру загадалі ісці, і нічога не кажа пра тое, ці праблему стварыў тунель, сертыфікат або праграма. Радок журнала — гэта пачатак расследавання, а не яго вынік.

302 паказвае куды, а не чаму

Запіс у журнале доступу фіксуе запыт, стан і памер і звычайна апускае загаловак Location, які якраз мае значэнне. Адно перанакіраванне можа быць цалкам нармальным: кананічнае імя хоста, нармалізацыя канцавога слэша, пераход на HTTPS. Вам патрэбна паслядоўнасць, бо адзін крок і цыкл — гэта розныя няспраўнасці з рознымі ўладальнікамі. Паўторныя крокі паміж схемамі паказваюць на апрацоўку URL і схемы. А крок да імені, якое браўзер не можа развязаць, паказвае зусім у іншае месца.

Нішто з гэтага не з'яўляецца доказам пра VPN. Тунель — гэта шлях; перанакіраванне — гэта інструкцыя, якую запісала праграма.

Фіксуйце ланцужок, а не радок журнала

Скарыстайцеся сеткавым выглядам браўзера і запішыце чатыры палі на кожны крок: запытаны URL, стан, загаловак Location і час. Скончыце або канчатковым адказам, або памылкай злучэння, бо цікавы выпадак — гэта крок, які так і не завяршаецца. Зрабіце гэта адзін раз на працоўным шляху і адзін раз на збойным, з тым жа ўліковым запісам і той жа навігацыяй. Параўнанне двух ланцужкоў каштоўнейшае за любы адзін радок у журнале.

Трымайце гэты запіс прыватным. URL нясуць ідэнтыфікатары сесіі, а захаваны архіў браўзера нясе больш, чым вы чакаеце. Выдаляйце радкі запыту, перш чым што-небудзь уставіць у тыкет.

Уяўленне праграмы пра ўласны URL

Magento стварае абсалютныя URL з канфігурацыі, з прывязкай да вэб-сайта або прадстаўлення крамы. bin/magento config:show web/secure/base_url друкуе значэнне, у якое верыць праграма, і гэта часта імя хоста, якое засталося ад зборкі або міграцыі, а не тое, якім карыстаўся браўзер. Калі там названы ўнутраны хост, браўзер адпраўляюць туды, куды ён не можа дайсці, і ніякае змяненне тунеля гэтага не выправіць.

Параўнайце бяспечныя і небяспечныя базавыя URL з публічнымі імёнамі, што перад вамі. Неадпаведнасць у любым з іх дае менавіта тое перанакіраванне, на якое вы глядзіце.

Загалоўкі даверанага проксі — гэта дамова

Калі TLS завяршаецца на балансіроўшчыку, праграма бачыць звычайны HTTP, і ёй трэба сказаць пра гэта інакш. Налада загалоўка offloader называе загаловак, які ўсталёўвае проксі, напрыклад перададзены пратакол, і праграма давярае яму пры выбары схемы.

Гэтае давер'е — дамова з адным проксі, а не агульны дазвол. Прыманне загалоўка ад адвольных кліентаў дазваляе кожнаму заявіць схему, таму ён мае сэнс толькі там, дзе яго ўсталёўвае прызначаны проксі. Калі імя загалоўка і паводзіны проксі не супадаюць, праграма стварае перанакіраванні на схему, якой браўзер ніколі не карыстаўся, і цыкл замыкаецца. Праверце канфігурацыю проксі і наладу праграмы разам, затым ачысціце кэш канфігурацыі, каб змяненне ўступіла ў сілу.

Калі цыкл — гэта сесія, а не маршрут

Ланцужок, які заўсёды вяртае да ўваходу, звычайна азначае праблему з cookie. Праверце, ці cookie сесіі быў выдадзены для таго імя хоста, якім браўзер сапраўды карыстаўся, і ці быў ён пазначаны як бяспечны на злучэнні, якое браўзер лічыць бяспечным. Cookie, прывязаны да няправільнага дамена, стварае цыкл уваходу, які выглядае зусім як збой маршрутызацыі.

Выпраўце прадэманстраваную неадпаведнасць у яе ўласніка, ці гэта базавы URL, дамен cookie або дамова проксі, і затым паўторна праверце ўсю навігацыю, а не назірайце за знікненнем аднаго 302. Адключэнне патрабаванняў HTTPS дзеля разрыву цыкла абменьвае перанакіраванне на горшую праблему. Калі змяненне зроблена, праверце тунель асобна: запытайце вядомы прыватны рэсурс і пацвердзіце, што ён даходзіць, каб наступнае перанакіраванне мела чыстую базу для параўнання.