WSS caur Squid nav tas pats, kas vienkārša WebSocket jaunināšana
Atdaliet šifrētos WebSocket CONNECT iekšienē no vienkāršas HTTP Upgrade apstrādes tiešajā starpniekserverī.
Vai Squid redz HTTP Upgrade pieprasījumu vai tikai tuneli ar šifrētu satiksmi? Tas nosaka, vai tā HTTP Upgrade vadības risina kļūmi.
| Parastais tiešā starpniekservera ceļš | Ar ko Squid sastopas |
|---|---|
wss:// | Parasti CONNECT, pēc tam galamērķa TLS, kas pārnēsā WebSocket rokas paspiešanu |
ws:// | Parasts HTTP Upgrade pieprasījums, ko starpniekserveris var apstrādāt |
Squid jaunināšanas vadība attiecas uz pieprasījumiem, ko tas apstrādā. Tā neatklāj šifrētas HTTP galvenes parastā necaurspīdīgā WSS tunelī. TLS pārtveršana vai cita īpaša starpniekservera apstrāde maina redzamību un var radīt savas saderības prasības.
WSS gadījumā atrodiet, kur secība apstājas: savienojums ar starpniekserveri, pieņemts CONNECT, pārbaudīts TLS, pēc tam lietojumprogrammas rokas paspiešana. Noraidījums pirms TLS ir cita kļūme nekā noraidīts parasts Upgrade pieprasījums.
Ja nepieciešams mainīt jaunināšanas politiku, izmantojiet direktīvu instalētajai Squid versijai un īpaši atļaujiet nepieciešamo darbību. Atļaujot visus jaunināšanas protokolus, politika tiek paplašināta ārpus konkrētās lietojumprogrammas.
Veiksmīgs HTTPS lapas pieprasījums nosaka tikai daļu ceļa. Ilgstoša WebSocket satiksme joprojām var neizdoties lietojumprogrammas prasību, savienojuma darbības laika vai starpnieku ierobežojumu dēļ, pat ar to pašu resursdatora nosaukumu.