Proxy masih di alamat tunnel lama setelah VPN tersambung ulang?
Penyambungan ulang dapat membuat penerus Anda terikat pada alamat yang tidak lagi dimiliki tunnel. Empat pemeriksaan berurutan, serah terima bernomor, dan permintaan uji sungguhan.
Menjalankan ulang klien VPN hanya membuktikan bahwa tunnel kembali. Itu tidak mengatakan apa pun tentang proxy yang diperintahkan keluar melaluinya. Squid, tinyproxy, dan sebagian besar penerus lain menyimpan alamat sumber lokal yang mereka dapatkan saat mulai sampai sesuatu memaksa mereka memuat ulang. Ketika penyambungan ulang memberikan alamat tunnel baru, penerus gagal pada setiap koneksi keluar atau mulai keluar melalui rute biasa Anda.
Kegagalan kedua itulah yang berbahaya: tunnel hidup, halaman termuat, dan hanya alamat keluarnya yang salah.
Mulai dari pendengar, bukan dari tunnel
Ada tiga alamat dalam permainan, dan penyambungan ulang hanya menggeser sebagian. Pendengar adalah tempat peramban Anda menunjuk, biasanya 127.0.0.1 atau alamat LAN, dan ia tidak peduli bahwa tunnel berubah. Sumber lokal keluar adalah yang diminta penerus kepada kernel saat memanggil hop berikutnya, dan itu terikat pada perangkat tunnel. Keluaran publik adalah yang dicatat server web, dan itu bisa berupa alamat hasil terjemahan beberapa hop jauhnya.
Pencarian IP publik hanya menjawab pertanyaan terakhir. Itu tidak bisa memberi tahu alamat lokal mana yang harus diikat penerus, karena satu keluaran publik bisa menyembunyikan beberapa sumber internal. Bacalah alamat dari pemilik koneksi: keluaran status klien, antarmuka itu sendiri, atau ruang nama tempat tunnel hidup. Mengambil antarmuka pertama yang namanya mirip tunnel memberi jawaban salah begitu ada profil kedua.
Tata letak kontainer dan ruang nama mematahkan asumsi itu secara diam-diam. Penerus di satu ruang nama jaringan tidak dapat mengikat tunnel yang ada di ruang lain, dan tidak ada jumlah penyuntingan konfigurasi yang memperbaikinya.
Empat pemeriksaan sebelum Anda menyunting apa pun
Kerjakan berurutan. Pemeriksaan pertama yang gagal adalah tempat Anda berhenti, karena yang berikutnya menganggap yang sebelumnya berlaku.
- Pastikan tunnel yang dipakai adalah profil yang menjadi dasar pembuatan proxy, bukan profil kedua yang tersambung sendiri.
- Cetak alamat yang saat ini ada pada perangkat itu dan bandingkan dengan alamat dalam konfigurasi yang berjalan.
- Tanyakan kepada penerus sumber apa yang berhasil ia pecahkan, bukan apa yang diklaim berkas di disk.
- Pastikan lalu lintas dari penerus benar-benar tunduk pada kebijakan perutean dan firewall yang Anda harapkan.
Alamat perangkat mudah: ip -4 addr show dev tun0 mencetak alamat saat ini, dan ip -4 route get 1.1.1.1 menunjukkan antarmuka mana yang akan dipilih kernel untuk tujuan itu. Penerus yang mengikat alamat persis gagal dengan suara keras ketika alamat itu hilang. Penerus yang mengikat perangkat, atau jatuh kembali ke sumber bawaan, terus bekerja dan bocor, dan itulah hasil yang senyap.
Cocokkan dokumentasi dengan rilis yang Anda jalankan, bukan dengan hasil pencarian teratas. Direktif alamat keluar Squid didokumentasikan untuk v7 dan sebelumnya, dan dokumentasi v8 menyatakan jelas bahwa direktif itu tidak tersedia di sana, jadi skrip yang dibangun di sekitarnya tidak bertahan melewati batas itu (lihat referensi Squid tcp_outgoing_address). Validasi dengan parser produk itu sendiri sebelum apa pun dimuat ulang: squid -k parse melaporkan galat dan keluar tanpa menyentuh proses yang berjalan.
Beri nomor setiap tunnel dan buang pertukaran yang usang
Penyambungan ulang adalah serah terima, dan serah terima butuh urutan. Tandai setiap koneksi yang teramati dengan penghitung atau stempel waktu yang naik pada setiap pendirian yang berhasil, lalu bawa tanda itu di dalam konfigurasi kandidat. Ketika tanda pada kandidat lebih tua daripada yang sekarang, buang kandidat itu alih-alih menerapkannya, karena pembaruan lambat yang ditulis untuk tunnel sebelumnya akan menimpa pengaturan tunnel sekarang. Gabungkan ledakan peristiwa agar tautan yang berkedip menghasilkan satu transisi, bukan lima belas.
Susun pekerjaan dalam empat langkah: batalkan status keluar lama, tunggu pemilik koneksi melaporkan penyelesaian, bangun hanya fragmen yang dikelola, lalu validasi dan aktifkan melalui manajer layanan. Membuat ulang seluruh berkas dari dua nilai alamat adalah cara pembatasan pendengar, autentikasi, dan kebijakan tujuan menghilang diam-diam. Hormati juga penghentian yang disengaja. Pembantu yang terus memanggil tunnel yang dimatikan pengguna adalah bug, bukan ketahanan.
Soket terbuka tidak akan mengikuti alamat baru
Mengonfigurasi ulang penerus tidak mengatakan apa pun tentang koneksi yang sudah berdiri. Apakah koneksi itu terkuras atau mati bergantung pada produknya, jadi amati perilakunya alih-alih menganggapnya.
Permintaan yang dilayani melalui soket yang dibuka sebelum pertukaran tetap keluar melalui jalur lama, bahkan ketika konfigurasi baru sudah benar. Jika itu penting, putuskan secara eksplisit: beri jendela pengurasan singkat dan berhenti menerima pekerjaan baru, atau akhiri soket lama dan terima galatnya. Lalu uji dengan koneksi baru dan pisahkan hasil itu dari pemeriksaan pengurasan. Pengikatan sumber juga bukan batas keamanan. Ketika lalu lintas tidak boleh pernah menyentuh rute biasa, tegakkan dengan tanda dan aturan firewall, termasuk DNS dan IPv6, agar muat ulang yang gagal meninggalkan proxy benar-benar mati, bukan terbuka.
Buktikan keluaran baru dengan permintaan baru
Yang penting adalah permintaan yang dibuka setelah aktivasi, bukan ping dan bukan halaman yang sudah di-cache. Minta proxy mengambil URL sungguhan dan baca alamat keluar yang dilaporkan ujung jauh, lalu bandingkan dengan pandangan klien sendiri tentang tunnel ketika penyedia menampilkannya.
Jaga penguraian, muat ulang, dan permintaan sebagai perintah terpisah agar kegagalan menunjuk satu langkah. Dua yang pertama tidak mengubah apa pun saat gagal, dan itulah sebabnya keduanya berjalan sebelum mulai ulang.
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.comJika muat ulang gagal, hentikan layanan dan perbaiki fragmennya; proxy yang melayani dengan keluaran usang lebih buruk daripada gangguan singkat. Jika muat ulang berhasil tetapi permintaan baru tetap keluar di tempat tak terduga, kembali ke pemeriksaan perutean alih-alih menyunting alamat lagi. Catat generasi tunnel yang Anda validasi, agar penyambungan ulang berikutnya punya sesuatu yang konkret untuk dibandingkan.