Zergatik erregistratzen du Squid-ek HTTPS ostalaria baina ez orriaren bidea
Squid CONNECT erregistro arruntetan falta diren HTTPS bideak azaltzen ditu, TLS interception ohiko erregistro-doikuntza gisa hartu gabe.
shop.example:443rako erregistro batek ez dio Squid-i /orders/42 bidea ematen. CONNECT-ek ostalari/portua eskatzen du; gero helmugako TLS-ek HTTP bidea tunelaren barruan eramaten du.
| Froga | CONNECT errele arrunta |
|---|---|
| Helburuko ostalaria/portua eta tunelaren emaitza | Proxyarentzat eskuragarri. |
| Barneko HTTPS bidea eta aplikazioaren eskaera | Bezeroaren eta webgunearen artean enkriptatuta. |
# karakterearekin hasten den nabigatzailearen URL zatia | Normalean bezeroan geratzen da, proxy-erregistrotik kanpo ere. |
Erregistro formatu batek Squidek dituen eremuak erregistra ditzake, ez ikusi gabeko mezuak deszifratu. HTTP birbidalketa arrunta desberdina da, bitartekariak HTTP eskaera hori jasotzen duelako. Irteera xeheagoak ez du CONNECT muga aldatzen.
Kudeatutako TLS interception-ak bezeroaren konfiantza eta administrazio-eskakizunak aldatzen ditu. Ez da erregistro-etengailu txiki bat eta ez da beharrezkoa IP aldatzen duen aurreranzko proxy normal batentzat.
Aplikazioa zurea bada eta orri-mailako diagnostikoa behar baduzu, erabili bere erregistroak edo behar bezala diseinatutako bezero telemetria. Proxy hutsegiteetarako, gorde helburuko ostalaria, denbora, egoera eta osatutako konexio-fasea; askotan arazoa kokatzen dute orri-bide pribaturik bildu gabe.