สิ่งที่ route-nopull ของ OpenVPN หยุดไม่ให้เซิร์ฟเวอร์ผลักจริง ๆ
route-nopull ทิ้งเส้นทางและตัวเลือก DHCP ที่ถูกผลักมา ไม่ใช่แฮนด์เชก เลือกระหว่างมัน pull-filter หรือไม่ใช้เลย จากนั้นเพิ่มเส้นทางเอง
คุณใส่ route-nopull ในโปรไฟล์ไคลเอนต์เพื่อไม่ให้อุโมงค์กลืนเส้นทางเริ่มต้นของคุณ และตอนนี้ซับเน็ตของสำนักงานก็เข้าถึงไม่ได้ ขณะที่ไคลเอนต์ยังบอกว่าเชื่อมต่ออยู่ ข้อสังเกตทั้งสองเป็นจริง และไม่มีอะไรล้มเหลว แฟล็กนี้บอกไคลเอนต์ให้ข้ามเส้นทางและรายการ DHCP ที่เซิร์ฟเวอร์ผลักมา ซึ่งเป็นคำสั่งที่แคบกว่าที่คนส่วนใหญ่คาดเมื่อเพิ่มเข้าไป สิ่งที่เหลืออยู่คืออุโมงค์ที่ทำงานได้โดยไม่มีความเห็นว่าปลายทางใดควรใช้มัน
ช่องว่างนั้นคือการตัดสินใจทั้งหมดที่บทความนี้พูดถึง ไม่ว่าเซิร์ฟเวอร์จะเป็นผู้บรรยายเครือข่าย หรือไคลเอนต์ และแฟล็กก็มอบงานนั้นให้ไคลเอนต์โดยไม่ทำอะไรให้คุณเลย
แฟล็กปิดอะไรเมื่อเชื่อมต่อ
ไคลเอนต์ OpenVPN ที่ดึงข้อมูลมักได้รับชุดจากเซิร์ฟเวอร์หลังการยืนยันตัวตน: เส้นทาง การเปลี่ยนเส้นทางเกตเวย์เริ่มต้น เซิร์ฟเวอร์ DNS และคำสั่งปรับแต่งเล็กน้อย เมื่อ route-nopull มีผล ไคลเอนต์ยังคงยอมรับเซสชัน ยังตรวจสอบใบรับรอง ยังเจรจาเรื่องไซเฟอร์และ keepalive และยังยกอินเทอร์เฟซขึ้น สิ่งที่มันทิ้งคือการนำบรรทัด route ที่ถูกผลักมาและบรรทัด dhcp-option ที่ถูกผลักมาไปใช้ รวมถึง DNS ด้วย
ความสับสนมาจากไฟเขียวที่อยู่ข้างแอปพลิเคชันที่ตายแล้ว อุโมงค์มีอยู่ แต่การแมปปลายทางไปยังอุโมงค์นั้นไม่มี ไม่มีอะไรในแผงสถานะของไคลเอนต์แยก «เชื่อมต่อและกำหนดเส้นทาง» ออกจาก «เชื่อมต่อแต่ไม่ทำงาน» เพราะจากมุมมองของอุโมงค์ทั้งสองเป็นสถานะเดียวกัน
ทำไมอุโมงค์ที่ยังมีชีวิตจึงยังกำหนดเส้นทางอะไรไม่ได้
อินเทอร์เฟซปรากฏขึ้นพร้อมที่อยู่ของตัวเอง และบนลิงก์แบบจุดต่อจุดมักไม่มีอะไรเฉพาะเจาะจงไปกว่าเส้นทางโฮสต์ไปยังคู่ตรงข้าม ซับเน็ตส่วนตัวจะเข้าถึงได้ก็ต่อเมื่อมีเส้นทางบางเส้นชี้ไปที่อินเทอร์เฟซนั้นด้วยคำนำหน้าที่ถูกต้อง และเมื่อปิดการผลัก เส้นทางนั้นก็ไม่เคยมาถึง นั่นคือเหตุผลที่อินเทอร์เฟซดูแข็งแรงได้ขณะที่ซับเน็ตยังมืดอยู่
การอ่านโปรไฟล์จึงพิสูจน์ได้น้อยมาก ให้อ่านสถานะที่กำลังทำงานบนเครื่องที่เชื่อมต่อแทน:
ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10ที่อยู่ที่ไม่มีเส้นทางซับเน็ตในคำสั่งที่สองคือลายเซ็นของปัญหานี้ คำสั่งที่สามตอบคำถามที่ผู้ใช้สนใจจริง เพราะมันรายงานอินเทอร์เฟซที่เคอร์เนลจะเลือกสำหรับปลายทางเฉพาะ แทนรายการที่คุณหวังว่าจะใช้ ถ้ามันตอบผ่านลิงก์กายภาพของคุณ อุโมงค์ก็ไม่ได้อยู่ในเส้นทางเลย
การแปลงชื่อล้มเหลวด้วยเหตุผลที่เกี่ยวข้อง ไม่ใช่เหตุผลแยกต่างหาก รายการ dhcp-option DNS ที่ถูกผลักมาถูกข้ามด้วยแฟล็กเดียวกัน คำถามเกี่ยวกับโฮสต์ภายในจึงไปยังตัวแปลงชื่อใดก็ตามที่เครือข่ายท้องถิ่นให้มา ตัวแปลงนั้นไม่มีโซนสำหรับสำนักงาน คำถามจึงล้มเหลวหรือคืนคำตอบสาธารณะ และความล้มเหลวดูเหมือนปัญหาเซิร์ฟเวอร์ทั้งที่เป็นปัญหาการกำหนดค่าไคลเอนต์ การทดสอบที่อยู่ก่อนชื่อคือสิ่งที่แยกสองอย่างนี้ออก
เลือกระหว่างแฟล็กกับตัวกรองคำนำหน้า
สองตัวเลือกแก้รูปร่างต่าง ๆ ของข้อร้องเรียนเดียวกัน และการเลือกผิดคือสิ่งที่สร้างสถานะเชื่อมต่อแต่ไร้ประโยชน์ ตัวหนึ่งแทนที่นโยบายที่ถูกผลักมาทั้งหมด อีกตัวแก้ไขตามคำนำหน้า ตารางให้เวอร์ชันสั้น และย่อหน้าถัดไปครอบคลุมส่วนที่ทำให้คนแปลกใจ
| Setting | What the client keeps | Reasonable when |
|---|---|---|
| no option | every pushed route and DHCP entry | the server's view of the network is correct |
route-nopull | the session, none of the pushed routing or DNS | you will write the full local policy yourself |
pull-filter | everything except lines matching your prefixes | the push is nearly right and one or two lines are wrong |
pull-filter เป็นตัวจับคู่คำนำหน้าที่มีสามคำกริยา จึงยอมรับตระกูลของบรรทัดได้ เพิกเฉยอย่างเงียบ ๆ หรือปฏิเสธการเชื่อมต่อทั้งหมดเมื่อมีคำนำหน้าปรากฏ พฤติกรรมสุดท้ายคือสิ่งที่ควรรู้: กฎการปฏิเสธเปลี่ยนความขัดแย้งเชิงนโยบายให้เป็นแฮนด์เชกที่ล้มเหลวแทนที่จะเป็นการละเว้นอย่างเงียบ คู่มือ OpenVPN 2.6 แสดงรายการคำนำหน้าที่รับได้และความหมายที่แน่นอนของแต่ละคำกริยา
ทางสายกลางที่พบบ่อยคือปฏิเสธเฉพาะ redirect-gateway และปล่อยให้เส้นทางสำนักงานและ DNS มาถึงตามที่ตั้งใจไว้ นั่นทำให้การผลักยังทำงานสำหรับส่วนที่เซิร์ฟเวอร์เข้าใจดีกว่าคุณ พร้อมกันนั้นก็ป้องกัน บรรทัดเดียวที่จะยึดเส้นทางเริ่มต้นของคุณ
เพิ่มเส้นทางและตัวแปลงชื่อด้วยมือ
ถ้าคุณเก็บแฟล็กไว้ โปรไฟล์ต้องพูดในสิ่งที่เซิร์ฟเวอร์จะพูด คำสั่งฝั่งไคลเอนต์ route ถูกนำไปใช้หลังการเชื่อมต่อถูกสร้างขึ้น จึงทำงานเคียงข้างแฟล็กแทนที่จะถูกบล็อกโดยมัน ใส่ไว้ในโปรไฟล์ ไม่ใช่ในบรรทัดคำสั่งแบบโต้ตอบ มิฉะนั้นการเชื่อมต่อใหม่ครั้งถัดไปจะไม่สร้างสถานะที่ทำงานได้ซ้ำ
route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53บรรทัด DNS อยู่ในตำแหน่งที่ไม่สบายใจ: มันเป็นคำสั่งฝั่งไคลเอนต์ แต่ไคลเอนต์บางตัวนำไปใช้ผ่านการรวม DNS ของแพลตฟอร์มเท่านั้น ซึ่งอาจเขียนทับเมื่อลิงก์เปลี่ยน บนโฮสต์ systemd การตั้งตัวแปลงชื่อบนอินเทอร์เฟซอุโมงค์โดยตรงคาดเดาได้มากกว่าการหวังว่าไคลเอนต์จะชนะการแข่งขันลำดับความสำคัญ:
resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.comโดเมนการกำหนดเส้นทางสำคัญเท่ากับที่อยู่ หากไม่มี คำถามเกี่ยวกับชื่อสาธารณะอาจถูกส่งไปยังตัวแปลงชื่อภายในด้วย และตัวแปลงชื่อภายในใดที่ปฏิเสธการเรียกซ้ำจะทำให้การท่องเว็บพังในขณะที่โซนส่วนตัวยังทำงานอยู่ ด้วยโดเมนนี้ เฉพาะชื่อใต้คำต่อท้ายนั้นเท่านั้นที่ถูกกำหนดเส้นทางไปยังตัวแปลงชื่อของอุโมงค์ และทุกอย่างอื่นไปตามลิงก์กายภาพ
ตรวจสอบผลลัพธ์: ที่อยู่ ชื่อ และเส้นทางภายนอก
การทดสอบสามอย่างแยกความล้มเหลวที่เป็นไปได้ ดึงที่อยู่ส่วนตัวด้วย IP จากนั้นโฮสต์เดียวกันด้วยชื่อ จากนั้นเว็บไซต์สาธารณะทั่วไป IP ที่ทำงานได้แต่ชื่อล้มเหลวชี้ไปที่ตัวแปลงชื่อ IP ที่ล้มเหลวแต่ชื่อทำงานได้ชี้ไปที่การกำหนดเส้นทาง ถ้าทั้งสองล้มเหลวมักหมายความอุโมงค์ไม่ได้อยู่ในเส้นทาง
จากนั้นมองออกไปข้างนอกไม่ใช่ข้างใน เส้นทางของปลายอุโมงค์เองต้องอยู่รอดจากการเปลี่ยนแปลง และความล้มเหลวที่ปิดกั้นใด ๆ ต้องจำกัดอยู่ที่อุโมงค์โดยไม่จับปลายทาง ไคลเอนต์ที่ยังท่องเว็บต่อหลังอุโมงค์ล่มเป็นปัญหานโยบาย ไม่ใช่การกำหนดเส้นทาง และจะไม่ปรากฏในการทดสอบทั้งสามข้างต้น
เขียนรายการสุดท้ายลงในเอกสารของโปรไฟล์: เส้นทาง ตัวแปลงชื่อ โดเมน และเหตุผลที่แต่ละอย่างมีอยู่ การเชื่อมต่อใหม่ที่สร้างตารางเดิมซ้ำคือหลักฐานเดียวว่านโยบายท้องถิ่นสมบูรณ์ หากแอปพลิเคชันยังล้มเหลวทั้งที่อุโมงค์ขึ้นและผ่านทั้งสามการทดสอบ ที่ต่อไปที่ควรดูคือกลุ่มปัญหาเชื่อมต่อได้แต่ไม่ออนไลน์ ไม่ใช่ใบรับรองที่ตรวจสอบแล้ว