Reset TCP tidak membuktikan VPN Anda diblokir

“Koneksi direset, memulai ulang” muncul di log klien, dan kesimpulan datang sebelum bukti. Seseorang memutuskan bahwa jaringan memblokir VPN, atau sertifikatnya salah, atau negara tertentu ikut campur. Reset adalah paket TCP yang mengakhiri koneksi, dan baris log mencatat bahwa klien Anda menerima satu. Baris itu tidak menyebut perangkat yang mengirimnya atau alasannya.

Reset adalah paket, bukan putusan

TCP mendefinisikan pemrosesan reset: segmen dengan flag RST mengakhiri koneksi seketika. Penerima tidak bernegosiasi, tidak mencoba ulang, dan tidak bertanya mengapa. Ia melaporkan reset dan melanjutkan.

Itu saja yang diketahui klien. RST bisa datang dari server, proxy, firewall, atau penyeimbang beban yang kehilangan statusnya.

Atribusi adalah latihan tersendiri. Alamat sumber yang tampak dalam tangkapan bukan bukti asal fisik, dan tidak mengatakan apa pun tentang keputusan kebijakan di baliknya. Perangkat perantara dapat memalsukan alamat, dan perangkat berstatus dapat mereset karena waktu habis, bukan karena niat. Memperlakukan reset sebagai putusan melewati bagian tempat Anda menemukan kenyataannya.

Pastikan koneksi mana yang direset

Pertama periksa apakah profil aktif benar-benar memakai TCP. Reset pada terowongan UDP tidak masuk akal, dan log dari proxy HTTP bisa menyangkut bagian TCP yang berbeda dari VPN itu sendiri.

Catat tujuan, porta, waktu percobaan, dan tahap yang telah dicapai klien.

Tahap adalah bidang paling berguna. Reset selama jabat tangan TLS menunjuk pada satu kelompok tersangka; reset setelah autentikasi menunjuk pada kelompok lain. Tanpa tahap, setiap teori cocok.

Bandingkan kedua ujung jalur

Jika Anda mengelola server, bandingkan peristiwanya untuk percobaan yang sama. Apakah ia menerima koneksi? Apakah ia menutupnya dengan sengaja? Apakah balasan meninggalkan satu batas dan tidak pernah mencapai batas berikutnya?

Tangkap di klien dan di server jika bisa. Reset yang muncul di klien tetapi tidak di server tidak berasal dari server.

Perhatikan segmen RST di kedua arah:

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

Persempit dengan perbandingan terkendali

Jaringan kedua yang disetujui dapat memberi tahu apakah kegagalan mengikuti klien atau jalur. Jika profil yang sama berfungsi di tempat lain, konfigurasi klien kemungkinan baik-baik saja dan variabelnya adalah jalur.

Itu masih belum mengidentifikasi satu perangkat perantara. Itu mempersempit cakupan ke satu rute, yang merupakan hasil berguna dan jujur.

Pertahankan perbedaan antara jalur ini gagal dan aktor bernama ini yang menyebabkannya. Yang pertama dapat diuji; yang kedua biasanya tidak dari satu klien.

Periksa perbaikan tanpa mengubah pengaturan kepercayaan

Jangan menonaktifkan verifikasi TLS, jangan membuat ulang kredensial, dan jangan mengumumkan kebijakan pemblokiran dari satu baris reset. Setiap perubahan itu mengubah sistem yang diuji dan membuat perbandingan berikutnya tidak berarti.

Perbaiki komponen yang teridentifikasi melalui pemiliknya, lalu ulangi profil yang sama dan pengamatan yang sama:

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

Hasil yang berguna adalah kegagalan yang lebih terlokalisasi, bukan cerita yang lebih yakin. Jika reset hilang setelah perbaikan proxy, Anda punya penyebab. Jika ia berpindah ke tahap lain, Anda telah mempelajari sesuatu tentang jalur. Bagaimanapun, buktinya harus mampu bertahan dibaca orang kedua. Tuliskan apa yang Anda amati, bukan apa yang Anda simpulkan.