Satu endpoint VPN melalui Squid: pengecualian CONNECT yang sempit

Squid menjawab permintaan CONNECT dengan baris http_access pertama yang cocok, dan baris itu bisa berupa penolakan. Fakta tunggal ini menjelaskan mengapa pengecualian untuk endpoint VPN biasanya gagal pada percobaan pertama, karena permintaan tidak pernah mencapai izin yang ditambahkan seseorang di bagian bawah. Perbaikan yang sempit mempertahankan penjaga port yang ada dan mengajarkan mereka satu sumber, tujuan, dan port yang telah ditinjau. Semua hal lain pada proxy berperilaku persis seperti sebelumnya.

Bagaimana Squid memutuskan permintaan CONNECT

Permintaan CONNECT menyebutkan sebuah host dan sebuah port, dan Squid menelusuri baris http_access secara berurutan sampai salah satunya cocok. Penolakan yang cocok langsung mengakhiri evaluasi dan klien menerima 403 dari proxy. Itulah sebabnya posisi sebuah aturan lebih penting daripada rumusannya. Memindahkan baris yang sama satu langkah ke atas dapat mengubah hasilnya sepenuhnya.

Penjaga konvensional menolak apa pun di luar Safe_ports dan menolak CONNECT di luar SSL_ports. Nama-nama itu adalah ACL yang didefinisikan dalam konfigurasi Anda sendiri, jadi isinya milik Anda dan bukan milik protokol. Sebuah distribusi dapat mengizinkan rentang port yang luas sebagai Safe_ports sambil membatasi CONNECT secara terpisah. Baca nilai langsung sebelum menganggap sebuah port diblokir berdasarkan desain.

Pastikan proxy adalah komponen yang menolak permintaan. 403 yang dihasilkan Squid sama sekali tidak mirip peringatan TLS dari server VPN, dan menyatukan keduanya menjadi satu masalah menghabiskan jam pertama. Periksa baris log akses untuk permintaan itu, karena mencatat tindakan sekaligus aturan yang menghasilkannya.

Bangun satu kecocokan gabungan alih-alih tiga ACL terpisah

Bangun pengecualian dari tiga fakta: rentang sumber yang disetujui, satu alamat tujuan yang disetujui, dan satu-satunya port tempat endpoint mendengarkan. Dua ACL terpisah dan satu kecocokan gabungan menghasilkan kebijakan yang sangat berbeda, karena yang dievaluasi adalah kombinasinya. Beri nama ACL gabungan itu berdasarkan apa yang diizinkannya, bukan berdasarkan metode yang dibawanya.

Bentuk di bawah ini memakai rentang dokumentasi yang harus diganti dengan nilai yang telah ditinjau. Squid tidak mencadangkan satu pun nama ini, jadi Anda yang memilih dan Anda yang menjaganya konsisten. Resep ini dibatasi untuk Squid 6 dan 7, yang konfigurasi terdokumentasinya mendukung grup all-of. Referensi saat ini menandai direktif itu tidak tersedia di Squid 8, jadi perlakukan ini sebagai resep terikat versi dan bukan jalur migrasi, serta periksa direktif itu pada referensi versi Anda sendiri sebelum menerapkannya.

acl pvpn_src src 192.0.2.128/25
acl pvpn_dst dst 198.51.100.77/32
acl pvpn_port port 1194
acl pvpn_ok all-of CONNECT pvpn_port pvpn_dst pvpn_src

Grup all-of hanya cocok bila setiap anggota cocok, yang berarti sumber, tujuan, dan port diperiksa pada satu baris. Grup itu sendiri tidak memberikan apa pun, dan permintaan yang hanya cocok dengan dua dari tiga fakta tidak dapat memenuhinya. Sifat itu menjaga pengecualian tetap sempit ketika seseorang kelak menambahkan gateway kedua. Entah tujuan baru ditambahkan dengan sengaja, atau permintaan kembali ke penjaga semula.

Tekuk penjaga port tanpa menghapusnya

