DNS ผ่านพรอกซี: socks5 vs socks5h, การแก้ไข DNS จากระยะไกล และการรั่วไหล

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

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

บทนำ: ทำไมพรอกซีเชื่อมต่อแล้ว แต่เว็บไซต์กลับเห็นภูมิภาคอื่น

มาเริ่มกันที่อาการที่ทำให้ผู้อ่านส่วนใหญ่มาที่หัวข้อนี้ คุณตั้งค่าพรอกซีแล้ว ที่อยู่ IP ถูกเปลี่ยนอย่างถูกต้อง - ง่ายต่อการตรวจสอบจากบริการตรวจสอบ IP ใดๆ แต่ก็ยังมีอะไรบางอย่างผิดปกติ: เว็บไซต์แสดง localization ของประเทศอื่น, CDN ส่งคุณไปยังโหนดที่ไม่คาดคิด และบางครั้งระบบความปลอดภัยของทรัพยากรเป้าหมายก็บล็อกคำขอโดยไม่มีเหตุผลชัดเจน

สาเหตุเกือบจะเหมือนกันเสมอ ทราฟฟิก HTTP หรือแอปพลิเคชันของคุณผ่านพรอกซีจริง แต่ คำขอ DNS - คำขอที่แปลงชื่อเช่น example.com เป็นที่อยู่ IP เฉพาะ - กลับออกไปนอกพรอกซีโดยตรงจากเครื่องของคุณ และคำขอนี้เปิดเผยตัวตนของคุณอย่างชัดเจน

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

เมื่ออ่านเนื้อหานี้จบ คุณจะเข้าใจ:

• ใครเป็นผู้ดำเนินการแก้ไขชื่อ - ระบบปฏิบัติการ, ไลบรารีของแอปพลิเคชัน, เบราว์เซอร์ หรือพรอกซีเซิร์ฟเวอร์เอง
• โครงสร้าง socks5 แตกต่างจาก socks5h ในระดับโปรโตคอลอย่างไร และทำไมตัวอักษรเดียวถึงเปลี่ยนทุกอย่าง
• วิธีการ CONNECT ใน HTTP-พรอกซีแก้ปัญหาการแก้ไขชื่อได้เกือบอัตโนมัติอย่างไร
• ช่องทางใดบ้างที่ DNS รั่วไหลได้แม้จะตั้งค่าอย่างถูกต้องแล้ว
• วิธีเปิดใช้งานการแก้ไข DNS จากระยะไกลใน curl, Python, Node.js, Go, Chrome, Firefox, Selenium และ Playwright
• วิธีตรวจสอบเส้นทางการแก้ไขจริงด้วยเครื่องมือเช่น dig, nslookup และ tcpdump

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

พื้นฐาน: การแก้ไขชื่อโดเมนคืออะไรและใครเป็นคนทำ

เพื่อให้เข้าใจการรั่วไหล เราต้องเข้าใจกลไกการแก้ไขชื่ออย่างถ่องแท้ก่อน มาแยกแยะกัน

การแก้ไขชื่อโดเมนคืออะไร

คอมพิวเตอร์สื่อสารกันด้วยที่อยู่ IP แต่มนุษย์ใช้ชื่อ การแก้ไขชื่อ (resolve) คือกระบวนการแปลงชื่อที่มนุษย์อ่านได้ เช่น shop.example.com เป็นที่อยู่ IP ของเครื่อง เช่น 93.184.216.34 หากไม่มีขั้นตอนนี้ การเชื่อมต่อใดๆ ก็เป็นไปไม่ได้: เบราว์เซอร์ไม่รู้ว่าจะเชื่อมต่อกับเซิร์ฟเวอร์ไหนจนกว่าจะได้ IP มา

การแก้ไขชื่อเป็นธุรกรรมเครือข่ายที่แยกต่างหาก โดยปกติจะใช้โปรโตคอล DNS ผ่าน UDP หรือ TCP ที่พอร์ต 53 ไคลเอนต์ส่งคำขอไปยัง resolver, resolver ส่งคำตอบกลับ ประเด็นสำคัญคือ ใครเป็นคนส่งคำขอนี้และผ่านเส้นทางไหน ซึ่งเป็นคำถามหลักของหัวข้อทั้งหมดของเรา

ผู้ดำเนินการแก้ไขชื่อสี่รายที่เป็นไปได้

เมื่อแอปพลิเคชันต้องการติดต่อ example.com การแก้ไขสามารถทำได้โดยหนึ่งในสี่ฝ่าย มาดูแต่ละฝ่าย

1. ระบบปฏิบัติการ

แอปพลิเคชันส่วนใหญ่ไม่ได้แก้ไขชื่อด้วยตัวเอง พวกเขาเรียกใช้ฟังก์ชันของระบบ - ในโลกของ C คือ getaddrinfo ระบบปฏิบัติการมี resolver ของตัวเอง (stub resolver) ที่รู้ว่าจะติดต่อ DNS เซิร์ฟเวอร์ไหน เก็บแคชในเครื่อง และคำนึงถึงไฟล์ hosts นี่เป็นเส้นทางที่พบบ่อยที่สุด และอันตรายที่สุดในแง่ของการรั่วไหล: resolver ของระบบโดยค่าเริ่มต้นจะออกไปยังเครือข่ายโดยตรง โดยไม่สนใจพรอกซีของคุณ

2. ไลบรารีของแอปพลิเคชัน

โปรแกรมและไลบรารีบางตัวมีตรรกะการแก้ไขเป็นของตัวเอง ซึ่งอาจมอบหมายงานให้ระบบปฏิบัติการ, ดำเนินการเอง หรือ - ที่สำคัญที่สุด - ส่งชื่อไปยังพรอกซีเซิร์ฟเวอร์ เพื่อให้การแก้ไขเกิดขึ้นที่ฝั่งระยะไกล กลไกนี้คือสิ่งที่ socks5h และ proxy-hosting ใช้งาน

3. เบราว์เซอร์

เบราว์เซอร์สมัยใหม่เป็นจักรวาลที่แยกออกไปต่างหาก พวกเขามีนโยบายการแก้ไขของตัวเอง, แคช DNS ของตัวเอง, กลไกเช่น DoH (DNS over HTTPS), การโหลดล่วงหน้า, และ WebRTC เบราว์เซอร์สามารถแก้ไขชื่อโดยไม่ขึ้นกับการตั้งค่าระบบ ทำให้เกิดการรั่วไหลอีกประเภทหนึ่ง

4. พรอกซีเซิร์ฟเวอร์เอง

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

การเปรียบเทียบที่สำคัญ

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

socks5 กับ socks5h: การตัดสินใจแก้ไขชื่อเกิดขึ้นที่ไหน

ตอนนี้เรามาถึงหัวใจของหัวข้อแล้ว ความแตกต่างระหว่าง socks5 และ socks5h ไม่ใช่แค่เรื่องความสวยงามหรือคำพ้องความหมาย มันเป็นเส้นทางการแก้ไขที่แตกต่างกันโดยพื้นฐาน แม้ว่าโปรโตคอล SOCKS5 ภายในจะเหมือนกัน

โปรโตคอล SOCKS5 กล่าวว่าอย่างไร

