OpenVPN-ը HTTP փրոքսիի միջոցով. նախ կարդացեք CONNECT-ի պատասխանը
CONNECT փրոքսին փոխանցում է բայթեր, ուստի երկու կողմերին էլ TCP է պետք։ Կարդացեք 407, 403 և 503-ը նախքան վկայագրերին մեղադրելը, և թողեք սերվերի ստուգումը միացված։
Ուղղեք VPN հաճախորդը կորպորատիվ HTTP փրոքսիի, և առաջին օգտակար փաստն այն է, որ փրոքսին չի խոսում VPN-ի արձանագրությամբ։ Այն բացում է սովորական TCP կապ ձեր նշած հասցեով և հետո քաշվում է կողմ, թողնելով ձեր հաճախորդին և սերվերին իրենց փոխանակությունն անել այդ հոսքի միջով։ Այն ամենը, ինչ պետք է հաճախորդին՝ տրանսպորտի տեսակից մինչև սերվերի լսողը, պետք է համապատասխանի այդ դասավորությանը։ Երկու անհամապատասխանություն բացատրում են խափանումների մեծ մասը՝ UDP պրոֆիլ՝ ուղղված CONNECT փրոքսիին, և փրոքսիի պատասխան, որը սխալմամբ ընդունվում է որպես VPN սխալ։
Ինչ է տանում փրոքսին և ինչ՝ ոչ
Փրոքսին ընդամենը տրանսպորտային քայլ է։ Այն չի դառնում ձեր բրաուզերի փրոքսին, չի պահում քեշում այն կայքերը, որոնք այցելում եք թունելով, և չի տեսնում ներքին երթևեկությունը, եթե ինչ-որ մեկը դիտավորյալ ստուգում չի կարգավորել։ Այն թունելը, որը բացում է, նրա համար անթափանց է ըստ նախագծի։
Դա նաև նշանակում է, որ փրոքսին չի կարող ուղղել սերվերը, որին համապատասխան լսող չկա։ Նպատակակետին հասնելու թույլտվությունը և այդ նպատակակետում լսող ծառայությունը երկու առանձին փաստ են, և միայն առաջինն է պատկանում փրոքսիի ադմինիստրատորին։
Փոխադրիչը պետք է TCP լինի երկու ծայրերում
Սովորական CONNECT փրոքսին միայն բայթային հոսք է փոխանցում , ուստի հաճախորդը պետք է օգտագործի հոսքային տրանսպորտ։ Այդ դեպքի հաճախորդի հատվածն այսպիսի տեսք ունի.
proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128Սերվերի կողմին պետք է իրական TCP լսող remote տողում նշված պորտում։ Պրոֆիլում proto udp-ը proto tcp-client-ով փոխարինելը ստեղծում է հաճախորդ, որը սպասում է հոսքի. այն չի ստեղծում հոսքը մյուս կողմում։ Եթե նույն սերվերը նաև պատասխանում է UDP-ով այդ պորտում, դա այլ լսող է, ոչ թե նույնի երկրորդ ռեժիմը։
Այնտեղ, որտեղ կա առանձին TCP օրինակ, նրա թունելային սարքը, հասցեների լողավազանը և երթուղավորումը սեփական ռեսուրսներ են։ Աշխատող կոնֆիգուրացիան պատճենելը և տրանսպորտի բառը փոխելը թողնում է այդ ռեսուրսները ուղղված բնօրինակ օրինակին, ինչը ստեղծում է կապ, որը նույնականացվում է, ապա ոչինչ չի երթուղավորում։
Կարդացեք փրոքսիի պատասխանը VPN-ի արդյունքից առաջ
Հաճախորդի առաջին փոխանակությունը հարցումային տող է, որը նշում է նպատակակետի հոսթը և պորտը։ Այդ տողի պատասխանը ձեզ ասում է՝ արդյոք բայթային հոսք ընդհանրապես կա, և այն գալիս է նախքան որևէ վկայագրի կամ հավատարմագրի ստուգումը.
CONNECT vpn.example.net:1194 HTTP/1.1
Host: vpn.example.net:1194| Proxy reply | What it means | Where to look next |
|---|---|---|
407 Proxy Authentication Required | The proxy wants its own credentials | The client's proxy auth options, not the VPN account |
403 Forbidden | The destination or method is not permitted | The proxy's access policy for that host and port |
503 Service Unavailable | The proxy could not complete the upstream connection | The proxy's own logs and the server's listener |
CONNECT-ին 200 դասի պատասխանը նշանակում է, որ հոսքը կա։ Այն ոչինչ չի ասում այն մասին, թե արդյոք դարպասի վկայագիրը վստահելի է, արդյոք ընդհանուր բանալին համընկնում է, թե արդյոք օգտվողի հաշիվը վավեր է։ Այդ ստուգումները կատարվում են ավելի ուշ՝ հոսքի ներսում, և դրանք ձախողվում են հաճախորդի սեփական հաղորդագրություններով, ոչ թե HTTP կարգավիճակի տողով։ Հաճախորդի մատյանում փնտրեք առաջին OpenVPN իրադարձությունը փրոքսիի ձեռքսեղմումից հետո, ոչ թե վերջին տողը մինչև պատուհանի փակվելը։
Փրոքսիի և VPN-ի հավատարմագրերը հաճախ տարբեր ինքնություններ են՝ տարբեր թիմերի ձեռքում։ 407-ը VPN հաշվի վատ գաղտնաբառ չէ, և մերժված վկայագիրը փրոքսիի թույլտվության խնդիր չէ։
Ինչ չի բացահայտում CONNECT-ը
Բացահայտ CONNECT թունելը գաղտնալսում չէ։ Փրոքսին փոխանցում է բայթեր և չի ավարտում VPN-ի TLS սեսիան, ուստի հաճախորդի կողմից սերվերի վկայագրի ստուգումը մնում է իմաստալից և պետք է մնա միացված։ Ստուգումն անջատելը փրոքսիով անցնելու համար լուծում է ձերինից տարբեր խնդիր։
Կան առանձին կարգավորումներ, որտեղ կազմակերպությունը դիտավորյալ ավարտում և ստուգում է TLS-ը։ Դրանք պահանջում են իրենց վստահության կոնֆիգուրացիան և իրենց քաղաքականության որոշումը, և դրանք այն չեն, ինչ պահանջում է սովորական http-proxy տողը։
TCP-ի գինը TCP-ի ներսում
Թունելը TCP-ով տանելը պահում է արտաքին հոսքը կարգավորված և վերահաղորդմամբ, իսկ ներքին երթևեկությունը սովորաբար նույնպես TCP է։ Երկու վերականգնման մեխանիզմները չեն համաձայնեցվում, ուստի մեկ կորսված սեգմենտը կարող է կանգնեցնել այն ամենը, ինչ կիսում է այդ արտաքին հոսքը, մինչև այն նորից ուղարկվի։ Սա համատեղելիության համար իրական զիջում է, ոչ թե անվճար բարելավում։
Օգտագործեք փրոքսիի ուղին, երբ ցանցը ձեզ այլընտրանք չի թողնում, և նախընտրեք ուղիղ UDP ուղին այնտեղ, որտեղ քաղաքականությունը թույլ է տալիս։ Ամեն դեպքում, փոփոխությունից հետո համոզվեք, որ նույն փրոքսին, նպատակակետը և պրոֆիլը հասնում են հաջորդ փուլ. դիտարկիչը, որը այդ հասցեում էջ է բեռնում, այլ արձանագրություն է օգտագործում և ոչինչ չի ապացուցում թունելի մասին։