Зашто 403 са VPN сајта није квар проксија
403 од извора, одбијен CONNECT и 407 изазов означавају различите границе. Прво упоредите излазну путању проксија са VPN адресом прегледача.
Корисници искључе VPN, наиђу на 403 на интерној страници и пријаве да је прокси покварен. Три одвојене ствари могу да произведу ту страницу: извор је одбио захтев, проследни прокси је одбио да отвори тунел или је прокси затражио сопствене акредитиве. Свака од њих је тачан одговор на друго питање, а њихово свођење на једну општу страницу квара уништава једини доказ који имате. Разврстајте одбијање по компоненти која га је произвела, а затим упоредите мрежну путању коју свака компонента заиста користи.
Именујте компоненту која је произвела 403
HTTP статусни код припада страни која га је послала. Када извор врати 403, он је анализирао захтев и одлучио да позивалац можда нема ресурс, што је одговор о ауторизацији, а не проблем транспорта. Када проследни прокси одговори 403 на CONNECT, одбио је да уопште изгради тунел, и ништа изнад није било контактирано. Када одговори 407, тражи сопствене акредитиве, које немају никакве везе са пријавом у апликацију.
| What you observe | What it means |
|---|---|
| Origin replies 403 | The origin understood the request and denied it |
| Proxy refuses CONNECT with 403 | The proxy declined to open that tunnel |
| Proxy replies 407 | Proxy authentication is required first |
| Gateway replies 502 or 504 | Upstream failure or timeout, not a permission decision |
RFC 9110 дефинише ове улоге, укључујући изазов својствен проксију. Прочитајте сопствени статус одговора и сваки заглавље Proxy-Authenticate пре читања тела, јер пријатељска HTML страница грешке обично крије која ју је компонента написала.
Шта CONNECT тунел крије од преноса бајтова
Када прокси врати 200 на CONNECT, он преноси бајтове и прегледач чува сопствену TLS сесију са извором. Прокси који преноси бајтове зато не може да прочита шифровани 403 унутар те сесије и никада не постаје аутор одбијања. Одбијање пре отварања тунела је сасвим други догађај, створен један слој ниже.
Обрнути прокси који завршава TLS је у другом положају: поседује TLS границу, анализира HTTP и може легитимно да преписује или пресреће одговоре. Та способност је избор конфигурације, а не својство проксија уопште, и не даје право да се заобиђе политика приступа апликације. Читање одговора је способност; одлука шта позивалац сме да види остаје посао извора.
Практична последица је да морате да знате који од три облика извршавате пре него што протумачите 403. Додавање правила за HTTP инспекцију стримном проксију не даје му видљивост, а очекивање да пренос бајтова објасни одбијање извора послаће вас у погрешан дневник.
Упоредите излазну путању проксија са адресом тунела прегледача
Прегледач повезан са VPN-ом не премешта аутоматски посебан прокси сервер на тај тунел. Извор види излазну адресу проксија, и ако прокси и даље излази преко локалне подразумеване руте, заштићени сајт види адресу којој никада није било конфигурисано да верује. Унутрашња VPN адреса на преносном рачунару невидљива је том извору. Ово је најчешћи разлог зашто тунел који ради и даље даје 403 са сајта који се према свима осталима понаша исправно.
Тестирајте обе путање одвојено да се адресе не би помешале.
curl -sS -o /dev/null -w 'status=%{http_code}\n' --noproxy '*' https://198.51.100.20/private
curl -sS -o /dev/null -w 'status=%{http_code}\n' -x http://203.0.113.10:3128 https://198.51.100.20/privateПрви захтев показује шта извор одговара на вашу сопствену адресу, други показује шта одговара на адресу проксија. Подударни пар 403 указује на правила ауторизације извора; 200 иза којег следи 403 указује на путању проксија. Питајте власника извора које изворне адресе скуп правила заиста прихвата, уместо да претпостављате да је VPN базен укључен.
Тестирајте сваку границу захтевом који је изолује
Изолујте слој проксија тако што ћете од њега затражити нешто што не може да одбије из апликацијских разлога. CONNECT ка домаћину до којег прокси сме да стигне, са одбаченим излазом, каже вам да ли пријем у тунел уопште ради.
curl -sSv -o /dev/null -x http://203.0.113.10:3128 https://198.51.100.20/ 2>&1 | grep -E 'CONNECT|HTTP/1.1|Proxy-Authenticate'
Ако то испише 200 за CONNECT и затим TLS руковање, пријем проксија је у реду и каснији 403 је дошао од извора. Ако испише 407, доставите акредитиве проксија са --proxy-user и поновите пре него што донесете било какав закључак о сајту. Ако испише 403 у линији CONNECT, сопствена листа дозвола проксија је граница коју треба испитати, а апликација није укључена.
Држите акредитиве ван историје шкољке и ван налепљених транскрипата. Лозинка проксија откуцана у командној линији видљива је другим локалним корисницима, а забележен CONNECT траг са акредитивима гори је од никаквог трага.
Држите пресуду читљивом уместо да преписујете страницу
Када знате која је компонента одбила, сачувајте тај одговор. Обрнути прокси који изворни 403 преименује у 504 истек или га замењује страницом успеха крије одлуку о ауторизацији иза приче о доступности и шаље следећег одговорног у погрешан тим. Прилагођене странице грешке су добре када задрже статус и додају контекст.
Кеширање заслужује исту пажњу. RFC 9111 уређује како заједнички кешеви смеју поново да користе одговоре, а одбијање створено за једног позиваоца не сме да се преда другом као да је дозвола. Ако се одговори о одбијању уопште чувају, држите их приватним и ограниченим, и никада не додајте јавно правило свежине само да бисте смањили саобраћај нагоре.
Завршите писаном пресудом која именује компоненту, статус који је створила и изворну адресу коју је извор видео. Забележите тачан захтев, важеће поставке проксија и време, да би следећи извештај могао да се упореди са истим доказима уместо да се поново изводи из памћења. Тај запис одговара на следећи извештај за неколико секунди и спречава да се исти 403 поново дијагностикује као прекид VPN-а.