โปรโตคอล SOCKS5 มีความยืดหยุ่น ในคำสั่งสร้างการเชื่อมต่อ ไคลเอนต์จะระบุประเภทของที่อยู่ปลายทาง มีสามตัวเลือก:

• ที่อยู่ IPv4 - ไคลเอนต์ส่ง IP ที่พร้อมแล้ว
• ที่อยู่ IPv6 - เหมือนกัน แต่สำหรับ IPv6
• ชื่อโดเมน - ไคลเอนต์ส่งสตริงชื่อ แล้วพรอกซีเซิร์ฟเวอร์ต้องทำการแก้ไข

นั่นคือโปรโตคอลรองรับทั้งการแก้ไขในเครื่องและระยะไกล ปัญหาอยู่ที่ว่าไคลเอนต์จะส่งที่อยู่ประเภทไหน และนี่คือจุดที่ข้อตกลงในการตั้งชื่อ схемเข้ามามีบทบาท

scheme socks5: การแก้ไขในเครื่อง

เมื่อไคลเอนต์ใช้ scheme socks5 (ไม่มีตัวอักษร h) ตามธรรมเนียมที่ยอมรับกันหมายความว่า: แก้ไขชื่อในเครื่อง ไคลเอนต์จะถาม resolver ของมันก่อน (โดยปกติคือระบบ) ว่า example.com มี IP อะไร ได้ที่อยู่มา แล้วจึงส่งที่อยู่ IPv4 หรือ IPv6 ที่พร้อมแล้วให้พรอกซีเซิร์ฟเวอร์

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

scheme socks5h: การแก้ไขจากระยะไกล

ตัวอักษร h ใน socks5h หมายถึง hostname - ชื่อโฮสต์ scheme นี้บอกไคลเอนต์: อย่าแก้ไขด้วยตัวเอง ส่งชื่อไปให้พรอกซีเซิร์ฟเวอร์ ไคลเอนต์ส่งคำสั่งที่มีประเภทที่อยู่เป็นชื่อโดเมน และพรอกซีเซิร์ฟเวอร์ทำการแก้ไขที่ฝั่งของมัน

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

ตารางเปรียบเทียบกลไก

รวบรวมความแตกต่างในรูปแบบกระชับ:

• socks5: การแก้ไขทำโดยไคลเอนต์ (OS/ไลบรารี) พรอกซีได้รับ IP คำขอ DNS มาจากเครือข่ายของคุณ อาจเกิดความไม่สอดคล้องทางภูมิศาสตร์และการรั่วไหล
• socks5h: การแก้ไขทำโดยพรอกซี พรอกซีได้รับชื่อ คำขอ DNS มาจากเครือข่ายของพรอกซี ภูมิภาคสอดคล้องกัน ไม่มีการรั่วไหล

จำกฎง่ายๆ: ถ้าความเป็นส่วนตัวและความถูกต้องของตำแหน่งทางภูมิศาสตร์สำคัญ - ให้ใช้ socks5h เสมอ ตัวอักษรตัวเดียวช่วยประหยัดเวลาการดีบักเป็นชั่วโมง

ทำไมถึงเป็นธรรมเนียมนี้

ข้อมูลทางประวัติศาสตร์มีประโยชน์เพื่อความเข้าใจ เดิมทีไคลเอนต์ SOCKS แก้ไขชื่อด้วยตัวเอง เพราะโปรโตคอลรุ่นแรก (SOCKS4) ไม่สามารถส่งชื่อได้ SOCKS5 เพิ่มการรองรับชื่อโดเมน แต่ระบบนิเวศของเครื่องมือได้แนะนำ suffix h เพื่อแยกแยะพฤติกรรมอย่างชัดเจน ทำให้เกิดคู่ socks5 / socks5h ที่ curl, Python, และไคลเอนต์ HTTP จำนวนมากเข้าใจในปัจจุบัน นี่เป็นมาตรฐานการตั้งชื่อโดยพฤตินัย ไม่ใช่ส่วนหนึ่งของ RFC

HTTP และ HTTPS-พรอกซี: ทำไมวิธี CONNECT ถึงแก้ไขที่พรอกซี

SOCKS ไม่ใช่พรอกซีประเภทเดียว งานจำนวนมากใช้ HTTP-พรอกซี และกลไกการแก้ไขที่นี่ต่างออกไป ซึ่งในหลายกรณีก็ดีกว่า

คำขอ HTTP ปกติผ่านพรอกซี

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

วิธี CONNECT สำหรับ HTTPS

สำหรับ HTTPS เรื่องน่าสนใจยิ่งขึ้น ทราฟฟิกที่เข้ารหัสไม่สามารถอ่านได้โดยพรอกซี - และไม่ควรอ่าน ดังนั้นสำหรับ HTTPS จึงใช้วิธีพิเศษที่เรียกว่า CONNECT ไคลเอนต์ส่งคำสั่งไปยังพรอกซีเช่น CONNECT example.com:443 สังเกตว่าที่นี่ส่ง ชื่อโฮสต์ ไม่ใช่ IP

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

ข้อสรุปสำคัญ: ในการใช้งาน HTTP-พรอกซีที่ถูกต้องกับวิธี CONNECT การแก้ไขจะเป็นการแก้ไขจากระยะไกลโดยค่าเริ่มต้น ชื่อถูกส่งไปยังพรอกซี, พรอกซีแก้ไขด้วยตัวเอง นี่เป็นสาเหตุหนึ่งที่ HTTP-พรอกซีสำหรับทราฟฟิก HTTPS มักทำงานถูกต้องกว่าจากกล่องเมื่อเทียบกับ SOCKS ที่ตั้งค่าไม่ถูกต้อง

ข้อควรระวังเกี่ยวกับการเพิ่มประสิทธิภาพของไคลเอนต์

มีจุดสำคัญบางประการ ไคลเอนต์บางตัวพยายามเพิ่มประสิทธิภาพการเชื่อมต่อ แต่ก็ยังแก้ไขชื่อในเครื่องก่อนส่ง CONNECT จากนั้นจึงส่ง IP address ใน CONNECT แทนชื่อ ในทางเทคนิคถือว่าทำได้ แต่จะทำลายประโยชน์ทั้งหมดของการแก้ไขจากระยะไกล ดังนั้นแม้จะมี HTTP-พรอกซีก็ไม่ควรวางใจพฤติกรรมโดยไม่ตรวจสอบ เราจะพูดถึงวิธีการตรวจสอบในหัวข้อแยกต่างหาก

HTTPS-พรอกซีในฐานะคำศัพท์แยก

อย่าสับสนสองความหมาย บางครั้ง HTTPS-พรอกซีหมายถึงพรอกซีที่พรอกซีทราฟฟิก HTTPS (ผ่าน CONNECT) และบางครั้งหมายถึงพรอกซีที่การเชื่อมต่อกับพรอกซีนั้นเข้ารหัสด้วย TLS (นั่นคือช่องทางไคลเอนต์-พรอกซีได้รับการป้องกัน) สิ่งเหล่านี้ต่างกัน จากมุมมองของการแก้ไข สิ่งแรกสำคัญกว่า: ชื่อปลายทางถูกส่งอย่างไร การเข้ารหัสช่องทางไปยังพรอกซีไม่ได้ส่งผลโดยตรงต่อเส้นทางการแก้ไข แต่ก็ช่วยปกป้องข้อเท็จจริงของการส่งชื่อจากผู้สังเกตการณ์ระหว่างคุณกับพรอกซี

