pull-filter เปรียบเทียบข้อความ ไม่ใช่ซับเน็ต: อ่านมันเป็นคำนำหน้า
ตัวกรองเปรียบเทียบจุดเริ่มต้นของแต่ละออปชันที่พุชมากับข้อความของคุณ ช่องว่างที่หายไป กฎกว้างก่อนหน้า และการกระทำที่ผิดทำให้เกิดความผิดพลาดต่างกัน
เจตนาคือจะทิ้งเส้นทางที่พุชมาหนึ่งเส้น หลังการเปลี่ยนแปลง ออปชันการกำหนดเส้นทางอื่นหายไป หรือไคลเอนต์เชื่อมต่อใหม่เป็นวงจร ผลลัพธ์ทั้งสองมาจากการอ่านตัวกรองเป็นกฎซับเน็ตทั้งที่มันเปรียบเทียบข้อความ ไคลเอนต์ตรวจว่าออปชันที่พุชมาเริ่มต้นด้วยอักขระที่คุณให้ไว้หรือไม่ และไม่มีตรรกะเรื่องที่อยู่ในขั้นตอนใดเลย
สิ่งที่ตัวกรองเปรียบเทียบจริง
ออปชันที่พุชมาแต่ละรายการมาเป็นบรรทัดที่ประกอบด้วยชื่อและอาร์กิวเมนต์ของมัน ตัวกรองเปรียบเทียบอักขระของคุณกับจุดเริ่มต้นของบรรทัดนั้น ก่อนที่ที่อยู่ใดจะถูกแยกวิเคราะห์และก่อนที่จะติดตั้งเส้นทางใด ดังนั้นกฎที่เขียนสำหรับชื่อหนึ่งจะจับทุกออปชันที่เริ่มต้นด้วยตัวอักษรเหล่านั้น ไม่ใช่แค่ตัวที่คุณกำลังดูอยู่ นี่คือเหตุผลที่ตัวกรองอาจดูถูกต้องเมื่อมองแยกเดี่ยวแต่ก็ยังลบสิ่งที่เกี่ยวข้องไม่ได้
สตริงที่ดูเหมือนช่วงเครือข่ายยังคงเป็นเพียงอักขระ มันไม่ได้เลือกคำนำหน้า ไม่ได้คำนวณบนบิตเครือข่าย และไม่สามารถแสดงชุดปลายทางได้ เมื่อกฎแบบนั้นดูเหมือนทำงานแล้วหยุดลง ข้อความที่พุชมามักเปลี่ยนรูปร่างไป
ช่องว่างหนึ่งช่องเปลี่ยนชุดการจับคู่
ชื่อออปชันเดียวกันที่มีและไม่มีตัวคั่นท้ายเลือกคนละบรรทัด หากไม่มีตัวคั่น การจับคู่จะเปิดค้างไว้ แต่หากมีชื่อออปชันต้องสิ้นสุดตรงนั้นก่อนที่อาร์กิวเมนต์จะเริ่ม
pull-filter ignore "route"
pull-filter ignore "route "
รูปแบบเปิดยังจับออปชันที่เพียงเริ่มต้นด้วยตัวอักษรเดียวกัน และนั่นคือวิธีที่ พฤติกรรมการกำหนดเส้นทางที่ไม่เกี่ยวข้องหายไปพร้อมกับเส้นทางที่คุณต้องการทิ้ง คัดลอกบรรทัดที่พุชมาจากบันทึกก่อนเขียนตัวกรอง เก็บสำเนาโปรไฟล์ที่ไม่แก้ไขไว้ข้างฉบับที่แก้แล้ว เพราะการย้อนการจับคู่แบบกว้างทำได้ง่ายจากไฟล์มากกว่าจากความจำ
ลำดับและการกระทำให้อาการต่างกัน
กฎถูกประเมินตามลำดับและการจับคู่แรกเป็นตัวตัดสินผล ดังนั้นกฎกว้างที่วางไว้แต่เนิ่นๆ ทำให้ทุกกฎเฉพาะที่ตามมาถูกเข้าถึงไม่ได้ การกระทำก็เปลี่ยนความผิดพลาดเช่นกัน การเพิกเฉยต่อการจับคู่จะทิ้งออปชันและเซสชันดำเนินต่อ ขณะที่การปฏิเสธทำให้เกิดข้อผิดพลาดที่รีสตาร์ตการเชื่อมต่อ ดังนั้นบรรทัดที่ถูกพุชซ้ำๆ รวมกับการกระทำแบบปฏิเสธจึงสร้างวงจรการเชื่อมต่อใหม่ วงจรนั้นอ่านผิดว่าเป็นความผิดพลาดของเครือข่ายได้ง่าย และบรรทัดบันทึกที่ระบุออปชันที่จับคู่ได้คือสิ่งที่แยกสองกรณีนี้ออกจากกัน
| Action | Effect on the session | How it gets reported |
|---|---|---|
| Ignore | Option dropped, session continues | Something is missing afterwards |
| Reject | Error raised, connection restarts | The VPN keeps dropping |
บันทึกว่าบรรทัดใดจับคู่และการกระทำใดทำงาน เส้นทางที่ถูกทิ้งและวงจรรีสตาร์ตต้องซ่อมต่างกัน และบันทึกควรบอกว่าเกิดกรณีใดแทนที่จะปล่อยทั้งสองไว้เปิด
ตรวจสอบว่าโฮสต์ติดตั้งอะไร
อ่านเส้นทางที่ใช้งานหลังเชื่อมต่อใหม่ และทดสอบปลายทางที่คุณต้องการเก็บไว้รวมถึงปลายทางที่ต้องการลบ การทิ้งเส้นทางที่พุชมาไม่ได้ให้สิ่งทดแทน ดังนั้นทรัพยากรอาจเข้าถึงไม่ได้ผ่านเส้นทางอื่นในขณะที่เส้นทางที่ไม่ต้องการหายไปแล้ว ถ้าชื่อหนึ่งถูกแปลงที่อื่นตอนนี้ ให้ตรวจว่าออปชันตัวแปลงที่พุชมาถูกจับด้วยคำนำหน้าแบบกว้างเดียวกันหรือไม่ การเปลี่ยนแปลงที่ผ่านการทดสอบที่คุณรันแต่ล้มเหลวในการทดสอบที่คุณตั้งใจคือผลลัพธ์ปกติที่นี่
เก็บความต่างนั้นไว้ในตั๋ว: เส้นทางที่คุณลบ เส้นทางที่คุณคาดว่าจะเก็บไว้ และสิ่งที่ตารางแสดงตอนนี้ การเปลี่ยนแปลงครั้งหน้าจะถูกตัดสินเทียบกับบันทึกนั้น
อย่าถือว่ามันเป็นขอบเขตความไว้วางใจ
ตัวกรองบนข้อความเป็นความสะดวกในการกำหนดค่า ไม่ใช่การควบคุมต่อเซิร์ฟเวอร์ที่คุณไม่ไว้วางใจ เพียงรูปแบบที่ต่างกันก็เอาชนะมันได้ ซึ่งเป็นเหตุผลที่คู่มือจำกัดข้ออ้างนั้น เมื่อเซิร์ฟเวอร์เป็นขององค์กรคุณ การแก้ไขนโยบายการพุชชัดเจนกว่าการสะสมข้อยกเว้นในเครื่อง
เขียนว่าเหตุใดตัวกรองในเครื่องจึงมีอยู่ตั้งแต่แรก เพื่อให้คนถัดไปตัดสินได้ว่ายังจำเป็นหรือไม่ ตัวกรองสะสมมานานหลังจากเหตุผลหมดไปแล้ว