Waarom Squid 'n UDP-sok het op 'n onverwagte poort
Onderskei Squid se DNS- en portuurkas-UDP-sokke van die TCP-ontvanger wat kliënte as 'n voorspelersproxy gebruik.
'n Onbekende UDP-poort wat deur Squid besit word, is nie outomaties nog 'n openbare HTTP-proxy nie. Kliënte gebruik die gekonfigureerde TCP-ontvanger vir gewone HTTP-proxytoegang; Squid open ook sokke vir DNS en kasportuur-kommunikasie.
Om die ekstra sok te identifiseer, teken op:
- Of dit TCP of UDP is, die gebinde adres daarvan en enige afgeleë eindpunt wat gewys word.
- Die effektiewe ontvanger-, DNS-, ICP- en HTCP-instellings vir daardie instansie.
- Die netwerkbereikbaarheid wat deur die funksie wat daardie instellings aktiveer, vereis word.
Squid se UDP-adresverwysing dek uitdruklik die DNS-, ICP- en HTCP-modules. Hul gedrag kan nie uit http_port afgelei word nie, en 'n hoë poortnommer alleen identifiseer nie die funksie nie.
Moenie daardie UDP-eindpunt in 'n toepassing se HTTP-proxyveld invoer of dit vir elke kliënt oopmaak net omdat dit in die soklys verskyn nie. Omgekeerd kan die blokkering van die DNS-pad wat Squid werklik gebruik, latere bestemmingresolusie breek. Verander die firewallreël vir die geïdentifiseerde funksie: 'n oplosser-navraagsok, kasportuurpoort en kliëntontvanger het verskillende take.