การรีเซ็ต TCP ไม่ได้พิสูจน์ว่า VPN ของคุณถูกบล็อก

ข้อความ «การเชื่อมต่อถูกรีเซ็ต กำลังเริ่มใหม่» ปรากฏในบันทึกของไคลเอนต์ และข้อสรุปมาก่อนหลักฐาน มีคนตัดสินว่าเครือข่ายบล็อก VPN หรือใบรับรองผิด หรือประเทศใดประเทศหนึ่งแทรกแซง การรีเซ็ตคือแพ็กเก็ต TCP ที่สิ้นสุดการเชื่อมต่อ และบรรทัดบันทึกระบุว่าไคลเอนต์ของคุณได้รับหนึ่งแพ็กเก็ต มันไม่ได้ระบุอุปกรณ์ที่ส่งหรือเหตุผล

การรีเซ็ตคือแพ็กเก็ต ไม่ใช่คำตัดสิน

TCP กำหนดการประมวลผลการรีเซ็ต: ส่วนที่มีแฟล็ก RST จะสิ้นสุดการเชื่อมต่อทันที ผู้รับไม่เจรจา ไม่ลองใหม่ และไม่ถามว่าทำไม มันรายงานการรีเซ็ตแล้วไปต่อ

นั่นคือทั้งหมดที่ไคลเอนต์รู้ RST อาจมาจากเซิร์ฟเวอร์ พร็อกซี ไฟร์วอลล์ หรือตัวกระจายโหลดที่สูญเสียสถานะ

การระบุที่มาเป็นแบบฝึกหัดแยกต่างหาก ที่อยู่ต้นทางที่เห็นในการดักจับไม่ใช่หลักฐานของต้นกำเนิดทางกายภาพ และไม่ได้บอกอะไรเกี่ยวกับการตัดสินใจเชิงนโยบายเบื้องหลัง อุปกรณ์กลางทางสามารถปลอมแปลงที่อยู่ได้ และอุปกรณ์ที่มีสถานะสามารถรีเซ็ตเพราะหมดเวลาแทนที่จะตั้งใจ การถือว่าการรีเซ็ตเป็นคำตัดสินจะข้ามส่วนที่คุณค้นหาความจริง

ยืนยันว่าการเชื่อมต่อใดถูกรีเซ็ต

ก่อนอื่นตรวจสอบว่าโปรไฟล์ที่ใช้งานอยู่ใช้ TCP จริงหรือไม่ การรีเซ็ตบนอุโมงค์ UDP ไม่สมเหตุสมผล และบันทึกของพร็อกซี HTTP อาจเกี่ยวกับส่วน TCP อื่นที่ไม่ใช่ตัว VPN เอง

บันทึกปลายทาง พอร์ต เวลาที่พยายาม และขั้นตอนที่ไคลเอนต์ไปถึง

ขั้นตอนเป็นฟิลด์ที่มีประโยชน์ที่สุด การรีเซ็ตระหว่างการจับมือ TLS ชี้ไปที่กลุ่มผู้ต้องสงสัยกลุ่มหนึ่ง การรีเซ็ตหลังการยืนยันตัวตนชี้ไปที่อีกกลุ่มหนึ่ง หากไม่มีขั้นตอน ทุกทฤษฎีก็เข้ากันได้

เปรียบเทียบทั้งสองปลายของเส้นทาง

หากคุณดูแลเซิร์ฟเวอร์ ให้เปรียบเทียบเหตุการณ์ของมันสำหรับความพยายามเดียวกัน มันยอมรับการเชื่อมต่อหรือไม่ มันปิดมันโดยเจตนาหรือไม่ คำตอบออกจากขอบเขตหนึ่งและไม่เคยไปถึงขอบเขตถัดไปหรือไม่

ดักจับที่ไคลเอนต์และที่เซิร์ฟเวอร์หากทำได้ การรีเซ็ตที่ปรากฏที่ไคลเอนต์แต่ไม่ปรากฏที่เซิร์ฟเวอร์ไม่ได้เกิดขึ้นที่เซิร์ฟเวอร์

ระวังส่วน RST ในทั้งสองทิศทาง:

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

จำกัดขอบเขตด้วยการเปรียบเทียบที่ควบคุมได้

เครือข่ายที่ได้รับอนุมัติแห่งที่สองสามารถบอกได้ว่าความล้มเหลวตามไคลเอนต์หรือตามเส้นทาง หากโปรไฟล์เดียวกันทำงานที่อื่น การกำหนดค่าไคลเอนต์น่าจะปกติ และตัวแปรคือเส้นทาง

นี่ยังไม่ได้ระบุอุปกรณ์กลางทางตัวใดตัวหนึ่ง มันจำกัดขอบเขตให้เหลือเส้นทางเดียว ซึ่งเป็นผลลัพธ์ที่มีประโยชน์และซื่อสัตย์

รักษาความแตกต่างระหว่าง «เส้นทางนี้ล้มเหลว» กับ «ผู้กระทำที่ระบุชื่อนี้ทำให้เกิดขึ้น» อย่างแรกทดสอบได้ อย่างหลังโดยปกติไม่ได้จากไคลเอนต์เดียว

ตรวจสอบการแก้ไขโดยไม่เปลี่ยนการตั้งค่าความเชื่อถือ

อย่าปิดการตรวจสอบ TLS อย่าสร้างข้อมูลรับรองใหม่ และอย่าประกาศนโยบายการบล็อกจากบรรทัดการรีเซ็ตบรรทัดเดียว การเปลี่ยนแปลงแต่ละอย่างเหล่านี้เปลี่ยนระบบที่กำลังทดสอบและทำให้การเปรียบเทียบครั้งถัดไปไม่มีความหมาย

แก้ไของค์ประกอบที่ระบุผ่านเจ้าของ แล้วทำซ้ำโปรไฟล์เดิมและการสังเกตเดิม:

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

ผลลัพธ์ที่มีประโยชน์คือความล้มเหลวที่ระบุตำแหน่งได้ดีขึ้น ไม่ใช่เรื่องเล่าที่มั่นใจกว่า หากการรีเซ็ตหายไปหลังแก้ไขพร็อกซี คุณมีสาเหตุ หากมันย้ายไปขั้นตอนอื่น คุณได้เรียนรู้บางอย่างเกี่ยวกับเส้นทาง ไม่ว่าอย่างไร หลักฐานควรทนต่อการอ่านของบุคคลที่สอง จดสิ่งที่คุณสังเกต ไม่ใช่สิ่งที่คุณสรุป