Proksi HTTP, terowong SSH atau VPN: pilih lapisan yang betul

Tanya tiga jurutera bagaimana hendak mencapai perkhidmatan dalaman dan anda akan mendapat tiga reka bentuk: proksi web, terowong SSH atau VPN penuh. Ketiga-tiganya boleh mendekatkan perkhidmatan jauh, dan ketiga-tiganya boleh membuat trafik kelihatan datang dari tempat lain. Perbezaannya muncul kemudian, apabila protokol yang digunakan bukan yang diandaikan oleh alat yang dipilih. Reka bentuk yang lulus pemeriksaan pelayar pantas biasanya gagal pada aplikasi yang mencetuskan permintaan itu.

Putuskan daripada dua fakta: protokol mana yang mesti melintas, dan siapa yang boleh menyelesaikan nama yang terlibat. Selebihnya ialah keutamaan.

Proksi hanya menggerakkan apa yang difahaminya

Proksi web menghuraikan protokol yang menjadi tujuan pembinaannya. Klien menyerahkan permintaan kepadanya dan ia menyerahkan permintaan itu ke hadapan, jadi aplikasi tanpa tetapan proksi tidak menyertai sama sekali. Untuk HTTPS klien memerlukan saluran legap, yang disediakan proksi melalui CONNECT dan bukan dengan membaca permintaan.

Pemajuan dinamik SSH membuka port setempat yang bertutur SOCKS, dan port itu memajukan aliran TCP ke mana-mana destinasi yang dinamakan klien. Protokol yang dibina di atas TCP biasanya berfungsi melaluinya. UDP tidak, melainkan alat menambah sokongan secara jelas. Pemajuan setempat lebih sempit: satu port setempat dipetakan kepada satu hos dan port tetap, yang melayani satu perkhidmatan yang diketahui dan tidak lebih.

ssh -D 1080 user@bastion
ssh -L 8443:fileserver.internal:443 user@bastion

VPN menggerakkan paket. Semua yang dihalakan klien ke dalam terowong melaluinya, termasuk UDP dan ICMP, sebab itu ia sesuai untuk keperluan rangkaian, bukan satu sambungan.

Seseorang mesti menyelesaikan nama itu

Apabila nama sasaran hanya wujud dalam DNS rangkaian jauh, mesin yang membuat carian mesti dapat melihat zon itu. Proksi web membuat carian itu sendiri, jadi nama dalaman berfungsi melaluinya walaupun komputer riba langsung tidak dapat menyelesaikan nama itu. SOCKS boleh berkelakuan sama, tetapi hanya jika klien memajukan nama itu dan bukannya menyambung ke alamat yang sudah diselesaikannya. Pilihan itu ada pada klien, bukan pada pelayan.

curl menunjukkan pemisahan itu dengan jelas: satu bendera menyerahkan nama hos kepada proksi, satu lagi menyelesaikannya secara setempat dahulu. Dengan penyelesaian setempat, nama yang hanya dalaman gagal sebelum mana-mana terowong disentuh, dan ralat itu menyalahkan proksi atas apa yang sebenarnya keputusan DNS.

VPN mengambil laluan ketiga dengan memasang penyelesai peribadi dan domain carian di sebelah laluan. Itu memudahkan, dan ia mencipta ilusi yang biasa: laluan yang wujud bersama penyelesai yang tidak menjawab kelihatan betul-betul seperti terowong mati, walaupun paket sampai ke seberang.

Apabila rangkaian hanya membenarkan satu jalan keluar

Banyak rangkaian korporat hanya membenarkan sambungan keluar melalui proksi web yang disahkan. OpenVPN dan SSH kedua-duanya boleh dijalankan di sana, yang pertama dengan menerowongkan pengangkutannya sendiri melalui proksi dan yang kedua melalui arahan proksi yang menjalankan pembantu CONNECT kecil.

Terowong yang dibina di atas TCP bertahan dengan kekangan itu, dan VPN berasaskan UDP tidak, yang menjelaskan sangat banyak konfigurasi yang berfungsi di rumah dan gagal di pejabat. Kos kedua mudah terlepas pandang: terowong TCP yang dibawa dalam sambungan TCP melalui proksi kini mempunyai dua lapisan yang menghantar semula, dan di bawah kehilangan pasangan itu tersekat dengan cara yang tidak dihasilkan mana-mana lapisan sendirian.

Merantaikan perantara ialah persoalan berbeza daripada memilih lapisan. Menambah proksi kedua atau Tor mengubah siapa memerhati apa, dan kedudukan dalam rantaian menentukan hop mana yang melihat teks sifer.

Urutan lebih penting daripada bilangan hop. Hop luar memerhati aliran tersulit manakala hop dalam melihat teks biasa yang dibawanya, jadi rantaian hanya seprivasi pautan yang paling tidak teliti. Mencampurkan protokol merentas hop tidak memperbaikinya secara automatik. Ia kebanyakannya menjadikan mod kegagalan lebih sukar difikirkan.

Alamat palsu bukan salah satu pilihan

Membina paket dengan alamat sumber orang lain tidak mencapai apa-apa yang berguna: balasan pergi kepada pemilik sebenar, dan kebanyakan rangkaian membuang trafik itu terus. Perantara diperlukan kerana sumber itu tidak boleh direka, dan itulah justifikasi jujur bagi ketiga-tiga reka bentuk.

Ia juga mengehadkan apa yang boleh didakwa oleh mana-mana daripadanya. Kelihatan berasal dari alamat tertentu ialah persoalan tentang di mana alamat itu diperuntukkan secara sah dan siapa yang boleh menghalakan laluannya, bukan tentang alat mana yang boleh memalsukan pengepala. Jika reka bentuk mengandaikan sebaliknya, andaian itu gagal pada pembekal pertama yang menapisnya. Tuliskan andaian itu supaya kegagalan dapat dikenali apabila tiba.

Putuskan mengikut protokol dan nama

Pilih proksi apabila satu klien web memerlukan satu perkhidmatan web dan ia mempunyai tetapan proksi. Pilih terowong SSH apabila beberapa perkhidmatan TCP yang diketahui sudah cukup dan akses SSH sudah ada. Pilih VPN apabila beberapa aplikasi, trafik bukan TCP, DNS peribadi atau laluan yang boleh diguna semula menjadi sebahagian daripada keperluan.

Kemudian sahkan dengan klien sebenar dan nama sebenar. Memuatkan halaman melalui proksi tidak mengajar anda apa-apa tentang UDP, dan menjalankan satu alat melalui SOCKS tidak mengajar anda apa-apa tentang penyelesai sistem. Baca alamat setempat mana yang diikat proses itu dan penyelesai mana yang menjawab. Itulah perbezaan antara laluan yang berfungsi dan laluan yang kebetulan berfungsi sekali.