pull-filter ของ OpenVPN จับได้มากกว่าเส้นทางที่คุณตั้งใจ
pull-filter เปรียบเทียบข้อความของคุณเป็นคำนำหน้ากับตัวเลือกที่ถูกส่งมา ดังนั้น route จึงจับ route-gateway และ route-ipv6 ด้วย ตรวจสอบคำกริยาก่อน แล้วจึงตรวจเส้นทาง
คุณเพิ่มหนึ่งบรรทัดเพื่อเก็บเส้นทางค่าเริ่มต้นภายในเครื่องไว้ และหลังจากนั้นอุโมงค์ก็ไปไม่ถึงเซิร์ฟเวอร์ DNS ภายในอีกต่อไป บรรทัดนั้นคือ pull-filter ignore "route" ซึ่งไม่ได้หมายความว่า "เพิกเฉยเส้นทางนี้" แต่หมายความว่า "ทิ้งทุกตัวเลือกที่ถูกส่งมาซึ่งข้อความเริ่มต้นด้วยห้าตัวอักษรนั้น" และบนเซิร์ฟเวอร์ทั่วไปสิ่งนั้นรวมถึง route-gateway, route-metric และ route-ipv6 พร้อมกับเส้นทางเองด้วย รายการตรวจสอบด้านล่างคือสิ่งที่ฉันทำก่อนจะแตะโปรไฟล์ที่คนอื่นต้องใช้
ตัวกรองทำงานเฉพาะกับตัวเลือกที่ถูกส่งมา
pull-filter ทำงานเฉพาะกับบรรทัดตัวเลือกที่เซิร์ฟเวอร์ส่งมาหลังจากสร้างอุโมงค์แล้วเท่านั้น และไม่ทำอะไรอื่น ตัวเลือกที่เขียนในไฟล์ภายในเครื่องของคุณไม่ได้รับผลกระทบ และทราฟฟิกของแอปพลิเคชันก็เช่นกัน หากคุณหวังจะหยุดกระบวนการไม่ให้ใช้อุโมงค์ นี่คือเครื่องมือที่ผิดอย่างสิ้นเชิง และการผสมตัวกรองแบบใดก็ไม่ทำให้ได้
ขอบเขตนั้นมีประโยชน์เพราะหมายความว่าคุณปล่อยการตั้งค่าของเซิร์ฟเวอร์ไว้ได้ และยังปฏิเสธบางส่วนของมันได้ในเครื่อง มันยังเป็นข้อจำกัดที่ควรบันทึกไว้ในตั๋ว: ตัวกรองเปลี่ยนสิ่งที่ไคลเอนต์นี้ยอมรับ ไม่ใช่สิ่งที่เซิร์ฟเวอร์เสนอ มันไม่มีผลกับผู้ใช้อื่นของโปรไฟล์เดียวกัน และไม่คงอยู่เมื่อเปลี่ยนไปยังไคลเอนต์อื่นที่ไม่รองรับตัวเลือกนี้ ซึ่งควรรู้ก่อนจะสร้างขั้นตอนการทำงานบนมัน
ยืนยันว่าเซิร์ฟเวอร์ส่งอะไรมาจริง ๆ ก่อนเขียนรูปแบบ เมื่อระดับความละเอียดสูงไคลเอนต์จะพิมพ์สตริงตัวเลือกที่ถูกส่งมาซึ่งได้รับมา และนั่นคือแหล่งเดียวที่ซื่อตรงสำหรับข้อความที่คุณใช้เปรียบเทียบ:
sudo openvpn --config /etc/openvpn/corp.ovpn --verb 4
sudo grep -n 'pull-filter' /etc/openvpn/corp.ovpnอ่านบรรทัดที่ถูกส่งมาเป็นรายการตัวเลือกที่คั่นด้วยเครื่องหมายจุลภาค และสังเกตว่าชื่อตัวเลือกกับอาร์กิวเมนต์คั่นด้วยช่องว่าง ข้อความตัวกรองของคุณถูกเปรียบเทียบกับสตรีมนั้น จึงเป็นเหตุผลว่าทำไมช่องว่างจึงสำคัญมากในขั้นตอนถัดไป
การจับคู่เป็นคำนำหน้าของสตริง ไม่ใช่ชื่อตัวเลือกที่แยกวิเคราะห์แล้ว
การเปรียบเทียบเป็นคำนำหน้าของสตริง ไม่ใช่ชื่อตัวเลือกที่แยกวิเคราะห์แล้ว ดังนั้น "route" จึงตรงกับ route-gateway 10.8.0.1, route-ipv6 2001:db8::/32 และ route-metric 100 การเพิ่มช่องว่างหนึ่งช่องที่ท้ายจะจำกัดให้แคบลงถึงกลุ่มที่คุณน่าจะหมายถึง และคำนำหน้าเต็มจะจำกัดให้แคบลงอีกถึงปลายทางเฉพาะ
| Filter text | What it actually matches | Typical outcome |
|---|---|---|
"route" | Every option beginning with those letters | Routes, gateway, metric and IPv6 routes all dropped |
"route " | Route entries only, not the hyphenated siblings | The routes go, the rest survives |
"route 10.60." | A single destination range | The narrowest rule, and the easiest to audit |
"dhcp-option DNS" | Pushed DNS settings | Resolver stays local, internal names stop resolving |
แถวสุดท้ายคือแถวที่จับคนระหว่างทำงานกับอุโมงค์แบบแยก การเก็บตัวแก้ไขชื่อของคุณเองเป็นทางเลือกที่ชอบธรรม และหมายความว่าทุกชื่อภายในตอนนี้อาศัยตัวแก้ไขที่ไม่เห็นโซนส่วนตัว นั่นคือผลที่ยอมรับโดยเจตนา ไม่ใช่ผลข้างเคียงที่ค้นพบในการผลิต
การจับคู่ด้วยคำนำหน้ายังหมายความว่ากฎหนึ่งอาจขยายกว้างขึ้นอย่างเงียบ ๆ ในภายหลัง เมื่อเซิร์ฟเวอร์เพิ่มตัวเลือกใหม่ที่เริ่มต้นด้วยข้อความของคุณ ตัวกรองของคุณก็เริ่มใช้กับตัวเลือกนั้นโดยไม่มีใครแก้ไขโปรไฟล์ของคุณ นี่คือโหมดความล้มเหลวที่ต้องออกแบบให้รับมือ และการบรรเทาคือจับคู่ส่วนของตัวเลือกให้มากที่สุด ไม่ใช่ให้น้อยที่สุด
สามคำกริยา สามผลลัพธ์ที่ต่างกัน
accept, ignore และ reject ไม่ใช่สามการสะกดของแนวคิดเดียวกัน พวกมันต่างกันที่ไคลเอนต์ทำอะไรกับการจับคู่ และที่ว่าใครจะรู้เรื่องนี้
ignore ทิ้งตัวเลือกที่ตรงกันอย่างเงียบ ๆ ซึ่งเป็นสิ่งที่คุณต้องการสำหรับการตั้งค่าที่คุณแทนที่โดยเจตนา reject ทิ้งมันและทำให้ไคลเอนต์บ่น ซึ่งเป็นสิ่งที่คุณต้องการเมื่อการไม่มีอยู่ควรเห็นได้ในบันทึกแทนที่จะถูกค้นพบภายหลัง accept เป็นรูปแบบเชิงบวก ใช้เมื่อคุณสร้างรายการอนุญาตแทนที่จะลบตัวเลือกทีละตัว
ไม่ว่าคุณจะใช้คำกริยาใด ตัวกรองจะถูกใช้ตามลำดับที่ปรากฏ ดังนั้นกฎสองข้อที่ทับซ้อนกันจะให้ผลลัพธ์ที่ขึ้นกับลำดับและตรวจทานได้ยากมาก เก็บกฎหนึ่งข้อต่อหนึ่งเจตนา และใส่ข้อความที่เจาะจงที่สุดในแต่ละข้อ หากต้องการรายการอนุญาต ให้เลือกกฎ accept ไม่กี่ข้อแทนที่จะเป็นกองกฎ ignore ที่รวมกันได้เท่ากัน จากนั้นผู้ตรวจทานสามารถอ่านไฟล์จากบนลงล่างและคาดการณ์ผลลัพธ์ได้ และนั่นคือการทดสอบเดียวที่ขยายได้
ตรวจสอบเส้นทางและตัวแก้ไขที่ถูกใช้ ไม่ใช่โปรไฟล์
ตัวกรองที่ดูถูกต้องในไฟล์ยังอาจทำให้คุณเหลืออุโมงค์ที่ไม่ส่งต่ออะไรที่มีประโยชน์ ตรวจสอบผลบนระบบที่กำลังทำงาน ซึ่งตัวเลือกที่ถูกส่งมาได้ถูกใช้หรือทิ้งไปแล้ว:
ip route show default
ip route show | grep -c 'proto static'
resolvectl status | grep -A4 'Link.*tun0'
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://intranet.example.internal/สองบรรทัดแรกบอกคุณว่า เส้นทางค่าเริ่มต้นที่ถูกส่งมาถึงแล้วหรือไม่ และมีรายการแบบคงเหลือรอดกี่รายการ การสอบถามตัวแก้ไขแสดงว่าเซิร์ฟเวอร์ใดที่อินเทอร์เฟซอุโมงค์ใช้จริง และโดยปกติที่นั่นคือที่ที่ความประหลาดใจเรื่อง DNS ปรากฏขึ้น บรรทัดสุดท้ายตอบคำถามเดียวที่สำคัญสำหรับผู้ใช้
ทดสอบทั้งสองทิศทางขณะอยู่ที่นั่น กฎที่ทำให้อินเทอร์เน็ตภายในเครื่องของคุณยังทำงานแต่ทำลายการแปลงชื่อภายในอย่างเงียบ ๆ จะผ่านการตรวจสอบผิวเผินและล้มเหลวในงานจริงงานแรก ดังนั้นให้ใส่ทรัพยากรภายในหนึ่งอย่างและเว็บไซต์สาธารณะหนึ่งแห่งในการทดสอบเดียวกัน
บันทึกข้อยกเว้นและผู้เป็นเจ้าของ
ตัวกรองเป็นข้อยกเว้นต่อการออกแบบของผู้ดูแล ดังนั้นจดบันทึกพร้อมเหตุผลและจุดตรวจทาน "เพิกเฉยเส้นทางที่ถูกส่งมาเพื่อเก็บค่าเริ่มต้นในเครื่อง" ตรวจทานได้ ส่วนบรรทัดเปล่าในโปรไฟล์ตรวจทานไม่ได้ และคนถัดไปจะลบมันหรือขยายมันด้วยการเดา
เวอร์ชันก็สำคัญที่นี่เช่นกัน พฤติกรรมการจับคู่และไวยากรณ์ที่ยอมรับได้แน่นอนได้รับการปรับปรุงตลอด OpenVPN 2.4, 2.5 และ 2.6 ดังนั้นยืนยันรูปแบบกับคู่มือของบิลด์ที่คุณส่งมอบ ไม่ใช่กับโพสต์ฟอรัมเกี่ยวกับรุ่นเก่า คู่มือ OpenVPN 2.6 เอกสารตัวเลือกนี้และกฎการจับคู่ของมัน
สุดท้าย ตกลงข้อยกเว้นกับผู้ที่ดูแลเซิร์ฟเวอร์ ตัวกรองฝั่งไคลเอนต์ที่ขัดกับนโยบายเซิร์ฟเวอร์โดยเจตนาเป็นเหตุการณ์สนับสนุนที่รอการตรวจสอบครั้งถัดไป และถูกกว่ามากที่จะสะสางก่อนโปรไฟล์ถูกส่งออกไป มากกว่าหลังจากมีคนสังเกตว่าเส้นทางหายไป