การรั่วไหลของ DNS: กลไกการเกิดและสถานการณ์ทั่วไป

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

สถานการณ์ที่ 1: resolver ระบบหลบเลี่ยงพรอกซี

กรณีที่พบบ่อยที่สุด คุณตั้งค่าแอปพลิเคชันให้ใช้ socks5 (ไม่มี h) หรือไคลเอนต์ไม่สามารถแก้ไขจากระยะไกล แอปพลิเคชันเรียก getaddrinfo ของระบบ ระบบปฏิบัติการส่งคำขอ DNS ไปยัง resolver โดยตรงผ่านเครือข่าย ไม่ผ่านพรอกซี ข้อมูลที่แท้จริงจะผ่านพรอกซีในภายหลัง แต่ชื่อรั่วไหลไปแล้ว

วิธีสังเกต: พรอกซีได้รับการเชื่อมต่อด้วย IP ไม่ใช่ชื่อ ใน dump เครือข่ายของเครื่องคุณจะเห็นแพ็กเก็ตขาออกไปยังพอร์ต 53 ที่ไม่ได้ถูกห่อหุ้มใน tunnel ของพรอกซี

การรักษา: เปลี่ยนเป็น socks5h, เปิดใช้งานการแก้ไขจากระยะไกลในไคลเอนต์, หรือแยกแอปพลิเคชันให้ไม่สามารถเข้าถึงเครือข่ายโดยตรงสำหรับ DNS

สถานการณ์ที่ 2: WebRTC ในเบราว์เซอร์

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

การรักษา: ควบคุมนโยบาย WebRTC ในเบราว์เซอร์, ปิดหรือจำกัดการประมวลผล ICE candidates, ใช้การตั้งค่าเบราว์เซอร์ที่บังคับให้ทราฟฟิกทั้งหมดรวมถึง WebRTC ผ่านพรอกซี

สถานการณ์ที่ 3: DoH ในตัวของเบราว์เซอร์

เบราว์เซอร์สมัยใหม่สามารถ DNS over HTTPS - การแก้ไขผ่านคำขอ HTTPS ที่เข้ารหัสไปยังผู้ให้บริการ DoH ของตัวเอง ปัญหาคือคำขอนี้อาจออกไป นอกเหนือ จาก scheme SOCKS ของคุณ โดยตรงจากเครื่อง ถ้าเบราว์เซอร์ถูกตั้งค่าให้แก้ไขผ่าน DoH ของตัวเองและไม่ได้ห่อหุ้มทราฟฟิกนี้ไว้ในพรอกซี เกิดความขัดแย้ง: ชื่อถูกแก้ไขอย่างเข้ารหัสและเป็นส่วนตัวจากผู้ให้บริการ แต่ก็หลุดออกจากพรอกซีของคุณ ทำให้แย่ที่สุดสำหรับงานด้านตำแหน่งทางภูมิศาสตร์ เราจะพูดถึงกลไกนี้โดยละเอียดในหัวข้อ DoH

สถานการณ์ที่ 4: เส้นทาง IPv6 คู่ขนาน

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

การรักษา: ปิด IPv6 สำหรับแอปพลิเคชันที่พรอกซี หรือตรวจสอบให้แน่ใจว่าพรอกซีรองรับ IPv6 และทราฟฟิกทั้งหมดรวมถึงการแก้ไข AAAA ผ่านพรอกซี สำหรับหลายๆ งาน วิธีที่ง่ายกว่าคือบังคับให้ไคลเอนต์ใช้เฉพาะ IPv4

สถานการณ์ที่ 5: แคชและการโหลดล่วงหน้า

เบราว์เซอร์และระบบปฏิบัติการทำแคช DNS อย่างจริงจังและสร้างการเชื่อมต่อล่วงหน้า (preconnect, prefetch) หากแคชเต็มก่อนตั้งค่าพรอกซี แอปพลิเคชันอาจใช้บันทึกเก่าหรือการเชื่อมต่อที่สร้างไว้ล่วงหน้าโดยไม่สนใจการตั้งค่าใหม่ เป็นเรื่องเล็กน้อย แต่ในการดีบักอาจทำให้สับสน

การรักษา: ล้างแคช DNS ของระบบปฏิบัติการและเบราว์เซอร์, รีสตาร์ท, ปิดการโหลดล่วงหน้าที่ก้าวร้าวระหว่างการวินิจฉัย

รูปแบบทั่วไปของการรั่วไหล

สังเกตเห็นรูปแบบทั่วไปหรือไม่? การรั่วไหลทั้งหมด归结为一个点: มีช่องทางที่ชื่อหรือการเชื่อมต่อออกไปไม่ผ่านพรอกซี หน้าที่ของวิศวกรคือค้นหาและปิดช่องทางดังกล่าวทั้งหมด การรั่วไหลไม่ใช่เรื่องลึกลับ แต่เป็นประตูที่ไม่ได้ปิด

ปฏิบัติตามเครื่องมือ: วิธีเปิดใช้งานการแก้ไขจากระยะไกล

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

curl: socks5 กับ socks5-hostname

curl เป็นเครื่องมือมาตรฐานในการทำความเข้าใจความแตกต่าง มันให้ทางเลือกอย่างชัดเจน

• --socks5 host:port - การแก้ไขในเครื่อง curl หา IP เอง แล้วจึงผ่านพรอกซี
• --socks5-hostname host:port - การแก้ไขจากระยะไกล curl ส่งชื่อไปยังพรอกซีเซิร์ฟเวอร์

ผ่านตัวเลือก --proxy ก็สามารถจัดการ scheme ได้: socks5://... ให้การแก้ไขในเครื่อง ในขณะที่ socks5h://... ให้การแก้ไขจากระยะไกล ตัวอย่างการเรียกที่ถูกต้องสำหรับการแก้ไขจากระยะไกล: curl --proxy socks5h://user:pass@proxyhost:1080 https://example.com สำหรับ HTTP-พรอกซี scheme http://... กับวิธี CONNECT จะแก้ไขที่พรอกซีโดยค่าเริ่มต้น แต่ก็ควรตรวจสอบพฤติกรรมจริง

Python: requests และ httpx

ในระบบนิเวศของ Python scheme socks5h เป็นมาตรฐานทองคำสำหรับการแก้ไขจากระยะไกล

สำหรับ requests ต้องใช้แพ็คเกจเสริมที่รองรับ SOCKS พรอกซีถูกกำหนดด้วย dictionary: ระบุ scheme socks5h://user:pass@host:port สำหรับ https และ http scheme socks5:// ที่ไม่มี h หมายถึงการแก้ไขในเครื่อง - นี่คือสาเหตุที่พบบ่อยที่สุดของการรั่วไหลในมือใหม่ ตัวอักษรตัวเดียวช่วยได้

