WSS-ը Squid-ի միջոցով նույնը չէ, ինչ սովորական WebSocket թարմացումը
Առանձնացրեք CONNECT-ի ներսում գաղտնագրված WebSocket-ները forward proxy-ում պարզ HTTP Upgrade-ի մշակումից։
Squid-ը տեսնում է HTTP Upgrade հարցում, թե՞ միայն գաղտնագրված երթևեկություն կրող թունել։ Դա որոշում է՝ արդյոք նրա HTTP Upgrade կառավարումը լուծում է խափանումը։
| Սովորական բացահայտ proxy-ի ուղի | Ինչի է հանդիպում Squid-ը |
|---|---|
wss:// | Սովորաբար CONNECT, ապա նպատակակետի TLS, որը կրում է WebSocket-ի ձեռքսեղմումը |
ws:// | Պարզ HTTP Upgrade հարցում, որը proxy-ն կարող է մշակել |
Squid-ի թարմացման կառավարումը վերաբերում է այն հարցումներին, որոնք ինքն է մշակում։ Այն չի բացահայտում գաղտնագրված HTTP վերնագրերը սովորական անթափանց WSS թունելի ներսում։ TLS-ի ընդհատումը կամ proxy-ի այլ հատուկ մշակումը փոխում է տեսանելիությունը և կարող է բերել իր սեփական համատեղելիության պահանջները։
WSS-ի համար գտեք, թե որտեղ է կանգ առնում հաջորդականությունը՝ կապը proxy-ի հետ, ընդունված CONNECT, ստուգված TLS, ապա հավելվածի ձեռքսեղմումը։ TLS-ից առաջ մերժումը տարբեր խափանում է, քան մերժված պարզ Upgrade հարցումը։
Եթե թարմացման քաղաքականության փոփոխություն է անհրաժեշտ, օգտագործեք տեղադրված Squid տարբերակի հրահանգը և հատուկ թույլատրեք պահանջվող վարքը։ Բոլոր թարմացման արձանագրությունների թույլատրումը քաղաքականությունը տարածում է կոնկրետ հավելվածից այն կողմ։
Հաջող HTTPS էջի հարցումը հաստատում է ուղու միայն մի մասը։ Երկարատև WebSocket երթևեկությունը դեռ կարող է ձախողվել հավելվածի պահանջների, կապի կյանքի տևողության կամ միջնորդների սահմանափակումների պատճառով, նույնիսկ նույն host անվան դեպքում։