L2TP, GRE หรือ IPsec: ชั้นไหนควรแบกเซสชัน?
L2TP แบกเซสชัน PPP, GRE แบกแพ็กเก็ตที่จัดเส้นทาง, IPsec ป้องกันทราฟฟิกที่เลือกไว้ มอบงานหนึ่งอย่างให้แต่ละชั้น แล้วตรวจสอบทีละชั้น
คำถามสองข้อพันกันทุกครั้งที่ L2TP, GRE และ IPsec อยู่ในบันทึกการออกแบบเดียวกัน: ฉันกำลังแบกเซสชันไหน และชั้นไหนป้องกันมัน? ถ้าตอบข้อแรกผิด ทุกอย่างปลายน้ำยังคงสอดคล้องกันภายในขณะที่แก้ปัญหาผิด — สร้างโอเวอร์เลย์ที่จัดเส้นทางในที่ที่ผู้ใช้ต้องหมุนโมเด็ม หรือใช้คอนเซนเทรเตอร์ Dial-in แทนเกตเวย์ระหว่างไซต์ เวิร์กชีตด้านล่างบังคับให้แยกความต่างนี้ก่อนที่ใครจะล็อกอินเข้าเครื่อง กรอกตามลำดับ แล้วแต่ละบรรทัดจะกลายเป็นสิ่งที่ทดสอบได้ด้วยตัวเอง
เริ่มจากเซสชัน ไม่ใช่จากรายการโปรโตคอล
ผู้ใช้ระยะไกลที่มีเซสชัน PPP กับโอเวอร์เลย์ที่จัดเส้นทางระหว่างเกตเวย์สองตัวเป็นความสัมพันธ์เครือข่ายคนละแบบ แม้ทั้งคู่จะถูกห่อด้วย IPsec ในที่สุด แบบแรกสิ้นสุดลิงก์ต่อผู้ใช้และต้องการการกำหนดแอดเดรส การพิสูจน์ตัวตนของบุคคลหรืออุปกรณ์ และนโยบายที่ระบุว่าเครือข่ายภายในใดที่ผู้ใช้รายนั้นเข้าถึงได้ แบบหลังส่งต่อแพ็กเก็ตระหว่างไซต์ที่ไม่มีใครหมุนโมเด็มเข้าไป
เขียนประโยคเดียวที่ระบุว่าคุณกำลังสร้างแบบไหนในสองแบบนี้ แล้วอ่านกลับราวกับว่าคุณคือคนที่ต้องดูแลมัน ถ้าประโยคนั้นต้องใช้คำว่า 'และ' คุณกำลังสร้างทั้งสองแบบ และเวิร์กชีตต้องมีสองคอลัมน์แทนคอลัมน์ประนีประนอมเดียวที่รับใช้แต่ละฝ่ายได้ครึ่งเดียว ถ้ามันระบุผู้ใช้แต่ไม่มีพูลแอดเดรส หรือระบุพรีฟิกซ์แต่ไม่มีนโยบายส่งต่อ ประโยคนั้นยังไม่สมบูรณ์ ถ้อยคำฟังดูเป็นราชการ แต่นั่นคือที่ที่ถูกที่สุดในการจับการออกแบบที่มิฉะนั้นจะถูกค้นพบโดยตั๋วช่วยเหลือ
ให้แต่ละชั้นมีงานเดียวเท่านั้น
L2TPv2 แบกเซสชัน PPP ระหว่างปลายทั้งสอง PPP ทำการเจรจาลิงก์ และเมื่อมีการเจรจา จะทำการพิสูจน์ตัวตนผู้ใช้; L2TP ไม่เพิ่มการเข้ารหัสใด ๆ ดังนั้นเดมอน L2TP เปล่า ๆ จึงไม่นำส่วนใดของความสัมพันธ์ความปลอดภัย IPsec ไปใช้ และอยู่ได้เฉพาะภายในลิงก์ที่คุณไว้วางใจอยู่แล้ว
GRE คือการห่อหุ้มระหว่างสองแอดเดรส มันแบกแพ็กเก็ตชั้นเครือข่ายข้ามโอเวอร์เลย์เชิงตรรกะ และโดยตัวมันเองไม่ได้ให้ทั้งความลับหรือตัวตนเพียร์ที่ผ่านการพิสูจน์ นั่นไม่ใช่ข้อบกพร่อง: ส่วนหัวถูกออกแบบให้เรียบง่ายเพื่อให้ประมวลผลบนฮาร์ดแวร์ส่งต่อได้ถูก ผลลัพธ์คือ GRE ตอบคำถาม 'จะย้ายแพ็กเก็ตนี้ระหว่างสองแอดเดรสได้อย่างไร' และไม่ตอบอย่างอื่น ซึ่งเป็นคำถามที่คุณควรถามมันพอดี
เหลือ IPsec เป็นชั้นที่เลือกทราฟฟิก พิสูจน์ตัวตนเพียร์ และเข้ารหัสสิ่งที่ได้รับคำสั่งให้ป้องกัน ทราฟฟิกใดที่มันป้องกันเป็นการตัดสินใจตั้งค่าที่ต้องตรงกับการห่อหุ้มที่ปลายทั้งสองสร้างจริง เพราะนโยบายที่เขียนสำหรับแอดเดรสภายนอกของ GRE ทำงานต่างจากที่เขียนสำหรับพรีฟิกซ์ภายใน ข้อกำหนด GRE แยกเพย์โหลด ส่วนหัว GRE และโปรโตคอลส่งมอบภายนอกออกจากกันอย่างชัดเจน และนโยบายของคุณก็ต้องการการแยกแบบเดียวกัน
| Layer | Its one job | What it never does |
|---|---|---|
| PPP | Link negotiation, optional user authentication, address assignment | Protect traffic between gateways |
| L2TPv2 | Carry the PPP session between two endpoints | Encrypt or authenticate peers |
| GRE | Encapsulate network-layer packets between two addresses | Hide or authenticate the payload |
| IPsec | Authenticate peers and encrypt selected traffic | Carry a dial-in user session by itself |
เขียนเส้นทางแพ็กเก็ตก่อนคอนฟิก
หยิบแพ็กเก็ตหนึ่งลูกแล้วไล่ส่วนหัวทุกอันที่ถูกเพิ่มตามลำดับที่เพิ่ม พร้อมระบุอุปกรณ์ที่เพิ่มมัน สำหรับผู้ใช้ Dial-in มักเป็น PPP ใน L2TP ใน IPsec; สำหรับโอเวอร์เลย์ไซต์ เป็นแพ็กเก็ต IP ภายในใน GRE ใน IPsec ถ้าสองอุปกรณ์เพิ่มส่วนหัวเดียวกัน คุณมีลูปหรืออุโมงค์ซ้ำ และการแก้ไขนโยบายไม่ว่าอย่างไรก็แก้ไม่ได้
รายการเดียวกันตัดสิน MTU เพราะขนาดภายในที่ใช้ได้คือ MTU เส้นทางที่วัดได้ลบส่วนหัวที่คุณเพิ่งไล่ไว้ และไม่มีอะไรอื่น อย่าคัดลอกตัวเลขจากโพสต์ฟอรัม: บวกโอเวอร์เฮดของ IP ภายนอก UDP และ ESP เข้าด้วยกัน จากนั้น GRE หรือ L2TP จากนั้น PPP ในที่ที่ใช้ แล้วลบออกจาก MTU เส้นทางที่คุณวัดจริง อาการที่ปรากฏเฉพาะการถ่ายโอนขนาดใหญ่ หรือเซสชันที่สร้างแล้วตายตอนตอบกลับใหญ่ครั้งแรก มักย้อนกลับไปที่การบวกนี้ทำด้วยการเดา
ตรวจแต่ละชั้นแยกกัน จากนอกเข้าใน
รันการตรวจตามลำดับและหยุดที่รายการแรกที่ล้มเหลว แต่ละบรรทัดตอบคำถามต่างกัน ดังนั้นความล้มเหลวชี้ไปที่คอลัมน์หนึ่งของเวิร์กชีต แทนที่จะบอกว่าอุโมงค์เสีย
ip xfrm state # is the IPsec SA up?
ip -s link show gre1 # does the overlay interface carry packets?
ip route get 10.20.0.5 # does the inner prefix route where you think?
ss -lun | grep -E "1701|4500" # are the L2TP and NAT-T listeners bound?บนกล่อง Cisco สิ่งที่เทียบเท่าขึ้นกับบทบาท และไวยากรณ์ที่แน่นอนขึ้นกับแพลตฟอร์มและรีลีส: show crypto session สำหรับเพียร์ IPsec ตัวนับอินเทอร์เฟซสำหรับอินเทอร์เฟซ GRE หรืออุโมงค์ และการตรวจสอบ VPDN หรือ PPP สำหรับบทบาท Dial-in ชุดคำสั่งที่สิ้นสุด PPP ไม่พิสูจน์อะไรเกี่ยวกับการรองรับ GRE และอินเทอร์เฟซ GRE ที่ทำงานได้ก็ไม่พิสูจน์อะไรเกี่ยวกับบริการ PPP ดังนั้นตรวจสอบบทบาทที่คุณตั้งค่าจริง ไม่ใช่บทบาทในแผนภาพ
บันทึกทุกเอาต์พุตไว้ข้างบรรทัดเวิร์กชีตที่มันเป็นของ บันทึกที่จดขณะความขัดข้องยังเกิดอยู่มีค่ามากกว่าทอโปโลยีที่วาดใหม่ภายหลังจากความจำ
จัดลำดับการถอดประกอบ แล้วตรวจสอบอีกครั้ง
การถอดประกอบทำย้อนลำดับด้วยเหตุผล: เอาทราฟฟิกที่ป้องกันออกจากนโยบาย IPsec ก่อนถอดการห่อหุ้มที่นโยบายนั้นเขียนขึ้นมา มิฉะนั้นนโยบายจะชี้ไปยังอินเทอร์เฟซที่ไม่มีอยู่แล้ว และการโหลดคอนฟิกครั้งถัดไปจะล้มเหลวในที่ที่ดูไม่เกี่ยวข้อง บน Linux นั่นหมายถึงลบรายการ state และ policy ก่อนอินเทอร์เฟซอุโมงค์; บนเราเตอร์ ให้ลบรายการ crypto map หรือ profile ก่อนอุโมงค์
หลังสร้างใหม่ ให้ทำการสังเกตการยอมรับทั้งสี่ซ้ำทีละข้อ: การเข้าถึงภายนอก ความเชื่อมโยง IPsec ที่สร้างแล้ว เซสชัน PPP ที่สร้างแล้วในที่ที่การออกแบบมี และการส่งต่อภายในไปยังแอดเดรสปลายทางจริง ไฟเขียวหนึ่งดวงไม่ใช่หลักฐานของอีกสามข้อ และช่องว่างนั้นคือความล้มเหลวที่อยู่รอดนานที่สุดในการผลิต — อุโมงค์ที่ขึ้นแล้ว เข้ารหัสแล้ว และไม่ส่งต่ออะไรเลยเพราะไม่เคยเพิ่มเส้นทางภายใน
เก็บเวิร์กชีตที่กรอกแล้วไว้ข้างคอนฟิกของอุปกรณ์ คอลัมน์ใดที่คุณกรอกไม่ได้คือชั้นที่ไม่มีงานได้รับมอบหมาย และชั้นที่ไม่มีงานมักเป็นชั้นที่ไม่ควรอยู่ในสแตก