ไฟล์ hosts กับตัวกรองบนเราเตอร์ การบล็อกไซต์ผ่าน VPN

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

ชื่อถูกแก้ที่ใดเป็นตัวกำหนดทุกอย่าง

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

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

นี่คือกลไกเบื้องหลังข้อร้องเรียนที่คุ้นเคยว่าตัวกรองทำงานจนกว่า VPN จะเชื่อมต่อ

รายการ hosts ตอบก่อนที่อุโมงค์จะมีอยู่

บรรทัดอย่าง 127.0.0.1 www.example.com ถูกอ่านโดยตัวแก้ชื่อภายในเครื่อง คำตอบจึงเกิดขึ้นบนเครื่องโดยไม่ต้องใช้เครือข่าย ต่ออุโมงค์ เปลี่ยนเซิร์ฟเวอร์ DNS สลับเครือข่าย รายการก็ยังคืนค่า loopback นี่คือเหตุผลที่การบล็อกด้วย hosts เป็นเพียงหนึ่งเดียวในสองอย่างที่ไม่ได้รับผลกระทบจากตำแหน่งที่ VPN สิ้นสุด

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

ยืนยันคำตอบด้วย getent ahosts บน Linux หรือ Resolve-DnsName บน Windows แทนการเชื่อถือแท็บเบราว์เซอร์

ตัวกรองบนเราเตอร์เห็นเพียงสิ่งที่ผ่านมันไป

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

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

ถ้าอุโมงค์สิ้นสุดที่แล็ปท็อป เราเตอร์ก็อยู่นอกเส้นทางที่ป้องกันตามนิยาม ไม่ว่ากฎจะเขียนอย่างไร

สี่จุดบังคับใช้ และสิ่งที่แต่ละจุดมองข้าม

สี่ตำแหน่งสามารถบังคับใช้การบล็อกได้ และแต่ละแห่งล้มเหลวต่างกัน อ่านรายการนี้เป็นแผนที่ความครอบคลุม ไม่ใช่การจัดอันดับ

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

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

เลือกชั้นที่ตรงกับเจตนา ความสะดวกในบ้านเป็นของอุปกรณ์ และกฎขององค์กรเป็นของเกตเวย์

ทดสอบทั้งสองสถานะก่อนจะบอกว่าเสร็จแล้ว

รันสามคำสั่งเดิมทั้งตอนเชื่อมต่อและตัด VPN คือ getent ahosts เพื่อดูคำตอบของตัวแก้ชื่อ nslookup เพื่อดูว่าคำถามคืนอะไร และ curl -I ไปยังไซต์เพื่อดูว่าการเชื่อมต่อยังสมบูรณ์หรือไม่ ถ้าตัวแรกคืน loopback ขณะที่ตัวที่สามเชื่อมต่อกับที่อยู่จริง แสดงว่ามีบางอย่างเลี่ยงตัวแก้ชื่อ และรายการ hosts ไม่ใช่การควบคุมที่คุณคิด

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

เขียนผลลัพธ์ไว้พร้อมโครงสร้าง เพราะการเปลี่ยน VPN ครั้งถัดไปจะย้ายเส้นทางอีก