Adakah ISP menyekat UDP, atau aplikasi di dalam terowong?
ISP boleh menggugurkan pengangkutan UDP luar tanpa membaca pengepala dalam yang disulitkan. Asingkan penghantaran luar, pemajuan dalam dan tingkah laku aplikasi.
Seseorang melaporkan bahawa VPN „menyekat UDP“, dan frasa itu menyembunyikan dua dakwaan yang sama sekali berbeza. Satu tentang pengangkutan yang boleh dilihat oleh rangkaian capaian, satu lagi tentang paket aplikasi selepas dinyahsulit di dalam terowong. Terowong yang disulitkan boleh ditapis dari luar tanpa sebarang kunci, dan aplikasi UDP dalaman boleh gagal atas sebab yang tidak ada kaitan dengan penapisan. Tentukan dakwaan mana yang anda uji sebelum mengumpul bukti.
Dua pengepala, satu perkataan
Dalam penggunaan IPsec dengan NAT-traversal, paket luar ialah UDP yang dialamatkan antara dua titik akhir VPN, biasanya pada port 4500. Di dalamnya, muatan yang disulitkan membawa apa sahaja yang dipajukan oleh terowong, yang mungkin juga TCP atau UDP. Jadi perkataan UDP muncul dua kali dengan makna dan keterlihatan yang berbeza.
Rangkaian perantaraan melihat pengepala luar dan tiada apa-apa daripada yang dalam. Ia boleh membenarkan, membentuk atau menggugurkan aliran luar, dan ia tidak perlu menyahsulit apa-apa untuk berbuat demikian. Asimetri itulah sebab utama kedua-dua dakwaan dikelirukan: perkataan yang sama menerangkan apa yang ditapis oleh rangkaian dan apa yang dihantar oleh aplikasi. Tulis lapisan di sebelah perkataan setiap kali anda merekod penemuan, dan kekeliruan itu kebanyakannya hilang.
Pengepala dalam hanya kelihatan di titik akhir penerima, selepas dinyahsulit. Dari titik itu paket dipajukan seperti mana-mana paket lain, tertakluk kepada laluan, dasar dan penapisan titik akhir itu sendiri. Itu keputusan berasingan yang dibuat oleh peranti berbeza.
Apa yang masih boleh dilihat oleh rangkaian
Penyulitan menyembunyikan muatan dan pengepala pengangkutan dalam, bukan fakta bahawa aliran wujud. Alamat titik akhir, port, saiz paket dan masa kekal kelihatan, dan itu cukup untuk mengelaskan trafik secara heuristik atau menyekat destinasi tertentu.
sudo tcpdump -ni eth0 'udp port 4500' sudo tcpdump -ni tun0 'udp port 5201'
Tangkapan pertama menunjukkan aliran luar pada antara muka fizikal, dan yang kedua menunjukkan aliran dalam pada antara muka terowong. Menjalankan kedua-duanya serentak menjawab soalan itu secara langsung: jika aliran luar wujud dan yang dalam tidak, aplikasi tidak pernah menghantar apa-apa ke dalam terowong. Jika kedua-duanya wujud dan tiada apa yang kembali, masalahnya berada di luar terowong, di destinasi atau di laluan balik.
RFC 3948 mentakrifkan enkapsulasi UDP luar, dan spesifikasi ESP mentakrifkan susun atur terlindung di dalamnya. Tiada satu pun daripada kedua-dua dokumen itu menjanjikan bahawa rangkaian capaian akan melalukan aliran luar, sebab itu ujian kebolehcapaian pada tuple luar wajar dijalankan sebelum sebarang teori tentang yang dalam. Tuple luar yang disekat menghasilkan terowong yang tidak pernah terbentuk, bukan terowong yang terbentuk dan kemudian kehilangan satu aplikasi.
Mengapa satu aplikasi UDP gagal di dalam terowong yang berfungsi
Terowong yang membawa aplikasi web tetapi tidak membawa aplikasi UDP mempunyai beberapa penjelasan yang munasabah, dan penapisan protokol dalam oleh ISP bukanlah yang pertama. Yang paling biasa ialah liputan: kedua-dua aplikasi tidak masuk ke dalam terowong yang sama, kerana laluan ke destinasi UDP tiada atau peraturan terowong berpecah pelanggan mengecualikannya.
Yang kedua ialah titik akhir. Pelayan VPN yang membenarkan senarai protokol, tembok api di destinasi, atau perkhidmatan yang tidak pernah mendengar pada port yang dijangka, semuanya akan menghasilkan tamat masa yang kelihatan sama seperti sekatan rangkaian.
Yang ketiga ialah saiz paket. Aplikasi UDP sering menghantar datagram yang lebih besar daripada permintaan web, dan enkapsulasi mengurangkan MTU yang boleh digunakan, jadi selepas jabat tangan yang berjaya boleh menyusul kesunyian pada muatan bersaiz penuh pertama. Corak itu mudah disalah baca sebagai sekatan, kerana paket kecil berjaya dan paket besar hilang. Semakan MTU pantas menyelesaikannya dalam masa kurang seminit, dan jawapannya biasanya muatan yang lebih kecil atau MSS yang dibetulkan, bukan penapis rangkaian.
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 sama ada paket besar bertahan melalui laluan dengan pemecahan dimatikan, yang mendedahkan masalah MTU dengan cepat. Yang kedua menghantar aliran UDP kecil yang terbatas dan melaporkan kehilangan serta jitter. Aliran yang bermula kemudian tersekat menunjukkan saiz, bukan sekatan.
Laporkan lapisan, bukan protokol
Tulis penemuan dalam salah satu daripada tiga bentuk: penghantaran luar gagal, pemajuan dalam gagal, atau aplikasi gagal. Setiap satu mempunyai pemilik berbeza, dan mencampurkannya menghantar tiket kepada pasukan yang salah.
Menukar port setempat tidak boleh mencipta pendengar yang sepadan di hujung jauh, jadi penyelesaian sementara di sebelah klien yang kelihatan membantu biasanya menjadi bukti bahawa destinasi asal adalah salah. Begitu juga, profil alternatif yang dibekalkan membuktikan sesuatu tentang kebolehcapaian dan tiada apa-apa tentang sama ada aplikasi dikonfigurasikan dengan betul.
Asingkan inferens daripada pemerhatian juga. Analisis trafik boleh mencadangkan apa itu aliran tanpa menyahsulitnya, dan itu penemuan yang berguna, tetapi ia bukan dakwaan yang sama dengan membaca pengepala dalam. Nyatakan yang mana satu yang sebenarnya anda ada.