Pada posisi mereka saat ini, dua baris penjaga konvensional tampak seperti ini. Keduanya biasanya berada setelah autentikasi dan sebelum baris kebijakan yang mengizinkan apa pun.

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

Tambahkan kecocokan gabungan yang dinegasikan ke masing-masing, sehingga pengecualian yang cocok bertahan melewati penjaga yang jika tidak akan menolaknya. Hanya baris penjaga yang berubah, dan masing-masing hanya dengan satu suku tambahan.

http_access deny CONNECT !SSL_ports !pvpn_ok
http_access deny !Safe_ports !pvpn_ok

Suku-suku pada satu baris akses digabungkan, jadi baris itu kini hanya menolak permintaan yang gagal pada pemeriksaan asli dan pada pengecualian sekaligus. Permintaan untuk endpoint yang disetujui lolos, dan setiap permintaan lain mempertahankan perilaku port yang lama. Ini lebih sempit daripada menambahkan port ke daftar SSL_ports global, yang akan mengizinkan port itu ke setiap tujuan. Jika port sudah ada dalam daftar itu, ACL ini tidak menyempitkan apa pun dan izin lama yang lebih luas tetap berlaku untuk tujuan lain, jadi baca daftar langsung sebelum mengklaim pengecualian membuka port. Ini juga reversibel, karena dua baris kembali ke bentuk sebelumnya. Referensi kontrol akses mendokumentasikan urutan dan penjaga konvensional yang menjadi sandaran perubahan ini.

Di mana pengecualian tidak boleh ditempatkan

Godaannya adalah menaruh izin di atas penjaga lalu selesai. Penempatan itu juga melewati perlindungan autentikasi dan tujuan lokal yang biasanya berada dekat puncak konfigurasi yang berfungsi. Hasilnya bukan pengecualian sempit, melainkan lubang dengan komentar di atasnya. Pertahankan setiap izin baru pada tahap yang ditinjau sama seperti bagian lain kebijakan klien.

Periksa apa yang masih dibutuhkan permintaan setelah penjaga port. Akun terautentikasi, alamat klien yang diizinkan, dan kebijakan tujuan semuanya masih berlaku, dan pengecualian tidak mengubah satu pun dari itu. Jika proxy Anda sudah membiarkan akun yang disetujui menjangkau tujuan sembarang, penjaga port tidak pernah menjadi kendali yang sebenarnya.

Pertimbangkan apakah endpoint benar-benar TCP. Pengecualian CONNECT membawa aliran TCP, dan profil OpenVPN yang memakai UDP tidak akan menjadi terjangkau melaluinya. Ubah profil ke TCP hanya jika server mendengarkan dengan cara itu dan operator menerima perbedaan perilakunya.

Periksa batas dengan parser dan permintaan nyata

Urai konfigurasi sebelum memuat ulang, dan biarkan sesi kedua tetap terbuka selama melakukannya. Kesalahan sintaksis saat memuat ulang dapat meninggalkan proxy pada konfigurasi lama atau menolak yang baru sepenuhnya. Parser melaporkan baris yang ditolak, yang lebih banyak daripada yang akan diberitahukan kesalahan klien.

Lalu muat ulang dan kirim satu CONNECT nyata melalui proxy dari sumber yang disetujui. Menjalankan parser datang lebih dulu, karena memuat ulang dengan salah ketik tidak mengajarkan apa pun tentang kebijakan.

squid -k parse
squid -k reconfigure
curl -v -p -x http://proxy.lab.internal:3128 https://vpn.lab.internal:1194/ --max-time 5

Uji tiga kasus: sumber dan akun yang disetujui, sumber yang tidak disetujui, dan tujuan berbeda pada port yang sama. Kasus ketiga adalah yang membuktikan pengecualian itu sempit, karena melatih port tanpa kecocokan tujuan. Baca log akses untuk ketiganya alih-alih memercayai pesan klien. CONNECT yang berhasil membangun aliran TCP dan tidak lebih, jadi jabat tangan VPN tetap menjadi uji terpisah.