Proksi masih pada alamat terowong lama selepas VPN disambung semula?

Penyambungan semula boleh membiarkan forwarder anda terikat pada alamat yang terowong tidak lagi miliki. Empat pemeriksaan tersusun, penyerahan bernombor dan permintaan ujian sebenar.

Memulakan semula klien VPN hanya membuktikan terowong telah kembali. Ia tidak berkata apa-apa tentang proksi yang diberitahu untuk keluar melaluinya. Squid, tinyproxy dan kebanyakan forwarder lain menyimpan alamat sumber setempat yang mereka peroleh semasa mula sehingga sesuatu memaksa mereka memuat semula. Apabila sambungan semula memberikan alamat terowong baharu, forwarder sama ada gagal pada setiap sambungan keluar, atau mula keluar melalui laluan biasa anda.

Kegagalan kedua itulah yang berbahaya: terowong hidup, halaman dimuatkan, dan hanya alamat keluar yang salah.

Mulakan dengan pendengar, bukan terowong

Tiga alamat terlibat, dan sambungan semula hanya menggerakkan sebahagiannya. Pendengar ialah tempat pelayar anda menuju, biasanya 127.0.0.1 atau alamat LAN, dan ia tidak peduli terowong telah berubah. Sumber setempat keluar ialah apa yang forwarder minta kernel gunakan apabila mendail hop seterusnya, dan ia terikat pada peranti terowong. Keluaran awam ialah apa yang dicatat pelayan web, dan ia mungkin alamat terjemahan beberapa hop jauhnya.

Carian IP awam hanya menjawab soalan terakhir. Ia tidak dapat memberitahu alamat setempat mana yang perlu diikat oleh forwarder, kerana satu keluaran awam boleh menyembunyikan beberapa sumber dalaman. Baca alamat daripada pemilik sambungan: keluaran status klien, antara muka itu sendiri, atau ruang nama tempat terowong hidup. Mengambil antara muka pertama yang namanya kelihatan seperti terowong memberi jawapan salah sebaik sahaja profil kedua wujud.

Susun atur kontena dan ruang nama memecahkan andaian itu secara senyap. Forwarder dalam satu ruang nama rangkaian tidak boleh mengikat terowong yang wujud dalam ruang nama lain, dan tiada jumlah penyuntingan konfigurasi dapat membaikinya.

Empat pemeriksaan sebelum anda menyunting apa-apa

Lakukan mengikut urutan. Pemeriksaan pertama yang gagal ialah tempat anda berhenti, kerana yang berikutnya menganggap yang sebelumnya sah.

  1. Pastikan terowong yang digunakan ialah profil yang menjadi asas proksi, bukan profil kedua yang bersambung sendiri.
  2. Cetak alamat yang kini ada pada peranti itu dan bandingkan dengan alamat dalam konfigurasi yang berjalan.
  3. Tanya forwarder sumber apa yang ia selesaikan, bukan apa yang didakwa oleh fail pada cakera.
  4. Pastikan trafik daripada forwarder benar-benar tertakluk kepada dasar penghalaan dan tembok api yang anda jangkakan.

Alamat peranti mudah: ip -4 addr show dev tun0 mencetak yang semasa, dan ip -4 route get 1.1.1.1 menunjukkan antara muka mana yang akan dipilih kernel untuk destinasi itu. Forwarder yang mengikat alamat tepat gagal dengan kuat apabila alamat itu hilang. Forwarder yang mengikat peranti, atau kembali kepada sumber lalai, terus berfungsi dan bocor, dan itulah hasil senyap.

Padankan dokumentasi dengan keluaran yang anda jalankan, bukan dengan hasil carian teratas. Arahan alamat keluar Squid didokumenkan untuk v7 dan lebih awal, dan dokumentasi v8 menyatakan dengan jelas bahawa arahan itu tidak tersedia di sana, jadi skrip yang dibina mengikutnya tidak melepasi sempadan itu (lihat rujukan Squid tcp_outgoing_address). Sahkan dengan penghurai produk itu sendiri sebelum apa-apa dimuat semula: squid -k parse melaporkan ralat dan keluar tanpa menyentuh proses yang berjalan.

Nomborkan setiap terowong dan buang pertukaran usang

Sambungan semula ialah penyerahan, dan penyerahan memerlukan urutan. Tandakan setiap sambungan yang diperhatikan dengan pembilang atau cap masa yang meningkat pada setiap pembentukan berjaya, kemudian bawa tanda itu dalam konfigurasi calon. Apabila tanda pada calon lebih lama daripada yang semasa, buang calon itu daripada menerapkannya, kerana kemas kini perlahan yang ditulis untuk terowong sebelumnya akan menimpa tetapan terowong semasa. Gabungkan letupan peristiwa supaya pautan yang berkelip menghasilkan satu peralihan dan bukan lima belas.

Susun kerja dalam empat langkah: batalkan keadaan keluar lama, tunggu pemilik sambungan melaporkan penyelesaian, bina hanya serpihan terurus, kemudian sahkan dan aktifkan melalui pengurus perkhidmatan. Menjana semula seluruh fail daripada dua nilai alamat ialah cara sekatan pendengar, pengesahan dan dasar destinasi hilang secara senyap. Hormati juga hentian yang disengajakan. Pembantu yang terus mendail terowong yang dimatikan pengguna ialah pepijat, bukan ketahanan.

Soket terbuka tidak akan mengikut alamat baharu

Mengkonfigurasi semula forwarder tidak berkata apa-apa tentang sambungan yang sudah terbentuk. Sama ada ia disalirkan atau mati bergantung pada produk, jadi perhatikan tingkah laku dan jangan menganggapnya.

Permintaan yang dilayan melalui soket yang dibuka sebelum pertukaran masih keluar melalui laluan lama, walaupun konfigurasi baharu betul. Jika itu penting, putuskan secara jelas: beri tetingkap saliran pendek dan berhenti menerima kerja baharu, atau tamatkan soket lama dan terima ralatnya. Kemudian uji dengan sambungan baharu dan asingkan hasil itu daripada pemeriksaan saliran. Pengikatan sumber juga bukan sempadan keselamatan. Apabila trafik tidak boleh menyentuh laluan biasa, kuatkuasakan dengan tanda dan peraturan tembok api, termasuk DNS dan IPv6, supaya muat semula yang gagal membiarkan proksi benar-benar mati dan bukan terbuka.

Buktikan keluaran baharu dengan permintaan baharu

Yang penting ialah permintaan yang dibuka selepas pengaktifan, bukan ping dan bukan halaman yang sudah dicache. Minta proksi mengambil URL sebenar dan baca alamat keluar yang dilaporkan hujung jauh, kemudian bandingkan dengan pandangan klien sendiri tentang terowong apabila pembekal memaparkannya.

Kekalkan penghuraian, muat semula dan permintaan sebagai arahan berasingan supaya kegagalan menunjuk satu langkah. Dua yang pertama tidak mengubah apa-apa apabila gagal, dan itulah sebabnya ia berjalan sebelum mula semula.

squid -k parse
sudo squid -k reconfigure
curl -x http://127.0.0.1:3128 -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://example.com

Jika muat semula gagal, hentikan perkhidmatan dan baiki serpihan itu; proksi yang melayani dengan keluaran usang lebih buruk daripada gangguan singkat. Jika muat semula berjaya tetapi permintaan baharu masih keluar di tempat tidak dijangka, kembali ke pemeriksaan penghalaan dan jangan sunting alamat lagi. Catat generasi terowong yang anda sahkan, supaya sambungan semula berikutnya mempunyai sesuatu yang konkrit untuk dibandingkan.

Artikel berkaitan