DNS ของ VPN คุณถูกใช้จริงหรือไม่ จับพอร์ต 53 แล้วดู

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

ตัวเลือกที่พุชลงมาไม่ใช่คำค้น

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

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

ตรวจสอบว่าอินเทอร์เฟซถืออะไรอยู่จริง

บน Linux ตัวแปลงชื่อของระบบอาจเป็นไฟล์ธรรมดา NetworkManager หรือ systemd-resolved และการที่ตัวใดตัวหนึ่งถือครองมันเป็นตัวกำหนดว่าเซิร์ฟเวอร์ที่พุชลงมาจะไปลงที่ใด กระบวนการ OpenVPN บนบรรทัดคำสั่งไม่ได้อัปเดตตัวแปลงชื่อของระบบด้วยตัวเอง การผสานรวมที่มีเอกสารจึงเป็นสคริปต์ up/down หรือตัวจัดการการเชื่อมต่อที่รู้วิธีใช้การตั้งค่าอยู่แล้ว การรันทั้งสองอย่างพร้อมกันเป็นวิธีที่ได้ผลในการสร้างการแย่งชิง

resolvectl status
cat /etc/resolv.conf

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

ติดตามคำค้นหนึ่งรายการออกนอกเครื่อง

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

sudo tcpdump -ni tun0 port 53
sudo tcpdump -ni any port 53

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

ไฟร์วอลล์ที่ยอมรับเฉพาะ DNS ของตัวเอง

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

sudo iptables -S OUTPUT
sudo iptables -S | grep -i -E 'dns|53'

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

sudo iptables -I OUTPUT 1 -p udp --dport 53 -d 172.20.8.1 -j ACCEPT

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

ทำไมหน้าทดสอบการรั่วไหลจึงพิสูจน์ได้น้อยกว่าที่เห็น

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

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