สำหรับ httpx ตรรกะคล้ายกัน: ส่งพรอกซีด้วย scheme socks5h:// เพื่อการแก้ไขจากระยะไกล httpx เข้มงวดกับ schemes และมีเอกสารพฤติกรรมที่ดี แต่หลักการเหมือนกัน - ตัวอักษร h เปลี่ยนการแก้ไขไปที่ฝั่งพรอกซี

ข้อสังเกตสำคัญ: แม้จะระบุ socks5h แล้ว ก็ควรตรวจสอบว่าตัวแปรสภาพแวดล้อมพรอกซีของระบบ (HTTP_PROXY, ALL_PROXY) ไม่ได้ทำงานกับ scheme อื่น ตัวแปรสภาพแวดล้อมสามารถแทนที่ความตั้งใจของคุณได้

Node.js

ใน Node.js ไม่มีการรองรับ SOCKS โดยตรงใน http มาตรฐาน ใช้ SOCKS agents ซึ่งสร้างการเชื่อมต่อผ่านพรอกซี พารามิเตอร์สำคัญของ agents เหล่านี้คือตัวเลือกที่กำหนดว่าจะแก้ไขชื่อในเครื่องหรือไม่ ใน SOCKS agents ที่นิยม มี flag ที่มักเรียกว่า lookup หรือตัวเลือกที่เกี่ยวข้องกับ DNS: เมื่อตั้งค่าให้ปิดการ lookup ในเครื่อง ชื่อจะถูกส่งไปยังพรอกซี ตรวจสอบให้แน่ใจว่า agent ถูกกำหนดค่าให้ส่ง hostname ไม่ใช่แก้ไขล่วงหน้าผ่าน dns.lookup

คำแนะนำเชิงปฏิบัติ: ใน Node.js โดยเฉพาะ ต้องตรวจสอบว่าไม่ได้เรียก dns.resolve หรือ dns.lookup ในโค้ดก่อนสร้างการเชื่อมต่อ การแก้ไขล่วงหน้าเช่นนี้จะทำลายเส้นทางระยะไกล

Go

ใน Go ไลบรารีมาตรฐานมีแพ็คเกจสำหรับทำงานกับพรอกซี ผ่าน golang.org/x/net/proxy คุณสามารถสร้าง SOCKS5 dialer ได้ โดยค่าเริ่มต้น พฤติกรรมขึ้นอยู่กับว่าคุณส่งชื่อหรือที่อยู่ที่แก้ไขแล้วไปยัง Dial ประเด็นสำคัญคือการใช้ dialer โดยส่งชื่อโดเมนลงไป ไม่ใช่ผลลัพธ์ของ net.LookupHost ถ้าคุณเรียก resolver เองและส่ง IP มา ถือเป็นการแก้ไขในเครื่องพร้อมผลกระทบทั้งหมด วิธีที่ถูกต้อง: ส่งสตริง host:port พร้อมชื่อไปยัง dialer และไม่ต้องแก้ไขล่วงหน้า

Chrome: flags การเริ่มต้น

Chrome ถูกควบคุมผ่าน flags บรรทัดคำสั่งและนโยบาย สำหรับการระบุพรอกซี ใช้ flag proxy-server สิ่งสำคัญคือเมื่อทำงานผ่าน SOCKS5 Chrome โดยค่าเริ่มต้นอาจแก้ไขในเครื่อง มี flag ที่รับผิดชอบให้การแก้ไขสำหรับการเชื่อมต่อที่ถูกพรอกซีเกิดขึ้นที่ฝั่งพรอกซี - ชื่อของ flag เกี่ยวข้องกับ host-resolver-rules และการตั้งค่าที่บังคับให้โฮสต์ทั้งหมดผ่านพรอกซี นอกจากนี้ยังต้องควบคุม DoH ในตัว: ถ้า Secure DNS ในเบราว์เซอร์เปิดใช้งานและตั้งค่าให้ใช้ผู้ให้บริการของตัวเอง มันสามารถเลี่ยง scheme ของคุณได้ เพื่อความชัดเจนในการทดสอบ ควรปิด Secure DNS ชั่วคราว และนโยบาย WebRTC ก็ควรเข้มงวด

Firefox: การตั้งค่า about:config

Firefox ในอดีตสะดวกกว่าในการควบคุมการแก้ไข การตั้งค่าสำคัญคือ network.proxy.socks_remote_dns ตั้งค่าเป็น true แล้ว Firefox จะส่งชื่อโฮสต์ไปยัง SOCKS-พรอกซีเพื่อการแก้ไขจากระยะไกล แทนที่จะแก้ไขในเครื่อง นี่เป็นการตั้งค่าที่สำคัญที่สุดอย่างหนึ่งในเนื้อหาทั้งหมด นอกจากนี้ยังต้องควบคุม:

• network.trr.mode - โหมด DoH (TRR, Trusted Recursive Resolver) ค่าที่ปิด DoH แบบบังคับเป็นสิ่งสำคัญถ้าคุณต้องการให้การแก้ไขผ่านพรอกซีเท่านั้น
• media.peerconnection.enabled - การจัดการ WebRTC เพื่อป้องกันการรั่วไหลผ่าน ICE
• การตั้งค่าที่ปิด IPv6 หรือการโหลดล่วงหน้า ถ้าพบเส้นทางคู่ขนาน

Selenium

Selenium จัดการเบราว์เซอร์จริง ดังนั้นตรรกะการแก้ไขจะสืบทอดมาจาก Chrome หรือ Firefox สำหรับ Chrome คุณส่ง flags เดียวกันผ่าน options การเริ่มต้น (อาร์กิวเมนต์ proxy-server และที่เกี่ยวข้องกับการแก้ไข) สำหรับ Firefox คุณสร้างโปรไฟล์ที่มี network.proxy.socks_remote_dns เปิดใช้งานผ่าน object การตั้งค่าโปรไฟล์ เคล็ดลับความสำเร็จ: อย่าพึ่งพาค่าเริ่มต้นของ driver - ระบุการตั้งค่าการแก้ไขจากระยะไกลอย่างชัดเจนในโปรไฟล์หรือ flags แล้วตรวจสอบเส้นทางจริงในภายหลัง

Playwright

