รวมอย่างเดียวหรือยกเว้นอย่างเดียวสำหรับอุโมงค์แยก: ค่าเริ่มต้นควรเป็นแบบไหน
เลือกค่าเริ่มต้นก่อนสร้างรายการ: ส่งเฉพาะสิ่งที่คุณระบุชื่อเข้าไปในอุโมงค์ หรือส่งทุกอย่างแล้วตัดข้อยกเว้นออก จากนั้นทดสอบแอปที่ไม่มีใครใส่ไว้ในรายการ
เปิดส่วนการกำหนดเส้นทางในไคลเอนต์ VPN แล้วคุณจะเห็นตัวควบคุมสองแบบที่รูปร่างต่างกันแต่มักติดป้ายเดียวกัน ตัวหนึ่งให้คุณระบุปลายทางที่ควรอยู่ในอุโมงค์ ส่วนที่เหลือยังใช้เครือข่ายภายในตามเดิม อีกตัวถือว่าทุกอย่างผ่านอุโมงค์และถามว่าควรตัดอะไรกลับออกมา ทั้งสองแบบให้อุโมงค์ที่ใช้งานได้ในการทดสอบครั้งแรก และทั้งสองแบบดูแลรักษาด้วยการเพิ่มบรรทัดลงในรายการ นั่นคือเหตุผลที่ความต่างยังมองไม่เห็นจนกว่าจะมีคนติดตั้งอะไรใหม่
นี่คือการเลือกค่าเริ่มต้น ไม่ใช่คุณสมบัติ ควรตัดสินก่อนที่รายการจะมีรายการย่อยยี่สิบรายการ
อ่านค่าเริ่มต้นจากไคลเอนต์ ไม่ใช่จากโบรชัวร์
WireGuard ทำให้การตัดสินใจนี้เห็นได้ชัดเป็นพิเศษ เพราะ AllowedIPs เป็นรายการแบบรวมเท่านั้น ไม่มีความหมายอื่น เพียร์ที่มี 0.0.0.0/0, ::/0 จะส่งทุกอย่างเข้าอุโมงค์ ส่วนเพียร์ที่มี 10.20.0.0/16 จะส่งเฉพาะเครือข่ายนั้น ไม่มีไวยากรณ์สำหรับการยกเว้น ดังนั้นถ้าต้องการให้ซับเน็ตหนึ่งอยู่นอกอุโมงค์ คุณต้องระบุพรีฟิกซ์อื่นทั้งหมดหรือเพิ่มการกำหนดเส้นทางตามนโยบายนอกอินเทอร์เฟซ
OpenVPNไปถึงจุดเดียวกันจากทิศทางตรงข้าม โดย redirect-gateway def1 ติดตั้งอุโมงค์เต็มรูปแบบ และคำสั่ง route ที่ระบุชัดเจนจะเพิ่มหรือเขียนทับพรีฟิกซ์ที่เจาะจง ไคลเอนต์เชิงพาณิชย์มักซ่อนทั้งสองอย่างไว้หลังช่องทำเครื่องหมายและตารางปลายทาง ดังนั้นควรอ่านว่าตารางแก้ไขสิ่งใดจริง ๆ ก่อนเชื่อป้าย
คำถามที่ต้องถามไม่ใช่ชื่อของช่องทำเครื่องหมาย แต่คือสิ่งที่เกิดขึ้นกับแพ็กเก็ตที่ปลายทางไม่ปรากฏในรายการใดเลย เขียนคำตอบเป็นลายลักษณ์อักษรแล้วส่วนที่เหลือของการกำหนดค่าจะตามมาเอง ถ้าข้ามคำถามนี้ ความล้มเหลวครั้งแรกที่อธิบายไม่ได้จะถูกตัดสินโดยคนที่อยู่ใกล้ไคลเอนต์ที่สุดในวันนั้น
ตามรอยแอปที่ไม่มีใครใส่ไว้ในรายการ
ในการออกแบบแบบรวมอย่างเดียว แอปนั้นจะออกไปตรง ๆ ผ่านเครือข่ายภายในและ DNS ภายใน ในการออกแบบแบบยกเว้นอย่างเดียว มันจะผ่านอุโมงค์ตามที่เซิร์ฟเวอร์อนุญาต และนี่คือที่มาของความต่างระหว่างเครื่องมือ SaaS ใหม่ที่ใช้งานได้ตั้งแต่วันแรก กับตั๋วที่บอกว่า VPN ทำให้มันพัง
ไม่มีค่าเริ่มต้นใดปลอดภัยกว่าโดยตัวมันเอง แบบรวมอย่างเดียวจำกัดสิ่งที่อุโมงค์บรรจุและทำให้เครือข่ายภายในเป็นเส้นทางที่มีแรงต้านน้อยที่สุด ส่วนแบบยกเว้นอย่างเดียวถือว่าอุโมงค์เป็นเส้นทางปกติและปฏิบัติกับข้อยกเว้นในฐานะข้อยกเว้น ซึ่งใกล้เคียงกับสิ่งที่ นโยบายองค์กรส่วนใหญ่มุ่งหมายจริง ๆมากขึ้น
| Question | Include-only | Exclude-only |
|---|---|---|
| Unlisted new app | goes direct | goes through the tunnel |
| A site that breaks over the VPN | add it to the list | carve it out |
| Internal names still resolve | only if routed and served | usually, until split DNS says otherwise |
| Upkeep | one entry per internal service | one entry per misbehaving public service |
สังเกตว่าคุณลักษณะของวัตถุแบบใดที่แพลตฟอร์มระบุไว้
VpnService.Builder ของ Android เปิดเผยรายการแอปที่อนุญาตและรายการแอปที่ห้ามเป็นสองรูปแบบแยกกัน และกฎรายแอปเลือกตามแพ็กเกจไม่ใช่ตามปลายทาง เบราว์เซอร์ที่อยู่ในรายการเช่นนั้นจะพาปลายทางทุกแห่งที่เปิดติดตัวไปด้วย ซึ่งเป็นความละเอียดที่ต่างจากตารางเส้นทาง และไม่สามารถแก้ไซต์ที่พังเพียงแห่งเดียวภายในแอปที่ทำงานอยู่ได้
ไคลเอนต์เดสก์ท็อปมักผสมทั้งสองแบบไว้ในอินเทอร์เฟซเดียว ดังนั้นควรตรวจสอบว่าแถวที่คุณกำลังเพิ่มเป็นแพ็กเกจ ชื่อโฮสต์ หรือพรีฟิกซ์ทั้งสองแบบล้มเหลวต่างกันและแก้ไขคนละที่ แถวที่เป็นชื่อโฮสต์มักกลายเป็นเส้นทางบวกชื่อ ส่วนแถวที่เป็นแพ็กเกจกลายเป็นการตัดสินใจเชิงนโยบายภายในไคลเอนต์ จดไว้ว่าคุณเพิ่มแบบไหน เพราะคนที่แก้ไขในภายหลังจะถือว่าอีกแบบหนึ่ง
ทดสอบสถานะล้มเหลว ไม่ใช่แค่เส้นทางที่ราบรื่น
แอปที่ถูกยกเว้นจากอุโมงค์ไม่ได้เข้าถึงโดยตรงอย่างสะอาดโดยอัตโนมัติ ถ้าไคลเอนต์บังคับใช้กฎบล็อกเมื่อไม่มี VPN ด้วย ทราฟฟิกที่ถูกยกเว้นอาจถูกทิ้งทั้งหมด ซึ่งดูเหมือนแอปพังมากกว่าการตัดสินใจเรื่องเส้นทาง ทดสอบกรณีนั้นโดยเจตนาแทนที่จะไปรู้จากรายงานของผู้ใช้
จากนั้นตรวจสอบ DNS และ IPv6 เป็นรายการแยกกัน อุโมงค์ที่บรรจุเฉพาะ IPv4 เปิดทางอ้อมให้แอปที่รองรับ v6 และ split DNS ตัดสินว่าชื่อภายในจะถูกแปลงสำหรับทราฟฟิกที่ไม่ได้ผ่านอุโมงค์เลยหรือไม่ ลองรันแอปที่อยู่ในรายการ แอปที่ไม่อยู่ในรายการ การค้นหาชื่อหนึ่งครั้ง และการเชื่อมต่อใหม่หนึ่งครั้ง แล้วเก็บผลลัพธ์ไว้กับการกำหนดค่า
เขียนค่าเริ่มต้นไว้ในที่ที่คนถัดไปจะหาเจอ
บันทึกค่าเริ่มต้นที่เลือก ข้อยกเว้น และเจ้าของข้อยกเว้นไว้ในที่เดียวกับโปรไฟล์ไคลเอนต์ เพราะผู้ดูแลคนถัดไปจะเพิ่มรายการโดยไม่อ่านเหตุผลนี้ ระบุวันที่และเหตุผลของแต่ละข้อยกเว้น เพื่อให้การยกเว้นที่ล้าสมัยสำหรับไซต์ที่ได้รับการแก้ไขแล้วถูกลบออกได้อย่างมั่นใจ รายการที่ไม่มีเหตุผลจะเติบโตไม่มีที่สิ้นสุด
เมื่อมีคนรายงานว่าปลายทางหนึ่งเสีย ให้เปลี่ยนข้อยกเว้นไม่ใช่พื้นฐาน การพลิกค่าเริ่มต้นเพื่อแก้ไซต์เดียวจะย้ายแอปทุกตัวที่ไม่อยู่ในรายการไปอีกฟากของอุโมงค์อย่างเงียบ ๆ