Set semula TCP tidak membuktikan VPN anda disekat

“Sambungan ditetapkan semula, memulakan semula” muncul dalam log klien, dan kesimpulan tiba sebelum bukti. Seseorang memutuskan bahawa rangkaian menyekat VPN, atau sijil itu salah, atau negara tertentu campur tangan. Set semula ialah paket TCP yang menamatkan sambungan, dan baris log merekodkan bahawa klien anda menerima satu. Ia tidak menamakan peranti yang menghantarnya atau sebabnya.

Set semula ialah paket, bukan penghakiman

TCP mentakrifkan pemprosesan set semula: segmen dengan bendera RST menamatkan sambungan serta-merta. Penerima tidak berunding, tidak mencuba semula dan tidak bertanya mengapa. Ia melaporkan set semula dan meneruskan.

Itu sahaja yang diketahui klien. RST mungkin datang daripada pelayan, proksi, tembok api atau pengimbang beban yang kehilangan keadaannya.

Atribusi ialah latihan berasingan. Alamat sumber yang kelihatan dalam tangkapan bukan bukti asal fizikal dan tidak menyatakan apa-apa tentang keputusan dasar di belakangnya. Peranti perantaraan boleh memalsukan alamat, dan peranti berkeadaan boleh menetapkan semula kerana tamat masa dan bukan kerana niat. Menganggap set semula sebagai penghakiman melangkau bahagian tempat anda mengetahui kebenarannya.

Sahkan sambungan mana yang ditetapkan semula

Pertama semak sama ada profil aktif benar-benar menggunakan TCP. Set semula pada terowong UDP tidak masuk akal, dan log daripada proksi HTTP mungkin berkaitan bahagian TCP yang berbeza daripada VPN itu sendiri.

Catat destinasi, port, masa percubaan dan peringkat yang telah dicapai oleh klien.

Peringkat ialah medan paling berguna. Set semula semasa jabat tangan TLS menunjuk kepada satu kumpulan suspek; set semula selepas pengesahan menunjuk kepada yang lain. Tanpa peringkat, setiap teori sesuai.

Bandingkan kedua-dua hujung laluan

Jika anda mentadbir pelayan, bandingkan peristiwanya untuk percubaan yang sama. Adakah ia menerima sambungan? Adakah ia menutupnya dengan sengaja? Adakah balasan meninggalkan satu sempadan dan tidak pernah tiba di sempadan seterusnya?

Tangkap di klien dan di pelayan jika boleh. Set semula yang muncul di klien tetapi tidak di pelayan tidak berasal dari pelayan.

Perhatikan segmen RST dalam kedua-dua arah:

sudo tcpdump -ni any 'tcp[tcpflags] & tcp-rst != 0' -c 20
ss -tnp | grep 198.51.100.20

Sempitkan dengan perbandingan terkawal

Rangkaian kedua yang diluluskan boleh memberitahu sama ada kegagalan mengikuti klien atau laluan. Jika profil yang sama berfungsi di tempat lain, konfigurasi klien mungkin baik dan pemboleh ubahnya ialah laluan.

Itu masih tidak mengenal pasti satu peranti perantaraan. Ia menyempitkan skop kepada satu laluan, yang merupakan hasil berguna dan jujur.

Kekalkan perbezaan antara laluan ini gagal dan pelaku bernama ini yang menyebabkannya. Yang pertama boleh diuji; yang kedua biasanya tidak daripada satu klien.

Semak pembetulan tanpa mengubah tetapan kepercayaan

Jangan lumpuhkan pengesahan TLS, jangan jana semula kelayakan dan jangan mengumumkan dasar penyekatan daripada satu baris set semula. Setiap perubahan itu mengubah sistem yang diuji dan menjadikan perbandingan seterusnya tidak bermakna.

Betulkan komponen yang dikenal pasti melalui pemiliknya, kemudian ulangi profil yang sama dan pemerhatian yang sama:

openvpn --config client.ovpn --verb 4
sudo tcpdump -ni any 'host 198.51.100.20 and tcp' -c 40

Hasil yang berguna ialah kegagalan yang lebih setempat, bukan cerita yang lebih yakin. Jika set semula hilang selepas pembetulan proksi, anda mempunyai punca. Jika ia berpindah ke peringkat lain, anda telah mempelajari sesuatu tentang laluan. Walau apa pun, bukti itu harus mampu bertahan dibaca oleh orang kedua. Tuliskan apa yang anda perhatikan, bukan apa yang anda simpulkan.