ทำไมไวลด์การ์ดในไดเรกทีฟ route ของ OpenVPN จึงใช้งานไม่ได้

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

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

เส้นทางติดตั้งอะไร และอะไรที่มันไม่เคยอ่าน

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

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

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

เมื่อปลายทางเป็นคำนำหน้าจริง ๆ

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

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

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

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

เมื่อหน่วยของงานคือชื่อโฮสต์

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

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

function FindProxyForURL(url, host) {
    var h = host.toLowerCase();
    if (h === "corp.example" || dnsDomainIs(h, ".corp.example")) {
        return "PROXY 10.60.0.12:3128";
    }
    return "DIRECT";
}

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

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

สิ่งที่ตัวเลือกพร็อกซีไม่ครอบคลุม

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

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

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

ทดสอบทั้งสองเส้นทาง ไม่ใช่แค่เส้นทางที่ราบรื่น

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

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

บทความที่เกี่ยวข้อง