Mengapa banyak koneksi aplikasi berbagi satu sesi OpenVPN

Bayangkan sebuah peramban memuat halaman HTTPS sementara klien SSH menjangkau server lain dan resolver menjawab sebuah kueri, semuanya melalui satu sesi OpenVPN. Di antarmuka fisik Anda melihat satu percakapan; di dalam terowongan Anda melihat tiga. Kedua pandangan benar, dan mengetahui mengapa adalah pembeda antara tangkapan yang berguna dan yang membingungkan. Ikuti satu aliran dalam dari soket sampai kabel dan pelapisan berhenti menjadi abstrak.

Satu percakapan luar, banyak aliran dalam

Setiap aplikasi membuka soketnya sendiri, dan kernel memberinya tuple lima elemen: alamat sumber, port sumber, alamat tujuan, port tujuan, dan protokol. Tuple itu sudah ada sebelum terowongan apa pun terlibat. Perutean lalu memutuskan bahwa semuanya keluar melalui perangkat terowongan, sehingga paket yang diserahkan kepada OpenVPN masih membawa header asli di dalamnya. OpenVPN mengenkripsi paket dalam itu dan membungkus hasilnya dalam satu percakapan UDP atau TCP luar dengan rekan. Karena itu percakapan luarnya satu, sedangkan aliran di dalamnya sebanyak aplikasi yang dibuka.

Tidak ada yang runtuh. Tuple dalam bertahan dari ujung ke ujung, dan itulah sebabnya sisi jauh masih dapat membedakan ketiga aliran.

Port yang tetap

Yang tetap konstan adalah tuple luar: alamat Anda, port lokal yang diikat klien, alamat rekan, dan port layanan yang dikonfigurasi. Tuple itulah yang harus diizinkan oleh firewall atau NAT di jalur, dan itulah yang akan ditampilkan tangkapan di uplink. Itu juga yang berubah setelah koneksi ulang atau pergantian jaringan, karena klien bisa mengikat port lokal lain. Satu terowongan tidak berarti satu port sumber tetap selamanya.

Port dalam adalah yang dipedulikan titik akhir. Aliran HTTPS mempertahankan port tujuan 443 di dalam terowongan meskipun transport luar duduk di port yang dikonfigurasi operator. Titik akhir aplikasi tidak pernah tahu tentang yang luar.

Apa yang diubah dekapsulasi di ujung jauh

Di rekan, lapisan luar dilepas, dan paket dalam adalah yang tersisa. Dari sana, penerusan dan kebijakan akses berlaku pada tujuan dan protokol dalam. Server web tetap menerima koneksi HTTPS, daemon SSH tetap menerima SSH, dan resolver tetap menerima kueri.

Itulah sebabnya aturan yang mengizinkan transport luar bukan aturan yang sama dengan mengizinkan layanan internal. Yang pertama menjelaskan jalur; yang kedua menjelaskan otorisasi.

TCP luar berarti satu aliran, bukan satu koneksi

Ketika transport luar adalah UDP, nasib setiap aliran dalam independen: datagram yang hilang memengaruhi satu transfer sampai pengiriman ulangnya sendiri. Ketika transport luar adalah TCP, semua aliran dalam berbagi satu aliran byte yang andal.

Aliran bersama itulah bagian yang orang lewatkan. Pemulihan terjadi sekali, untuk semuanya, sehingga satu segmen hilang menunda lalu lintas setiap aplikasi yang dimultipleks di dalamnya. Masih banyak koneksi di titik akhir dan satu koneksi di kabel, dan di kabellah efek kepala antrean hidup. Jumlah port yang mendengarkan tidak memberi tahu Anda apa pun tentang ini, dan itulah sebabnya menghitung port adalah cara yang buruk untuk menalar kinerja terowongan.

Jelaskan penyiapan Anda sendiri dengan tepat

Sebutkan lalu lintas dalam yang dipilih dan transport luar tertentu yang membawanya, alih-alih mengatakan mesin mengirim semuanya melalui satu port. Layanan lokal, terowongan kedua, dan keluarga alamat lain semuanya menciptakan aliran yang tidak pernah masuk ke percakapan ini. Tangkapan di uplink menunjukkan tuple luar; tangkapan di dalam terowongan menunjukkan yang dalam.

Ambil keduanya, dan letakkan stempel waktu berdampingan. Jika Anda perlu membuktikan aplikasi mana yang menghasilkan aliran dalam mana, tabel soket di host adalah instrumen yang lebih baik, karena memetakan port ke proses secara langsung. Lalu catat tuple luar yang Anda amati dan saat Anda mengamatinya, karena tangkapan berikutnya setelah koneksi ulang bisa sah-sah saja menunjukkan angka yang berbeda.