sshuttle berbanding VPN penuh: apa yang sebenarnya diliputi kaedahnya
sshuttle hanya membawa apa yang disokong oleh kaedah penghantarannya: semak dahulu liputan TCP, DNS dan UDP, keistimewaan setempat yang diperlukan dan pembantu jauh.
sshuttle dipilih kerana SSH sudah berfungsi dan kriptografi kelihatan biasa, dan penaakulan itu melangkau satu-satunya soalan yang menentukan kesesuaiannya. Paket mana yang meninggalkan mesin, akaun mana yang membawanya di sebelah sana, dan berapa banyak keistimewaan setempat yang dituntut alat itu. Ketiga-tiga jawapan berbeza mengikut kaedah penghantaran, jadi persediaan yang berfungsi untuk satu aplikasi boleh gagal secara senyap untuk aplikasi seterusnya. Huraian di bawah bermula dengan protokol yang benar-benar diperlukan oleh aplikasi.
Mulakan dengan protokol yang diperlukan oleh aplikasi
Sokongan protokol dalam sshuttle 2.0 bergantung pada kaedah yang anda pilih. Kaedah NAT dan nft dalam Linux mengendalikan TCP dan DNS, dan TPROXY menambah UDP umum. Setiap platform dan kaedah mempunyai hadnya sendiri, dan macOS memintas melalui mekanisme yang sama sekali berbeza. Catat versi yang dipasang, kaedah yang dipilih dan protokol yang diperlukan oleh aplikasi sebelum anda memilih apa-apa.
Oleh itu, permintaan TCP yang berjaya membuktikan sangat sedikit tentang aplikasi UDP atau tentang setiap carian DNS. sshuttle juga menganggap TCP sebagai aliran dan bukannya mengterowongkan paket IP penuh, jadi kesimpulan daya pemprosesan yang dipinjam daripada VPN biasa tidak terpakai di sini. Bandingkan mekanisme yang benar-benar anda jalankan dengan beban kerja yang benar-benar anda miliki.
| Approach | What it carries | What it needs locally |
|---|---|---|
| SSH local forward | One explicitly named TCP destination | Nothing beyond the SSH client |
| sshuttle, nft or nat method | TCP and DNS to the routed prefixes | Root or sudo for firewall rules |
| sshuttle, tproxy method | TCP, DNS and general UDP | Root or sudo, and kernel support |
| IP VPN | Routed IP traffic in a tunnel | A client with the required privileges |
Apa yang diperlukan klien secara setempat
Susunan klien yang didokumenkan memerlukan root atau sudo, kerana ia memasang peraturan pintasan setempat dan bukannya mencipta antara muka terowong. Satu fakta itu mengubah kisah keselamatan: proses dengan keistimewaan itu boleh mengubah hala trafik seluruh mesin, bukan hanya satu aplikasi. Anggap keistimewaan itu sebagai bahagian reka bentuk dan bukan butiran pemasangan.
Sahkan peraturan mana yang dipasang oleh alat itu dan bahawa ia hilang apabila ia keluar. Sesi yang ranap dan meninggalkan peraturan pintasan boleh menghantar trafik ke lubang hitam lama selepas pengendali percaya sambungan itu sudah pergi, dan gejalanya kelihatan seperti gangguan rangkaian dan bukan peraturan yang tertinggal.
sudo sshuttle --method nft --dns 172.19.4.0/24
nft list ruleset | grep -i sshuttle
ip routePerintah pertama ialah bentuk panggilan biasa, dengan awalan yang benar-benar anda perlukan. Perintah kedua menunjukkan apa yang dipasang oleh alat itu, dan yang ketiga mengesahkan bahawa tiada antara muka terowong muncul, iaitu hasil yang dijangka untuk reka bentuk ini.
Apa yang dijalankan oleh sebelah jauh
Sebelah jauh ialah akaun SSH yang dibenarkan serta persekitaran pembantu Python yang serasi. Log masuk yang berjaya di bawah shell terhad tidak memberikan kebenaran secara automatik untuk menjalankan pembantu itu, dan akaun yang boleh menjalankan pembantu itu tidak sampai secara automatik ke setiap perkhidmatan sasaran. Kedua-dua fakta itu tergolong dalam permintaan akses dan bukan dalam nota penyelesaian masalah.
Lindungi pengesahan identiti hos dan pengesahan akaun. Menerima kunci hos yang tidak dikenali supaya sambungan pertama berfungsi menghapuskan pemeriksaan bahawa sebelah jauh ialah mesin yang anda maksudkan, dan itu lebih penting di sini berbanding penghantaran untuk satu tujuan.
Hadkan akaun jauh kepada perkhidmatan yang diperlukan oleh aliran kerja, dan rundingkan skop itu dengan pihak yang mengendalikan hos. Mereka sebahagian daripada hubungan kepercayaan, dan tiada tetapan di sebelah klien mengubahnya.
Di mana letaknya sempadan kepercayaan
Menghantar sambungan API peribadi melalui SSH tidak membenarkan setiap operasi API. TLS aplikasi dan log masuk aplikasi masih terpakai, dan alat itu tidak boleh menjadikan perkhidmatan tanpa pengesahan selamat. Lompatan selanjutnya daripada hos jauh juga tidak secara automatik menjadi segmen terlindung yang sama seperti saluran SSH, kerana sambungan kedua itu mengikut apa jua dasar yang ada pada hos jauh.
Tuliskan sempadan itu dalam satu ayat: trafik ke awalan ini keluar melalui akaun ini pada hos itu. Jika ayat itu memerlukan satu perenggan pengecualian, reka bentuk itu melakukan lebih daripada yang didakwa oleh dokumentasinya dan wajar ditinjau semula sebelum sampai ke pengeluaran.
Buktikan mengikut protokol, kemudian pilih alat itu
Uji setiap protokol yang diperlukan dengan permintaan tidak berbahaya, termasuk laluan penyelesai dan keluarga alamat yang digunakan oleh aplikasi. Sertakan pemutusan dalam ujian, supaya tingkah laku kegagalan yang dibenarkan menjadi hasil yang diketahui dan bukan kejutan semasa insiden. Sesi yang menghantar dengan betul semasa aktif tidak mengatakan apa-apa tentang apa yang berlaku apabila ia terputus.
Untuk segelintir perkhidmatan yang dinamakan secara jelas, penghantaran setempat biasa lebih mudah dimiliki dan diaudit. Untuk trafik aplikasi yang sesuai dengan kaedahnya, sshuttle menawarkan jalan tengah yang sah. Apabila keperluannya ialah kesambungan IP yang luas, reka bentuk VPN ialah jawapan jujur, dan pilihan mengikut liputan dan tanggungjawab operasi dan bukan kedudukan algoritma penyulitan.