Playwright มีพารามิเตอร์ proxy เมื่อเริ่มต้น context หรือเบราว์เซอร์ คุณระบุ server ด้วย scheme (เช่น socks5://host:port) และข้อมูลรับรอง มีข้อละเอียด: พฤติกรรมการแก้ไขขึ้นอยู่กับ engine (Chromium, Firefox, WebKit) และวิธีการ implement proxying เพื่อให้แน่ใจว่ามีการแก้ไขจากระยะไกลใน Chromium engine ให้รวมการตั้งค่าพรอกซีกับอาร์กิวเมนต์เริ่มต้นที่เกี่ยวข้อง และใน Firefox engine รวมกับการตั้งค่าโปรไฟล์ socks_remote_dns ควรจบการตั้งค่าด้วยการตรวจสอบการรั่วไหลเสมอ

ตารางสรุป: ไคลเอนต์, วิธีเปิดใช้งานการแก้ไขจากระยะไกล, วิธีตรวจสอบ

เก็บตารางปฏิบัติหลักของเนื้อหา:

• curl - เปิดใช้งาน: ใช้ --socks5-hostname หรือ scheme socks5h:// ใน --proxy - ตรวจสอบ: curl พร้อม verbose และสังเกตว่าส่งชื่อ; dump ทราฟฟิกเพื่อดูว่าไม่มีคำขอโดยตรงไปยังพอร์ต 53
• Python requests - เปิดใช้งาน: scheme socks5h:// ใน dictionary proxies - ตรวจสอบ: คำขอไปยังบริการที่แสดงแหล่งที่มาของ resolver; ควบคุมตัวแปรสภาพแวดล้อม
• Python httpx - เปิดใช้งาน: พรอกซีด้วย scheme socks5h:// - ตรวจสอบ: ทดสอบการรั่วไหล, วิเคราะห์ว่า resolver ใดปรากฏ
• Node.js - เปิดใช้งาน: SOCKS agent ส่ง hostname, โดยไม่เรียก dns.lookup ล่วงหน้า - ตรวจสอบ: ไม่มีการเรียก dns.resolve ก่อนเชื่อมต่อ; dump ที่พอร์ต 53
• Go - เปิดใช้งาน: SOCKS5 dialer, ส่ง host:port พร้อมชื่อ, โดยไม่เรียก net.LookupHost ล่วงหน้า - ตรวจสอบ: logging สิ่งที่ส่งไปยัง dialer; tcpdump
• Chrome - เปิดใช้งาน: proxy-server ด้วย SOCKS5, host-resolver-rules ให้พรอกซี, ปิด Secure DNS เพื่อการวินิจฉัย - ตรวจสอบ: ทดสอบการรั่วไหลออนไลน์, เปรียบเทียบภูมิภาค IP และภูมิภาค DNS
• Firefox - เปิดใช้งาน: network.proxy.socks_remote_dns เป็น true, ควบคุม network.trr.mode - ตรวจสอบ: about:networking, ทดสอบการรั่วไหลออนไลน์
• Selenium - เปิดใช้งาน: flags Chrome เดียวกันหรือโปรไฟล์ Firefox พร้อม socks_remote_dns - ตรวจสอบ: รันทดสอบการรั่วไหลภายในเบราว์เซอร์ที่ถูกควบคุม
• Playwright - เปิดใช้งาน: พารามิเตอร์ proxy รวมกับอาร์กิวเมนต์ engine เพื่อการแก้ไขจากระยะไกล - ตรวจสอบ: ไปที่ทดสอบการรั่วไหลในเซสชันอัตโนมัติ

DoH และ DoT: พวกมันโต้ตอบกับพรอกซีอย่างไร

DNS over HTTPS (DoH) และ DNS over TLS (DoT) คือการเข้ารหัสคำขอ DNS ตัวมันเองดีเยี่ยมสำหรับการปกป้องเนื้อหาของคำขอจากผู้สังเกตการณ์ แต่ในบริบทของพรอกซี พวกมันสร้างผลกระทบที่ละเอียดอ่อนซึ่งต้องเข้าใจ

DoH และ DoT คืออะไรโดยสรุป

DoT ห่อหุ้ม DNS ไว้ใน TLS บนพอร์ตที่เฉพาะ DoH ซ่อนคำขอ DNS ไว้ในทราฟฟิก HTTPS ปกติ ทำให้แยกไม่ออกจากการท่องเว็บ ทั้งสองโปรโตคอลเข้ารหัสคำขอ แต่ - และนี่คือประเด็นสำคัญ - การเข้ารหัสคำขอไม่เท่ากับการกำหนดเส้นทางผ่านพรอกซี มันเป็นคนละมิติ

ความขัดแย้งที่สำคัญ: DoH ของเบราว์เซอร์หลบเลี่ยงพรอกซี

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

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

เมื่อ DoH ของเบราว์เซอร์ทำลาย scheme ของคุณทั้งหมด

ระบุสถานการณ์ที่ DoH เลี่ยงพรอกซี:

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

ข้อสรุปเชิงปฏิบัติ: สำหรับงานที่ความสอดคล้องของภูมิภาคสำคัญ เมื่อทำงานผ่านพรอกซี ควรปิด DoH ของเบราว์เซอร์และระบบ หรือส่งไปยังพรอกซีเดียวกันโดยชัดเจน ภาพในอุดมคติคือการแก้ไขทั้งหมด ไม่ว่าจะเข้ารหัสหรือไม่ ต้องผ่านพรอกซีเซิร์ฟเวอร์ (การแก้ไขจากระยะไกล) ไม่ใช่หลบเลี่ยงมัน

DoT และพรอกซี

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

กฎทองของ DoH ในบริบทของพรอกซี

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

วิธีตรวจสอบ: dig, nslookup, tcpdump และการทดสอบออนไลน์

การตั้งค่าเป็นเพียงครึ่งเดียว วิศวกรต้องตรวจสอบว่าการแก้ไขไปในทิศทางที่ตั้งใจไว้ มาดูเครื่องมือวินิจฉัยจากง่ายไปซับซ้อน

dig และ nslookup ผ่านพรอกซี

dig และ nslookup เป็นยูทิลิตี้คลาสสิกสำหรับการแก้ไขด้วยตนเอง ข้อละเอียดคือ DNS ปกติใช้ UDP ในขณะที่ SOCKS-พรอกซีโดยธรรมชาติพรอกซีเฉพาะ TCP ดังนั้นการตรวจสอบการแก้ไขผ่านพรอกซีต้องให้คำขอ DNS ผ่าน TCP และยูทิลิตี้ถูกส่งผ่าน wrapper SOCKS ในทางปฏิบัติ การสังเกตพฤติกรรมทำได้สะดวกโดยห่อหุ้มเครื่องมือผ่านโปรแกรมที่ส่งทราฟฟิก TCP ไปยัง SOCKS ความหมายของการตรวจสอบ: เพื่อให้แน่ใจว่าเมื่อใช้การแก้ไขจากระยะไกล เครื่องของคุณไม่ส่งคำขอ DNS เอง แต่เห็นเฉพาะผลลัพธ์ที่มาผ่านช่องทางพรอกซี

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

tcpdump ที่พอร์ต 53 - การทดสอบที่ซื่อสัตย์ที่สุด

นี่เป็นวิธีที่ฉันชอบเพราะมันไม่โกหก เริ่มจับทราฟฟิกบนเครื่องของคุณด้วยตัวกรองพอร์ต 53 (และพอร์ต 443 สำหรับข้อสงสัย DoH) จากนั้นดำเนินการคำขอที่ถูกพรอกซี ตรรกะง่าย:

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

tcpdump แสดงความเป็นจริงทางกายภาพของเครือข่าย ไม่ใช่การประกาศจาก config นั่นคือเหตุผลที่มันจำเป็นสำหรับการยืนยันขั้นสุดท้าย

การทดสอบการรั่วไหลออนไลน์: วิธีอ่านผลลัพธ์อย่างถูกต้อง

มีบริการเว็บที่แสดงว่า resolver ใดดำเนินการคำขอ DNS ของคุณและมาจากภูมิภาคใด กุญแจสำคัญในการอ่านผลลัพธ์ที่ถูกต้องคืออย่าสับสนระหว่างสองพารามิเตอร์:

• IP ที่มองเห็นได้ของคุณ - นี่คือ IP ที่การเชื่อมต่อ HTTP มาจาก นั่นคือ IP ของพรอกซี
• resolver DNS - นี่คือที่อยู่และภูมิภาคของผู้ที่ดำเนินการแก้ไขจริง

ภาพที่ถูกต้องเมื่อใช้การแก้ไขจากระยะไกล: ทั้ง IP ที่มองเห็นได้และ resolver ระบุภูมิภาคของพรอกซี สัญญาณอันตราย: IP ที่มองเห็นได้คือภูมิภาคของพรอกซี แต่ resolver คือภูมิภาคจริงของคุณ นี่คือการรั่วไหลแบบคลาสสิกผ่านการแก้ไขในเครื่อง อีกรูปแบบหนึ่งของการรั่วไหล: resolver เป็นของผู้ให้บริการ DoH รายใหญ่ แต่การเชื่อมต่อไปยังมันหลบเลี่ยงพรอกซี - ในกรณีนี้ ภูมิภาคของ resolver อาจเป็นกลาง แต่เส้นทางเองก็ไม่ผ่านพรอกซี ซึ่ง tcpdump จะแสดงให้เห็น

Checklist การตรวจสอบการแก้ไข

ดำเนินการตามข้อต่อไปนี้:

1. ล้างแคช DNS ของ OS และเบราว์เซอร์, รีสตาร์ทแอปพลิเคชัน
2. ตรวจสอบว่า scheme เป็น socks5h หรือเปิดใช้งานการแก้ไขจากระยะไกลในไคลเอนต์
3. ตรวจสอบตัวแปรสภาพแวดล้อมพรอกซีเพื่อหา scheme ที่ขัดแย้ง
4. เริ่ม tcpdump ด้วยตัวกรองพอร์ต 53 และ 443
5. ดำเนินการคำขอที่ถูกพรอกซีไปยังทรัพยากรทดสอบ
6. ตรวจสอบว่าไม่มีแพ็กเก็ต DNS โดยตรงไปยังพอร์ต 53
7. ตรวจสอบว่าไม่มีการเชื่อมต่อ HTTPS อิสระไปยัง endpoint DoH
8. เปิดการทดสอบการรั่วไหลออนไลน์และเปรียบเทียบภูมิภาค IP กับภูมิภาค resolver
9. ตรวจสอบเส้นทาง IPv6: ไม่มีคำขอ AAAA หรือการเชื่อมต่อคู่ขนาน
10. บันทึกการกำหนดค่ามาตรฐานในเอกสารของทีม

ข้อผิดพลาดทั่วไปที่เกือบทุกคนทำ

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

ข้อผิดพลาดที่ 1: สับสนระหว่าง socks5 และ socks5h

อันดับหนึ่งแน่นอน คนเขียน socks5:// และมั่นใจว่าการแก้ไขเป็นระยะไกล แต่จริงๆ แล้วเป็นในเครื่อง ตัวอักษร h ที่หายไปตัวเดียวทำให้ภูมิภาคคลาดเคลื่อนทั้งหมด ระบุ socks5h ให้ชัดเจนเสมอถ้าคุณต้องการการแก้ไขจากระยะไกล และตรวจสอบด้วย dump

ข้อผิดพลาดที่ 2: ตั้งค่าพรอกซีแต่ลืม DoH

คลาสสิกสำหรับเบราว์เซอร์ ตั้งค่าพรอกซีแล้ว แต่ Secure DNS / DoH ในตัวยังทำงานและหลบเลี่ยง ผู้ใช้เห็น IP ที่ถูกต้องและสบายใจ แต่การแก้ไขรั่วไหล ควรซิงค์นโยบาย DoH กับพรอกซีเสมอ

ข้อผิดพลาดที่ 3: ไม่สนใจ IPv6

พรอกซีบน IPv4 แต่เครื่องมี dual stack Happy Eyeballs ทำงาน และการเชื่อมต่อบางส่วนผ่าน IPv6 โดยตรง ปิด IPv6 สำหรับแอปพลิเคชัน หรือตรวจสอบให้แน่ใจว่าพรอกซีรองรับ IPv6 เต็มรูปแบบ

ข้อผิดพลาดที่ 4: การแก้ไขในเครื่องล่วงหน้าในโค้ด

ปัญหาที่พบบ่อยใน Node.js และ Go นักพัฒนาเรียก resolver ล่วงหน้า (เพื่อตรวจสอบ, เพื่อ log) แล้วส่ง IP ไปยังพรอกซี การแก้ไขจากระยะไกลก็ไร้ผล อย่าแก้ไขชื่อก่อนส่งไปยัง proxy dialer

ข้อผิดพลาดที่ 5: ไว้วางใจตัวแปรสภาพแวดล้อม

HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY - ผู้ก่อกวนเงียบ พวกเขาแทนที่การตั้งค่าในโค้ดหรือขัดแย้งกับ scheme ตรวจสอบสภาพแวดล้อมก่อนรันและล้างค่าที่ไม่จำเป็น

ข้อผิดพลาดที่ 6: เชื่อ config แทนการตรวจสอบ

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

ข้อผิดพลาดที่ 7: ลืมล้างแคช DNS

เปลี่ยนการตั้งค่าแต่ผลลัพธ์เหมือนเดิม - เพราะบันทึกเก่าและการเชื่อมต่อถูกแคชไว้ ล้างแคชและรีสตาร์ทก่อนตรวจสอบเสมอ

ข้อผิดพลาดที่ 8: ผสมพรอกซีประเภทต่างๆ ใน pipeline เดียว

บางที่ใช้ HTTP-พรอกซีกับ CONNECT, บางที่ใช้ SOCKS กับการแก้ไขในเครื่อง พฤติกรรมการแก้ไขแตกต่างกัน และคำขอส่วนหนึ่งรั่วไหล ทำให้เป็นมาตรฐานตลอดทั้ง pipeline

ข้อผิดพลาดที่ 9: ไม่นับแคชของแอปพลิเคชัน

แอปพลิเคชันบางตัวมีแคช DNS และ connection pool ของตัวเองที่คงอยู่แม้เปลี่ยนการตั้งค่า การรีสตาร์ท process บางครั้งจำเป็น

ข้อผิดพลาดที่ 10: ไม่สนใจ WebRTC ในการอัตโนมัติ

ในการอัตโนมัติเบราว์เซอร์ มักลืม WebRTC เบราว์เซอร์ที่ถูกควบคุมสามารถเริ่ม ICE และเปิดเผยเส้นทางนอกพรอกซี ควบคุมนโยบาย WebRTC ในเซสชันอัตโนมัติเสมอ

เครื่องมือและทรัพยากรสำหรับการทำงานกับการแก้ไขผ่านพรอกซี

รวบรวมคลังอาวุธที่ควรมีไว้ใกล้ตัว แบ่งตามวัตถุประสงค์

เครื่องมือวินิจฉัย

• tcpdump - จับทราฟฟิกเครือข่าย, ผู้ตัดสินหลักของความจริงในเส้นทางการแก้ไข
• Wireshark - การวิเคราะห์แพ็กเก็ตแบบกราฟิก, สะดวกสำหรับกรณีซับซ้อนที่เกี่ยวข้องกับ DoH และ IPv6
• dig และ nslookup - การแก้ไขด้วยตนเอง, ตรวจสอบคำตอบของ resolver อย่างรวดเร็ว
• การทดสอบการรั่วไหล DNS ออนไลน์ - แสดง resolver และภูมิภาคของมัน, ให้คำตัดสินอย่างรวดเร็ว
• about:networking ใน Firefox - การวินิจฉัยการเชื่อมต่อและ DNS ในตัวของเบราว์เซอร์

เครื่องมือและไลบรารีสำหรับการตั้งค่า

• curl - มาตรฐานสำหรับตรวจสอบพฤติกรรมของ socks5 และ socks5-hostname, เหมาะสำหรับการดีบัก
• SOCKS wrappers สำหรับทราฟฟิก TCP - ช่วยให้ห่อหุ้มแอปพลิเคชันใดๆ ใน SOCKS เพื่อทดสอบการแก้ไข
• ไลบรารี SOCKS สำหรับภาษา - แพ็คเกจที่รองรับ SOCKS ใน Python, SOCKS agents ใน Node.js, proxy package ใน Go
• เครื่องมืออัตโนมัติเบราว์เซอร์ - Selenium และ Playwright พร้อมการตั้งค่าพรอกซีและการแก้ไขอย่างชัดเจน

แหล่งความรู้

• เอกสารทางการของ curl เกี่ยวกับตัวเลือกพรอกซี - แหล่งข้อมูลที่ดีที่สุดสำหรับความหมายของ socks5 เทียบกับ socks5h
• เอกสารของ HTTP clients ใน Python เกี่ยวกับการทำงานกับพรอกซีและ schemes
• คู่มือ about:config ของ Firefox สำหรับพารามิเตอร์เครือข่ายและการแก้ไข
• เอกสารของผู้ให้บริการพรอกซีที่คุณเลือก โดยเฉพาะบริการ MobileProxy.space ซึ่งอธิบาย schemes ที่รองรับและคำแนะนำสำหรับการแก้ไขจากระยะไกลสำหรับมือถือพรอกซี

กรอบการตัดสินใจเลือกวิธีการ

เพื่อไม่ให้สับสน เก็บตรรกะการตัดสินใจง่ายๆ นี้:

1. ต้องการทราฟฟิก HTTPS และการแก้ไขจากระยะไกล? HTTP-พรอกซีกับ CONNECT หรือ SOCKS5 ด้วย scheme socks5h
2. ทำงานจากไลบรารีหรือ CLI? ระบุ socks5h หรือ flag การแก้ไขจากระยะไกลอย่างชัดเจน
3. ทำงานจากเบราว์เซอร์? เปิดใช้งานการแก้ไขจากระยะไกล, ปิดหรือส่ง DoH ผ่านพรอกซี, จำกัด WebRTC และ IPv6
4. จบการตั้งค่าด้วย dump ทราฟฟิกและการทดสอบออนไลน์เสมอ

กรณีศึกษาและผลลัพธ์: มันเป็นอย่างไรในทางปฏิบัติ

ทฤษฎีไร้การปฏิบัติก็ตาย มาดูกรณีศึกษาทั่วไปที่สะท้อนสถานการณ์ปกติ ตัวเลขเป็นเพียงตัวอย่าง แต่สัดส่วนและตรรกะมาจากประสบการณ์วิศวกรรมจริง

กรณีที่ 1: ภูมิภาคไม่ตรงกันของนักวิเคราะห์ข้อมูล

ทีมงานเก็บข้อมูลด้วย Python script พร้อมพรอกซีของภูมิภาคที่ต้องการ ผลลัพธ์มาพร้อม localization ของประเทศอื่นประมาณสี่สิบเปอร์เซ็นต์ของเคส การวินิจฉัยพบ scheme socks5:// ใน dictionary proxies - การแก้ไขในเครื่อง เปลี่ยนเป็น socks5h:// แก้ปัญหาความไม่สอดคล้องของภูมิภาคได้สมบูรณ์ tcpdump ยืนยัน: คำขอโดยตรงไปยังพอร์ต 53 หายไป บทเรียน: ตัวอักษรตัวเดียวแก้ปัญหาที่ใช้เวลาเสียไปสองวัน

กรณีที่ 2: การรั่วไหลผ่าน DoH ของเบราว์เซอร์ในการอัตโนมัติ

ในการอัตโนมัติ Chromium ผ่าน Playwright ภูมิภาค IP ถูกต้อง แต่ทรัพยากรเป้าหมายกลับระบุภูมิภาคอื่น การทดสอบออนไลน์พบ resolver ที่ไม่ตรงกับภูมิภาคของพรอกซี Wireshark เปิดเผยการเชื่อมต่อ HTTPS อิสระไปยัง endpoint DoH ที่หลบเลี่ยงพรอกซี วิธีแก้: ปิด Secure DNS ในการกำหนดค่าเริ่มต้นและบังคับการแก้ไขจากระยะไกล หลังแก้ไข ภูมิภาคของ resolver ตรงกับภูมิภาค IP การแจ้งเตือนป้องกันการฉ้อโกงปลอมลดลงหลายเท่า

กรณีที่ 3: IPv6 คู่ขนานใน microservice

Go service ใช้ SOCKS5 แต่บางครั้งคำขอส่วนหนึ่งออกโดยตรง สาเหตุคือ dual stack และการพยายาม IPv6 ที่หลบเลี่ยงพรอกซี จำกัดไคลเอนต์ให้ใช้เฉพาะ IPv4 และส่งชื่อไปยัง dialer อย่างถูกต้องแก้ปัญหาการรั่วไหล tcpdump ไม่แสดงคำขอ AAAA โดยตรงอีกต่อไป ความเสถียรของภูมิภาคเพิ่มขึ้นเกือบร้อยเปอร์เซ็นต์

กรณีที่ 4: ตัวแปรสภาพแวดล้อมผู้ก่อกวน

Script มีพฤติกรรมต่างกันบนสองเครื่องด้วยโค้ดเดียวกัน บนเครื่องหนึ่งการแก้ไขจากระยะไกลทำงาน อีกเครื่องไม่ทำงาน สาเหตุ: บนเครื่องที่มีปัญหา มีการตั้งค่าตัวแปร ALL_PROXY ด้วย scheme ไม่มี h ซึ่งแทนที่การตั้งค่า หลังจากล้างสภาพแวดล้อม พฤติกรรมสอดคล้องกัน บทเรียน: สภาพแวดล้อมเป็นส่วนหนึ่งของการกำหนดค่า ต้องควบคุมอย่างเข้มงวดเท่ากับโค้ด

ข้อสรุปทั่วไปจากกรณีศึกษา

สังเกตรูปแบบ ในทุกกรณี อาการคล้ายกัน - ภูมิภาคผิดหรือการป้องกันทำงาน - แต่สาเหตุต่างกัน: scheme, DoH, IPv6, สภาพแวดล้อม นี่คือเหตุผลที่การวินิจฉัยตาม checklist สำคัญกว่าสัญชาตญาณ วิธีการที่เป็นระบบจะหารากได้เร็วกว่าการเดา

FAQ: คำถามที่พบบ่อย

socks5 กับ socks5h ต่างกันอย่างไรในคำง่ายๆ?

socks5 แก้ไขชื่อโดเมนที่ฝั่งคุณและส่ง IP ที่พร้อมแล้วไปยังพรอกซี socks5h ส่งชื่อไปยังพรอกซี และพรอกซีเป็นผู้แก้ไข เพื่อความเป็นส่วนตัวและตำแหน่งทางภูมิศาสตร์ที่ถูกต้อง เกือบทุกครั้งควรใช้ socks5h ตัวอักษร h หมายถึง hostname - ชื่อโฮสต์ถูกส่งไปยังระยะไกล

ถ้าฉันใช้ HTTP-พรอกซี ฉันต้องกังวลเกี่ยวกับการแก้ไขหรือไม่?

สำหรับ HTTPS ผ่าน CONNECT โดยปกติชื่อจะถูกส่งไปยังพรอกซี และพรอกซีแก้ไขเอง - ซึ่งดี แต่ไคลเอนต์บางตัวแก้ไขในเครื่องล่วงหน้าและส่ง IP ใน CONNECT ดังนั้นแม้กับ HTTP-พรอกซี ก็ควรตรวจสอบพฤติกรรมจริงด้วย dump ทราฟฟิก

ทำไม IP ถูกต้อง แต่เว็บไซต์เห็นภูมิภาคอื่น?

เกือบแน่นอนว่า DNS request ของคุณหลบเลี่ยงพรอกซี - ผ่าน resolver ในเครื่องหรือ DoH ของเบราว์เซอร์ โครงสร้างพื้นฐานเป้าหมายใช้ geolocation DNS และ CDN เพื่อกำหนดภูมิภาคของ resolver ของคุณ ไม่ใช่พรอกซี วิธีแก้คือการแก้ไขจากระยะไกลและควบคุม DoH

WebRTC เกี่ยวข้องกับการแก้ไขและการรั่วไหลอย่างไร?

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

DoH ทำลายการตั้งค่าพรอกซีของฉันหรือไม่?

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

จะตรวจสอบอย่างรวดเร็วว่ามีการรั่วไหลหรือไม่?

สองขั้นตอน ขั้นแรก: เริ่ม tcpdump ด้วยตัวกรองพอร์ต 53 และดำเนินการคำขอที่ถูกพรอกซี: แพ็กเก็ต DNS โดยตรงหมายถึงการรั่วไหล ขั้นที่สอง: เปิดการทดสอบออนไลน์และเปรียบเทียบภูมิภาคของ IP ที่มองเห็นกับภูมิภาคของ resolver ตรงกัน - ดี, ไม่ตรงกัน - รั่วไหล

จะทำอย่างไรกับ IPv6 ถ้าพรอกซีเป็น IPv4 เท่านั้น?

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

ทำไมโค้ดเดียวกันถึงทำงานต่างกันบนสองเครื่อง?

สาเหตุที่พบบ่อยคือตัวแปรสภาพแวดล้อมพรอกซี (HTTP_PROXY, ALL_PROXY และอื่นๆ) ซึ่งแทนที่การตั้งค่าในโค้ดหรือกำหนด scheme อื่น ตรวจสอบและล้างสภาพแวดล้อมเพื่อให้พฤติกรรมสอดคล้อง

แค่ระบุ socks5h ก็เพียงพอแล้วหรือไม่ที่จะไม่มีการรั่วไหล?

สำหรับแอปพลิเคชันเอง - ก้าวใหญ่ แต่ไม่รับประกันสำหรับทั้งระบบ ยังมีช่องทางเช่น DoH ของเบราว์เซอร์, WebRTC และ IPv6 การป้องกันที่สมบูรณ์คือการแก้ไขจากระยะไกลรวมกับการควบคุมช่องทางเลี่ยงทั้งหมดและการตรวจสอบด้วย dump

สามารถแก้ไขผ่านพรอกซีในบรรทัดคำสั่งเพื่อทดสอบได้หรือไม่?

ได้ curl ด้วยตัวเลือก --socks5-hostname หรือ scheme socks5h เป็นวิธีที่ง่ายที่สุดในการตรวจสอบการแก้ไขจากระยะไกล สำหรับยูทิลิตี้เช่น dig สะดวกในการห่อหุ้มทราฟฟิก TCP ใน SOCKS โดยจำไว้ว่า DNS แบบคลาสสิกผ่าน UDP ไม่ถูกพรอกซีโดย SOCKS โดยธรรมชาติ

บทสรุป: สรุปและขั้นตอนถัดไป

เราเดินทางจากอาการไปสู่ความเข้าใจอย่างลึกซึ้ง มาสรุปสิ่งสำคัญในกรอบความหมายที่กะทัดรัดที่จะติดตัวคุณไป

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

ความแตกต่างระหว่าง socks5 และ socks5h เป็นพื้นฐาน socks5 - การแก้ไขในเครื่อง, socks5h - การแก้ไขจากระยะไกล ตัวอักษรตัวเดียวเปลี่ยนทุกอย่าง: ภูมิภาค, ความเป็นส่วนตัว, ความสอดคล้อง HTTP-พรอกซีกับวิธี CONNECT โดยธรรมชาติจะส่งชื่อไปยังพรอกซี แต่ก็ไม่ควรเชื่ออย่างสุ่มสี่สุ่มห้า - ตรวจสอบ

การรั่วไหล归结为一个หลักการ: มีช่องทางที่ชื่อออกไปไม่ผ่านพรอกซี resolver ระบบ, WebRTC, DoH ของเบราว์เซอร์, IPv6 คู่ขนาน, แคช - นี่คือผู้ต้องสงสัยหลัก และจำข้อมูลเชิงลึกสำคัญ: การเข้ารหัสการแก้ไขไม่เท่ากับการกำหนดเส้นทางผ่านพรอกซี คุณสามารถมี DoH ที่เข้ารหัสซึ่งเปิดเผยภูมิภาคของคุณอย่างสมบูรณ์

สิ่งที่ต้องทำตอนนี้? นี่คือแผนปฏิบัติการ:

1. ตรวจสอบการกำหนดค่าปัจจุบันของคุณและเปลี่ยน socks5 เป็น socks5h ในที่ที่ต้องการการแก้ไขจากระยะไกล
2. ตรวจสอบเบราว์เซอร์: เปิดใช้งานการแก้ไขจากระยะไกล, จัดการนโยบาย DoH และ WebRTC
3. ตรวจสอบให้แน่ใจว่า IPv6 ไม่สร้างเส้นทางคู่ขนานนอกพรอกซี
4. ล้างตัวแปรสภาพแวดล้อมพรอกซีจากค่าที่ขัดแย้ง
5. ดำเนินการตรวจสอบด้วย tcpdump และการทดสอบออนไลน์ตาม checklist ในบทความ
6. บันทึกการกำหนดค่ามาตรฐานที่ทำงานได้ในเอกสาร เพื่อให้ทีมไม่ต้อง reinvent the wheel

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