Ինչու VPN կայքից 403-ը վստահված սերվերի ձախողում չէ
Բնօրինակից 403-ը, մերժված CONNECT-ը և 407 մարտահրավերը նշում են տարբեր սահմաններ։ Նախ համեմատեք վստահված սերվերի ելքի ուղին դիտարկիչի VPN հասցեի հետ։
Օգտատերերը անջատում են VPN-ը, ներքին կայքում հանդիպում 403-ի և հայտնում, որ վստահված սերվերը փչացած է։ Այդ էջը կարող են ստեղծել երեք առանձին բաներ՝ բնօրինակը մերժել է հարցումը, առաջընթաց վստահված սերվերը հրաժարվել է բացել թունելը, կամ վստահված սերվերը պահանջել է իր սեփական հավատարմագրերը։ Դրանցից յուրաքանչյուրը տարբեր հարցի ճիշտ պատասխան է, և դրանք մեկ ընդհանուր ձախողման էջի հարթեցնելը ոչնչացնում է ձեր ունեցած միակ ապացույցը։ Դասավորեք մերժումը ըստ այն բաղադրիչի, որն այն ստեղծել է, ապա համեմատեք ցանցային ուղին, որն իրականում օգտագործում է յուրաքանչյուր բաղադրիչ։
Անվանեք 403-ը ստեղծած բաղադրիչը
HTTP կարգավիճակի կոդը պատկանում է այն կողմին, որը ուղարկել է այն։ Երբ բնօրինակը վերադարձնում է 403, այն վերլուծել է հարցումը և որոշել, որ զանգահարողը գուցե չունի ռեսուրսը, ինչը լիազորման պատասխան է, ոչ թե փոխադրման խնդիր։ Երբ առաջընթաց վստահված սերվերը CONNECT-ին պատասխանում է 403, այն ընդհանրապես հրաժարվել է կառուցել թունելը, և վերևում ոչ ոքի հետ կապ չի հաստատվել։ Երբ այն պատասխանում է 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 թունելը բայթային փոխանցումից
Երբ վստահված սերվերը CONNECT-ին վերադարձնում է 200, այն փոխանցում է բայթեր, և դիտարկիչը պահում է իր 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'
Եթե դա CONNECT-ի համար տպում է 200 և հետո TLS ձեռքսեղմում, վստահված սերվերի ընդունումը կարգին է, և հետագա 403-ը եկել է բնօրինակից։ Եթե տպում է 407, տրամադրեք վստահված սերվերի հավատարմագրերը --proxy-user-ով և կրկնեք կայքի մասին որևէ եզրակացություն անելուց առաջ։ Եթե CONNECT տողում տպում է 403, վստահված սերվերի սեփական թույլատրելիների ցանկն է քննելու սահմանը, և հավելվածը ներգրավված չէ։
Հավատարմագրերը հեռու պահեք shell-ի պատմությունից և տեղադրված սղագրություններից։ Հրամանի տողում մուտքագրված վստահված սերվերի գաղտնաբառը տեսանելի է այլ տեղական օգտատերերի համար, և հավատարմագրերով գրանցված CONNECT հետքը ավելի վատ է, քան հետքի բացակայությունը։
Պահեք դատավճիռը ընթեռնելի՝ էջը վերաշարադրելու փոխարեն
Երբ իմանաք, թե որ բաղադրիչը մերժեց, պահպանեք այդ պատասխանը։ Հակադարձ վստահված սերվերը, որը բնօրինակի 403-ը վերանվանում է 504 ժամանակավարտ, կամ այն փոխարինում է հաջողության էջով, թաքցնում է լիազորման որոշումը հասանելիության պատմության հետևում և հաջորդ պատասխանողին ուղարկում է սխալ թիմ։ Անհատական սխալի էջերը լավն են, երբ պահում են կարգավիճակը և ավելացնում համատեքստ։
Քեշավորումը նույն խնամքն է արժանի։ RFC 9111-ը կարգավորում է, թե ինչպես կարող են համօգտագործվող քեշերը կրկին օգտագործել պատասխանները, և մեկ զանգահարողի համար ստեղծված մերժումը չպետք է փոխանցվի մյուսին՝ կարծես թույլտվություն լիներ։ Եթե մերժման պատասխանները ընդհանրապես պահվում են, պահեք դրանք մասնավոր և սահմանափակ, և երբեք չավելացնեք հանրային թարմության կանոն միայն վերևի հոսքի երթևեկությունը նվազեցնելու համար։
Ավարտեք գրավոր դատավճռով, որը նշում է բաղադրիչը, նրա ստեղծած կարգավիճակը և աղբյուրի հասցեն, որը տեսել է բնօրինակը։ Գրանցեք ճշգրիտ հարցումը, գործող վստահված սերվերի կարգավորումները և ժամանակը, որպեսզի հաջորդ զեկույցը կարողանա համեմատվել նույն ապացույցների հետ՝ հիշողությունից նորից չստանալու փոխարեն։ Այդ գրառումը պատասխանում է հաջորդ զեկույցին վայրկյանների ընթացքում և կանխում է նույն 403-ի կրկնակի ախտորոշումը որպես VPN ընդհատում։