Proxy HTTP, Tunnel SSH, atau VPN: pilih lapisan yang tepat

Tanyakan kepada tiga insinyur bagaimana mencapai layanan internal dan Anda akan mendapat tiga rancangan: proxy web, tunnel SSH, atau VPN penuh. Ketiganya dapat mendekatkan layanan jarak jauh, dan ketiganya dapat membuat lalu lintas tampak datang dari tempat lain. Perbedaannya muncul kemudian, ketika protokol yang dipakai bukan yang diasumsikan alat terpilih. Rancangan yang lolos pemeriksaan peramban cepat biasanya gagal pada aplikasi yang memicu permintaan itu.

Putuskan dari dua fakta: protokol mana yang harus menyeberang, dan siapa yang dapat menyelesaikan nama terkait. Sisanya soal preferensi.

Proxy hanya memindahkan apa yang dipahaminya

Proxy web mengurai protokol yang menjadi tujuan pembuatannya. Klien menyerahkan permintaan kepadanya dan ia meneruskan permintaan itu, sehingga aplikasi tanpa pengaturan proxy sama sekali tidak ikut serta. Untuk HTTPS klien memerlukan saluran buram, yang disediakan proxy melalui CONNECT alih-alih membaca permintaan.

Penerusan dinamis SSH membuka port lokal yang berbicara SOCKS, dan port itu meneruskan aliran TCP ke tujuan mana pun yang disebut klien. Protokol yang dibangun di atas TCP umumnya bekerja melaluinya. UDP tidak, kecuali suatu alat menambahkan dukungan secara eksplisit. Penerusan lokal bahkan lebih sempit: satu port lokal dipetakan ke satu host dan port tetap, yang melayani satu layanan dikenal dan tidak lebih.

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

VPN memindahkan paket. Semua yang dirutekan klien ke dalam tunnel melewatinya, termasuk UDP dan ICMP, karena itu cocok untuk kebutuhan jaringan, bukan satu koneksi.

Seseorang harus menyelesaikan nama itu

Ketika nama tujuan hanya ada di DNS jaringan jarak jauh, mesin yang melakukan pencarian harus dapat melihat zona itu. Proxy web melakukan pencarian sendiri, sehingga nama internal bekerja melaluinya bahkan ketika laptop sama sekali tidak dapat menyelesaikan nama. SOCKS dapat berperilaku sama, tetapi hanya jika klien meneruskan nama alih-alih menghubungkan ke alamat yang sudah diselesaikannya. Pilihan itu ada di klien, bukan di server.

curl memperlihatkan pemisahan itu dengan jelas: satu tanda meneruskan nama host ke proxy, tanda lain menyelesaikannya secara lokal lebih dulu. Dengan penyelesaian lokal, nama yang hanya internal gagal sebelum tunnel mana pun tersentuh, dan galatnya menyalahkan proxy atas apa yang sebenarnya keputusan DNS.

VPN mengambil jalur ketiga dengan memasang penyelesai privat dan domain pencarian di samping rute. Itu nyaman, dan menciptakan ilusi yang akrab: rute yang ada bersama penyelesai yang tidak menjawab tampak persis seperti tunnel mati, meski paket sampai ke sisi seberang.

Ketika jaringan hanya mengizinkan satu pintu keluar

Banyak jaringan korporat hanya mengizinkan koneksi keluar melalui proxy web yang terautentikasi. OpenVPN dan SSH keduanya dapat dibuat bekerja di sana, yang pertama dengan menerowongkan transportnya sendiri melalui proxy dan yang kedua melalui perintah proxy yang menjalankan pembantu CONNECT kecil.

Tunnel yang dibangun di atas TCP bertahan pada batasan itu, dan VPN berbasis UDP tidak, yang menjelaskan sangat banyak konfigurasi yang bekerja di rumah dan gagal di kantor. Biaya kedua mudah terlewat: tunnel TCP yang dibawa di dalam koneksi TCP melalui proxy kini memiliki dua lapisan yang mengirim ulang, dan di bawah kehilangan pasangan itu macet dengan cara yang tidak dihasilkan satu lapisan pun sendirian.

Merangkai perantara adalah pertanyaan berbeda dari memilih lapisan. Menambahkan proxy kedua atau Tor mengubah siapa mengamati apa, dan posisi dalam rantai menentukan hop mana yang melihat teks tersandi.

Urutan lebih penting daripada jumlah hop. Hop luar mengamati aliran tersandi sementara hop dalam melihat teks terang yang dibawanya, jadi rantai hanya seprivat tautan yang paling tidak cermat. Mencampur protokol antar hop tidak otomatis memperbaikinya. Itu terutama membuat mode kegagalan lebih sulit dipikirkan.

Alamat palsu bukan salah satu pilihan

Membuat paket dengan alamat sumber orang lain tidak mencapai apa pun yang berguna: balasan menuju pemilik sebenarnya, dan sebagian besar jaringan membuang lalu lintas itu mentah-mentah. Perantara diperlukan justru karena sumber tidak dapat diciptakan, dan itulah pembenaran jujur bagi ketiga rancangan.

Itu juga membatasi apa yang boleh diklaim masing-masing. Tampak berasal dari alamat tertentu adalah pertanyaan tentang di mana alamat itu dialokasikan secara sah dan siapa yang boleh merutekannya, bukan tentang alat mana yang dapat memalsukan tajuk. Jika suatu rancangan mengasumsikan sebaliknya, asumsi itu gagal pada penyedia pertama yang menyaringnya. Tuliskan asumsinya agar kegagalan dapat dikenali saat datang.

Putuskan berdasarkan protokol dan nama

Pilihlah proxy ketika satu klien web membutuhkan satu layanan web dan memiliki pengaturan proxy. Pilihlah tunnel SSH ketika beberapa layanan TCP dikenal sudah cukup dan akses SSH sudah ada. Pilihlah VPN ketika beberapa aplikasi, lalu lintas non-TCP, DNS privat, atau jalur yang dapat dipakai ulang menjadi bagian dari kebutuhan.

Lalu verifikasi dengan klien sebenarnya dan nama sebenarnya. Memuat halaman melalui proxy tidak mengajarkan apa pun tentang UDP, dan menjalankan satu alat melalui SOCKS tidak mengajarkan apa pun tentang penyelesai sistem. Bacalah alamat lokal mana yang diikat proses dan penyelesai mana yang menjawab. Itulah beda antara jalur yang bekerja dan jalur yang kebetulan bekerja sekali.