openfortivpn เขียนทับ DNS อยู่ตลอด? ค้นหาผู้ถือครองตัวจริง

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

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

เริ่มจากสิ่งที่การเชื่อมต่อเปลี่ยนจริง ๆ

เชื่อมต่อหนึ่งครั้งด้วยคำสั่งปกติของคุณและเปรียบเทียบการแปลงชื่อก่อนและหลัง บนโฮสต์ Linux ที่รัน systemd-resolved resolvectl status พิมพ์เซิร์ฟเวอร์ DNS และโดเมนค้นหาสำหรับแต่ละลิงก์ และลิงก์ tun หรือ ppp ใหม่ที่พกเซิร์ฟเวอร์ของตัวเองคือลายนิ้วมือของการอัปเดตจากฝั่งไคลเอนต์ บน macOS scutil --dns แสดงการกำหนดค่าตัวแปลงชื่อตามลำดับที่แอปพลิเคชันปรึกษามัน

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

สวิตช์สองตัวและผู้เขียนที่แต่ละตัวปิดปาก

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

openfortivpn gw.example.com:443 --no-dns --pppd-no-peerdns
# written out in long form
openfortivpn gw.example.com:443 --set-dns=0 --pppd-use-peerdns=0

--no-dns หยุดไคลเอนต์ไม่ให้ใช้เซิร์ฟเวอร์ DNS ที่เรียนรู้จากเกตเวย์ ขณะที่ --pppd-no-peerdns หยุด pppd ไม่ให้ดัน DNS ของคู่สัญญาเข้าสู่ระบบ คู่มือของ upstream เตือนว่าการอัปเดต DNS ผ่าน PPP อาจแข่งกับการอัปเดต DNS ของไคลเอนต์เอง ด้วยเหตุนี้สวิตช์ทั้งสองจึงควรอยู่ในส่วนดังกล่าว แทนที่จะถือว่าตัวใดตัวหนึ่งเพียงพอ

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

เลือกเจ้าของก่อนที่คุณจะปิดใช้งานสิ่งใด

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

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

ตรวจสอบการแปลงชื่อต่อลิงก์ ไม่ใช่ต่อไฟล์

/etc/resolv.conf เดียวไม่ใช่บัญชีรายการของสิ่งที่แอปพลิเคชันใช้จริงบนโฮสต์ที่มีการแปลงชื่อแบบจำกัดขอบเขตหรือตามโดเมน ดังนั้นจงอ่านสถานะของตัวแปลงชื่อในแบบที่แพลตฟอร์มเปิดเผย

resolvectl status
resolvectl query vpn.internal.example.com
resolvectl query example.com
ip route get 10.20.0.53

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

เชื่อมต่อใหม่และยืนยันสถานะที่ตัดการเชื่อมต่อ

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

จากนั้นเชื่อมต่อใหม่และอ่านค่าสามค่าเดิมอีกครั้ง ที่อยู่ตัวแปลงชื่อ โดเมนค้นหา อินเทอร์เฟซ

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