Membaca ralat SO_ORIGINAL_DST Squid

NF getsockopt(SO_ORIGINAL_DST) menunjuk kepada carian destinasi asal. Dalam persediaan pintasan, Squid perlu memulihkan ke mana sambungan yang dialihkan itu menuju pada asalnya.

Pelayar yang dikonfigurasikan secara eksplisit menghantar permintaannya kepada proksi dengan sengaja. Sambungan itu tidak memperoleh sejarah pintasan NAT semata-mata kerana intercept ditulis di sebelah port pendengar Squid.

Oleh itu ketidakpadanan ini boleh gagal sebelum sijil destinasi menjadi relevan.

Mulakan dengan cara sambungan itu tiba

• Jika aplikasi mempunyai alamat proksi yang dikonfigurasikan, kenal pasti pendengar proksi penghantaran biasa yang sepatutnya digunakan.
• Jika get laluan mengalihkan trafik yang sepatutnya langsung, semak sama ada ia sampai ke pendengar pintasan yang dimaksudkan dan sama ada reka bentuk NAT yang disokong mengekalkan maklumat destinasi yang diperlukan.
• Jika kedua-dua mod wujud, semak alamat dan port mana yang sebenarnya dihubungi oleh klien yang gagal.

Dokumentasi http_port Squid menjelaskan perbezaan dengan jelas: meninggalkan bendera mod memilih mod proksi penghantaran; intercept menjangka pintasan NAT pada lapisan IP.

Kemudian kendalikan keselamatan pengangkutan secara berasingan. Proksi HTTP boleh membawa HTTPS melalui CONNECT. Sambungan TLS ke proksi memerlukan pendengar dan konfigurasi klien yang serasi. Menyahsulit trafik destinasi ialah satu lagi keupayaan pilihan.

Jangan salin “pembaikan HTTPS” lama yang menghidupkan penjanaan sijil semata-mata kerana URL destinasi bermula dengan HTTPS. Baiki dahulu persetujuan antara klien dan pendengar. Jika selepas itu masih ada ralat TLS sebenar, ralat itulah yang lebih berguna untuk disiasat.