Apakah ISP memblokir UDP, atau aplikasi di dalam terowongan?

Seseorang melaporkan bahwa VPN „memblokir UDP“, dan frasa itu menyembunyikan dua klaim yang sangat berbeda. Yang satu tentang transport yang dapat dilihat jaringan akses, yang lain tentang paket aplikasi setelah didekripsi di dalam terowongan. Terowongan terenkripsi dapat difilter dari luar tanpa kunci apa pun, dan aplikasi UDP dalam dapat gagal karena alasan yang tidak ada hubungannya dengan penyaringan. Tentukan klaim mana yang Anda uji sebelum mengumpulkan bukti.

Dua header, satu kata

Dalam penerapan IPsec dengan NAT-traversal, paket luar adalah UDP yang dialamatkan antara dua titik akhir VPN, biasanya pada porta 4500. Di dalamnya, muatan terenkripsi membawa apa pun yang diteruskan terowongan, yang bisa jadi TCP atau UDP. Jadi kata UDP muncul dua kali dengan makna dan keterlihatan yang berbeda.

Jaringan perantara melihat header luar dan tidak melihat apa pun dari header dalam. Jaringan itu dapat mengizinkan, membentuk, atau menjatuhkan aliran luar, dan tidak perlu mendekripsi apa pun untuk melakukannya. Asimetri itulah seluruh alasan kedua klaim tercampur: kata yang sama menggambarkan apa yang disaring jaringan dan apa yang dikirim aplikasi. Tuliskan lapisan di samping kata setiap kali Anda mencatat temuan, dan kebingungannya sebagian besar hilang.

Header dalam baru terlihat di titik akhir penerima, setelah dekripsi. Dari titik itu paket diteruskan seperti paket lain, tunduk pada rute, kebijakan, dan penyaringan titik akhir itu sendiri. Itu keputusan terpisah yang diambil oleh perangkat berbeda.

Apa yang masih bisa dilihat jaringan

Enkripsi menyembunyikan muatan dan header transport dalam, bukan fakta bahwa ada aliran. Alamat titik akhir, porta, ukuran paket, dan waktu tetap terlihat, dan itu cukup untuk mengklasifikasikan lalu lintas secara heuristik atau memblokir tujuan tertentu.

sudo tcpdump -ni eth0 'udp port 4500'
sudo tcpdump -ni tun0 'udp port 5201'

Tangkapan pertama menunjukkan aliran luar pada antarmuka fisik, dan yang kedua menunjukkan aliran dalam pada antarmuka terowongan. Menjalankan keduanya sekaligus menjawab pertanyaan itu secara langsung: jika aliran luar ada dan yang dalam tidak, aplikasi tidak pernah mengirim apa pun ke dalam terowongan. Jika keduanya ada dan tidak ada yang kembali, masalahnya ada di luar terowongan, di tujuan atau di jalur kembali.

RFC 3948 mendefinisikan enkapsulasi UDP luar, dan spesifikasi ESP mendefinisikan tata letak terlindungi di dalamnya. Tidak ada dari kedua dokumen itu yang menjanjikan bahwa jaringan akses akan melewatkan aliran luar, karena itu uji keterjangkauan pada tuple luar layak dijalankan sebelum teori apa pun tentang yang dalam. Tuple luar yang diblokir menghasilkan terowongan yang tidak pernah terbentuk, bukan terowongan yang terbentuk lalu kehilangan satu aplikasi.

Mengapa satu aplikasi UDP gagal di dalam terowongan yang berfungsi

Terowongan yang membawa aplikasi web tetapi tidak membawa aplikasi UDP punya beberapa penjelasan masuk akal, dan penyaringan protokol dalam oleh ISP bukan yang pertama. Yang paling umum adalah cakupan: kedua aplikasi tidak masuk ke terowongan yang sama, karena rute ke tujuan UDP tidak ada atau aturan terowongan terpisah klien mengecualikannya.

Yang kedua adalah titik akhir. Server VPN yang mengizinkan daftar protokol, firewall di tujuan, atau layanan yang tidak pernah mendengarkan pada porta yang diharapkan, semuanya akan menghasilkan waktu habis yang tampak identik dengan blokir jaringan.

Yang ketiga adalah ukuran paket. Aplikasi UDP sering mengirim datagram lebih besar daripada permintaan web, dan enkapsulasi mengurangi MTU yang dapat dipakai, sehingga setelah jabat tangan yang berhasil bisa menyusul kesunyian pada muatan berukuran penuh pertama. Pola itu mudah salah dibaca sebagai blokir, karena paket kecil berhasil dan paket besar menghilang. Pemeriksaan MTU singkat menyelesaikannya dalam waktu kurang dari satu menit, dan jawabannya biasanya muatan lebih kecil atau MSS yang dikoreksi, bukan filter jaringan.

ping -M do -s 1400 -c 2 10.60.0.20
iperf3 -u -c 10.60.0.20 -p 5201 -b 1M -t 5

Perintah pertama menguji apakah paket besar bertahan melewati jalur dengan fragmentasi dimatikan, yang cepat membuka masalah MTU. Yang kedua mengirim aliran UDP kecil yang terbatas dan melaporkan kehilangan serta jitter. Aliran yang mulai lalu macet menunjuk ke ukuran, bukan ke blokir.

Laporkan lapisannya, bukan protokolnya

Tulis temuan dalam salah satu dari tiga bentuk: pengiriman luar gagal, penerusan dalam gagal, atau aplikasi gagal. Masing-masing punya pemilik berbeda, dan mencampurnya mengirim tiket ke tim yang salah.

Mengubah porta lokal tidak dapat membuat pendengar yang cocok di ujung jauh, jadi akal-akalan di sisi klien yang tampak membantu biasanya menjadi bukti bahwa tujuan aslinya salah. Demikian pula, profil alternatif yang disediakan membuktikan sesuatu tentang keterjangkauan dan tidak membuktikan apa pun tentang benar tidaknya konfigurasi aplikasi.

Pisahkan inferensi dari pengamatan. Analisis lalu lintas dapat menyarankan apa itu suatu aliran tanpa mendekripsinya, dan itu temuan yang berguna, tetapi bukan klaim yang sama dengan membaca header dalam. Sebutkan mana yang benar-benar Anda miliki.