การทำอุโมงค์แบบเต็มรูปแบบง่ายกว่าบัญชีอุโมงค์แบบแยกส่วนที่ยาวหรือไม่?
บัญชีข้อยกเว้นที่ครอบคลุมแอปส่วนใหญ่คือค่าเริ่มต้นที่ปลอมตัวอยู่ นับกฎ ตรวจสอบเกตเวย์ แล้วย้ายโปรไฟล์หนึ่งรายการและตรวจสอบขอบทั้งสองด้าน
บัญชีอุโมงค์แบบแยกส่วนเริ่มต้นด้วยแอปสามตัวและจบลงด้วยการครอบคลุมเครื่องส่วนใหญ่ และทุกบรรทัดใหม่คือข้อยกเว้นของใครบางคน ณ จุดนั้นบัญชีได้กลายเป็นค่าเริ่มต้นที่มีขั้นตอนเพิ่มเติมอย่างเงียบ ๆ การทำอุโมงค์แบบเต็มรูปแบบกลับด้านการจัดวาง ทุกอย่างเข้าสู่อุโมงค์เว้นแต่ข้อยกเว้นที่บันทึกไว้จะบอกเป็นอย่างอื่น ว่าสิ่งนั้นง่ายกว่าหรือไม่ขึ้นอยู่กับเกตเวย์และบริการภายในที่คุณจะทำให้เสีย
เริ่มต้นด้วยการนับกฎที่คุณดูแล
นับรายการ แล้วนับว่ามีกี่รายการที่มีเจ้าของระบุชื่อและวันที่ตรวจสอบครั้งล่าสุด ตัวเลขที่สองคือตัวเลขที่สำคัญ เพราะข้อยกเว้นที่ไม่มีเจ้าของไม่สามารถประเมินได้เมื่อซอฟต์แวร์ที่อ้างถึงถูกเปลี่ยนชื่อหรือถูกแทนที่ กฎที่ผูกกับพาธของไฟล์เรียกทำงานจะล้มเหลวอย่างเงียบ ๆ หลังการอัปเดต และความล้มเหลวนั้นดูเหมือน VPN ที่ไม่เสถียร ไม่ใช่กฎที่ล้าสมัย จดบัญชีไว้ก่อนที่คุณจะมีความเห็นเกี่ยวกับมัน
แต่ละรายการควรตอบสามคำถาม คือ อะไรพังหากไม่มีมัน ใครเป็นผู้ตัดสินใจ และคุณจะสังเกตได้อย่างไรว่ามูลเหตุหมดอายุ รายการที่ไม่สามารถตอบทั้งสามข้อเป็นผู้สมควรถูกลบมากกว่าถูกย้าย และการลบรายการเหล่านั้นก่อนทำให้การเปรียบเทียบในภายหลังซื่อตรง
หากรายการส่วนใหญ่กำหนดเส้นทางปริมาณมากของการรับส่งข้อมูล คุณกำลังเรียกใช้อุโมงค์แบบเต็มพร้อมภาระการบำรุงรักษาอยู่แล้ว การตัดสินใจจึงอยู่ที่ว่าค่าเริ่มต้นอาศัยอยู่ที่ใด ไม่ใช่ว่าควรมีหรือไม่
ตรวจสอบว่าเกตเวย์รับค่าเริ่มต้นไหวหรือไม่
การทำอุโมงค์แบบเต็มรูปแบบย้ายทุกแพ็กเก็ตไปยังอุปกรณ์เดียว ซึ่งเปลี่ยนภาระ CPU ตาราง conntrack การแปลที่อยู่ และความต้องการแบนด์วิดท์ขาขึ้นของอุปกรณ์นั้นในเวลาเดียวกัน เกตเวย์ที่ให้บริการซับเน็ตภายในไม่กี่ตัวได้อย่างสบายอาจไม่ได้ถูกกำหนดขนาดสำหรับการท่องเว็บทั้งหมดของผู้ใช้หนึ่งคน มองจำนวนเซสชันพร้อมกันสูงสุดที่คุณคาดไว้ ไม่ใช่ค่าเฉลี่ย เพราะจุดสูงสุดคือสิ่งที่พังก่อน
ip -s link show dev tun0
conntrack -C
ss -sวัดภาระงานเดียวกันก่อนและหลังการเปลี่ยนแปลงแทนการให้เหตุผลจากสเปก หนึ่งบ่ายของการใช้งานปกติบนเครื่องเดียวจะแสดงว่าเกตเวย์ใกล้ขีดจำกัดหรือไม่ และไม่มีค่าใช้จ่ายใด ๆ เทียบกับการค้นพบในเช้าวันจันทร์
ตรวจสอบ path MTU จากต้นจนจบด้วย เพราะค่าเริ่มต้นแบบเต็มทำให้ทุกแอปเผชิญกับขนาดแพ็กเก็ตสูงสุดของอุโมงค์ แอปที่เคยทำงานนอกอุโมงค์อาจต้องพึ่งพฤติกรรมการแบ่งส่วนที่คุณไม่เคยต้องคิดถึง
ยืนยันว่าบริการภายในและ DNS ส่วนตัวยังทำงาน
แจกแจงสิ่งที่ต้องอยู่ภายในตามโปรโตคอล ไม่ใช่ตามชื่อแอป โปรโตคอลการค้นพบสำหรับเครื่องพิมพ์และจอภาพ สะพานบ้านอัจฉริยะ หน้าจัดการของเราเตอร์ เซิร์ฟเวอร์พัฒนาภายในที่เข้าถึงด้วยชื่อซึ่งแก้ได้เฉพาะใน LAN สิ่งเหล่านี้พังเมื่อเส้นทางเริ่มต้นเริ่มชี้เข้าสู่อุโมงค์ และพังอย่างเงียบ ๆ เพราะไม่มีอะไรบันทึกข้อผิดพลาดที่ไคลเอนต์
DNS ส่วนตัวคือการพึ่งพาอีกอย่าง หากชื่อภายในเคยถูกแก้โดยตัวแก้ชื่อของอุโมงค์ ไม่มีอะไรเปลี่ยน หากถูกแก้ภายใน ค่าเริ่มต้นแบบเต็มต้องพาพวกมันไปยังตัวแก้ชื่อที่รู้จักโซน ทดสอบชื่อภายในหนึ่งชื่อและชื่อสาธารณะหนึ่งชื่อหลังการเปลี่ยนแปลง แทนที่จะสมมติว่ารายการตัวแก้ชื่อรอดชีวิต
เขียนข้อยกเว้นภายในลงในโปรไฟล์ที่เป็นเจ้าของมัน ข้อยกเว้นที่เก็บไว้เพียงในความจำของใครบางคนคือสิ่งแรกที่การย้ายครั้งถัดไปสูญเสีย
ย้ายโปรไฟล์หนึ่งรายการและตรวจสอบขอบเขต
เปลี่ยนโปรไฟล์ผ่านการกำหนดค่าที่เป็นเจ้าของมัน แทนที่จะวางค่าเริ่มต้นใหม่ทับเส้นทางที่ทำด้วยมือซึ่งถูกทิ้งไว้จากการทดลองก่อนหน้า เส้นทางที่เหลือเหล่านั้นคือสาเหตุปกติของการย้ายที่ดูเหมือนทำงานและมีพฤติกรรมไม่สอดคล้องในอีกหนึ่งวันต่อมา เก็บโปรไฟล์เก่าไว้ให้ใช้ได้ เพื่อให้การย้อนกลับเป็นการเลือก ไม่ใช่การสร้างใหม่
จากนั้นตรวจสอบสองขอบเขตแยกกัน ว่าปลายทางสาธารณะและส่วนตัวทั้งคู่ทำงาน และการรับส่งข้อมูลที่ไม่ต้องการไม่ออกไปนอกอุโมงค์ การโหลดหน้าที่สำเร็จพิสูจน์ข้อแรกและไม่บอกอะไรเกี่ยวกับข้อที่สอง
ip route get 203.0.113.10
ip route get 10.40.8.15
resolvectl query intranet.example
curl -sS -o /dev/null -w "%{remote_ip}\n" https://example.comทำการตรวจสอบซ้ำหลังการเชื่อมต่อใหม่และหลังการหยุดชะงัก เพราะ kill switch ที่บล็อกการรับส่งข้อมูลระหว่างการหลุดเป็นคุณสมบัติที่ต่างจากเส้นทางที่กลับมาทำงานถูกต้องในภายหลัง การออกแบบที่ง่ายกว่าคือแบบที่คุณยังอธิบายความครอบคลุมจริงของมันได้หลังแอปหรือเครือข่ายเปลี่ยนไป