Masalah ISP - TCP Out-of-Order

Mengakses halaman web apa pun (pada dasarnya koneksi TCP apa pun), menghasilkan beberapa percobaan ulang sebelum dan waktu pemuatan yang lama sebelum memuat halaman dengan elemen yang hilang (memuat ulang mungkin memperbaikinya). Google Chrome melempar banyak PROTOCOL_QUIC_Error atau sejenisnya. Wireshark pada port 80 menunjukkan satu ton kesalahan TCP out of order untuk setiap upaya sebelum berhasil setelah beberapa kali mencoba.

Solusi temp saya: Saya menggunakan koneksi openvpn (lebih dari UDP) untuk mengatasi hal ini, dan itu lancar seperti sebelum saya mulai mendapatkan kesalahan ini.

Anehnya, bahkan pencarian DNS terkadang menjadi sangat lambat, tapi saya tahu ISP saya adalah pembajakan DNS (untuk portal login mereka - bahkan ketika menggunakan Google DNS). Koneksi UDP lainnya pada dasarnya sempurna (League of Legends, Openvpn atas UDP, Beberapa layanan streaming video, dll.)

Jadi, apakah masalah ini ada di pihak ISP? (mungkin firewall yang buruk atau sesuatu) atau ada hubungannya dengan router saya? (tapi tidak pernah mengalami masalah ini sebelumnya dan tidak ada perubahan pada konfigurasi LAN saya). Saya mendapat masalah yang sama dengan menghubungkan langsung dengan PC tanpa router. Bagaimana cara mengatasi ini (atau apa yang menyebabkan masalah seperti itu?), Selain menggunakan koneksi VPN eksternal?

networking openvpn tcp isp udp smallet
sumber

Jika Anda belum mengubah apa pun di konfigurasi Anda, maka masalahnya tidak bisa dengan apa pun di ujung Anda. Hubungi ISP dan tanya mereka tentang hal itu, sementara itu tetap gunakan VPN.

ztk

Ya, tapi ISP saya tidak pernah menanggapi pertanyaan teknis apa pun. Mereka memiliki routing yang mengerikan sebelumnya, dan mereka hanya menjawab dengan langkah pemecahan masalah stok. Ini akan membantu mengetahui jika ini terjadi karena beberapa kesalahan konfigurasi pada akhirnya, sehingga saya bisa bertanya kepada mereka sesuatu yang spesifik.

smallet

Jawaban:

Saya punya dua saran untuk Anda, mengatasi dua masalah berbeda.

Adapun pembajakan DNS, Anda mungkin ingin mencoba dnscrypt . Selain unduhan mereka (untuk Windows dan Mac) Anda akan menemukannya di sebagian besar repo Linux. Itu melakukan sesuatu yang cerdas, yaitu tidak hanya mengubah port (yang masih dapat dibajak karena identifikasi paket dapat dibuat berdasarkan protokol, bukan port), tetapi mengenkripsi Permintaan resolusi DNS, sehingga tidak ada teknik firewall yang dapat mengenali permintaan, bahkan yang tidak berdasarkan protokol.

Adapun masalah utama Anda, Anda telah mendiagnosisnya sendiri: itu ada di hulu Anda. Saya kadang-kadang melihat perilaku ini di Universitas saya, dan saya tahu pasti bahwa itu terhubung dengan beberapa masalah di router Cisco Class 6500 dan 7600 (satu lagi alasan untuk mencurigai ISP Anda, saya ragu Anda telah membayar beberapa ribu dolar yang diperlukan untuk dapatkan router tingkat industri ini).

Seorang pria dalam hutang saya. pecahkan masalah kita dengan mengikuti panduan ini . Di antara banyak hal menarik, dinyatakan:

Jika ini adalah TCP dan Anda mendapatkan kinerja yang buruk mempertimbangkan mengaktifkan sysoption dan penyelesaian unit, opsi ajaib ini meminta proses khusus yang dibuat untuk mengatasi skenario di mana FWSM dikenal untuk memperkenalkan paket tidak sesuai pesanan untuk aliran TCP.

FWSM adalah bilah firewall untuk router Cisco Class 6500 dan 7600.

Di sana Anda pergi dengan masalah, diagnosis, dan perawatan Anda. Ini yang terbaik yang bisa saya tawarkan.

MariusMatutiae
sumber

Wow, tidak tahu ada sesuatu seperti DNSCrypt. Pencarian jauh lebih cepat sekarang (bahkan dibandingkan dengan menggunakan OpenDNS / Google DNS secara langsung), meskipun sepertinya menggunakan TCP - 443. Namun hal firewall itu, saya sangat ragu ISP India saya akan meresponsnya. Sepertinya masalah utama yang harus dimiliki blade firewall, terlepas dari konfigurasi yang buruk. Kemudian lagi, saya tahu hampir tidak ada tentang perangkat keras jaringan kelas perusahaan!

smallet

@smallet Menggunakan 3 secara default karena umumnya, di belakang firewall atau proxy, jika mereka mengizinkan port 80 sama sekali, maka mereka selalu mengizinkan 3 (= https) juga.

MariusMatutiae