แบนด์วิดท์ IPsec ต่ำกว่าที่คาด? ตรวจสอบ SA ที่ใช้งานอยู่ก่อน
รายการการแปลงที่ยาวไม่ใช่เซสชันที่ปกป้องการถ่ายโอนของคุณ บันทึก SA ที่เจรจา ขนาดเพย์โหลด และอัตราที่ส่งถึงจริงก่อนจะโทษการเข้ารหัส
การกำหนดค่ามีการแปลงแปดแบบ มีคนอ่านตัวที่แรงที่สุดแล้วเอาตัวเลขแบนด์วิดท์ไปผูกกับมัน อุโมงค์อาจไม่ได้เลือกการแปลงนั้น และไม่ได้รันภาระงานที่ใครจินตนาการไว้ สิ่งที่เจรจาได้คือรายการเดียวจากลิสต์นั้น ด้วยขนาดแพ็กเก็ตเดียว ทิศทางเดียว บนบิลด์เดียว วัดสิ่งนั้นแล้วการโต้เถียงเรื่องอัลกอริทึมมักจบก่อนจะเริ่ม
อาการ: ตัวเลขต่ำกว่าที่การกำหนดค่าสัญญาไว้
รายการการแปลงยาวๆ อธิบายความเป็นไปได้ และแต่ละความเป็นไปได้ถูกให้คะแนนบนกระดาษไม่ใช่บนฮาร์ดแวร์นี้ ผลลัพธ์ที่เจรจาได้คือชุดเดียวที่ทั้งสองฝ่ายยอมรับ และอาจเป็นชุดที่อ่อนที่สุดที่แต่ละฝ่ายยังอนุญาตเพื่อความเข้ากันได้ สิ่งที่ชุดนั้นทำได้ขึ้นอยู่กับสถานะออฟโหลด ขนาดแพ็กเก็ต และพฤติกรรมคิว ดังนั้นอุปกรณ์สองเครื่องที่มีไฟล์นโยบายเหมือนกันอาจลงเอยห่างกันมาก รายการคือนเมนู ส่วนความสัมพันธ์คือออร์เดอร์ที่ส่งกลับมา
การอ่านรายการบอกคุณว่าอะไรอาจถูกเลือก การอ่านความสัมพันธ์บอกคุณว่าอะไรกำลังแบกการถ่ายโอนจริงๆ และตัวเลขแบนด์วิดท์อธิบายเพียงสิ่งนั้น ทุกขั้นตอนการปรับแต่งที่เริ่มจากรายการคือการเดาพร้อมเอกสารเพิ่ม
บันทึกความสัมพันธ์ที่แบกการถ่ายโอนนี้
บน ASA show crypto ipsec sa จะแสดงความสัมพันธ์ที่ใช้งานอยู่พร้อมการแปลงและตัวนับต่อทิศทาง และ เอกสารอ้างอิงคำสั่ง ของ Cisco อธิบายเอาต์พุตนั้น เลือกเพียร์และทิศทางที่สำคัญ และสังเกตว่าการเจรจาคีย์ใหม่จะแทนที่ความสัมพันธ์และรีเซ็ตตัวนับ ซึ่งทำให้เส้นฐานที่คุณยังไว้วางใจอยู่กลายเป็นโมฆะอย่างเงียบๆ เก็บเอาต์พุตไว้ข้างบันทึกการทดสอบเพื่อให้รอบถัดไปมีอะไรเทียบ ตัวระบุความสัมพันธ์ที่เลื่อนไปมาระหว่างรอบทำให้ทุกการเปรียบเทียบหลังจากนั้นไร้ความหมาย
| What to record | Where to read it | What it rules out |
|---|---|---|
| Negotiated transform and SA identifiers | show crypto ipsec sa for that peer and direction | "the configuration picked the wrong algorithm" |
| Offload or accelerator state for that build | platform show commands and interface statistics | "the crypto engine is the ceiling" |
| Payload size and offered rate | the test tool's own settings and summary | "packets per second versus bytes per second" |
| Delivered rate and loss at the receiver | the receiving endpoint, not the sender's counters | "the sender transmitted, so it arrived" |
| Access-link load and drops | underlay interface counters along the path | "the bottleneck lives inside the tunnel" |
ห้าแถวก็พอทำให้การวัดทำซ้ำได้ และแต่ละแถวตัดคำอธิบายเฉพาะออกเมื่อมันหายไป ไม่มีแถวใดเป็นรายการจากลิสต์ข้อเสนอ เพราะลิสต์บอกไม่ได้ว่าอะไรกำลังปกป้องไบต์ของคุณตอนนี้ กรอกตารางหนึ่งครั้ง แล้วเหตุการณ์ถัดไปจะเริ่มจากข้อมูลไม่ใช่จากการโต้เถียงเรื่องอัลกอริทึมครั้งใหม่
แถวของลิงก์เชื่อมต่อคือแถวที่คนข้ามและมันคือแถวที่อธิบายช่องว่างที่ดูเหมือนปัญหาการเข้ารหัสบ่อยที่สุด อันเดอร์เลย์ที่อิ่มตัวหรือโพลิสเซอร์ตามเส้นทางให้รูปร่างอาการแบบเดียวกับเอนจินที่ช้า
วัดทิศทางเดียวด้วยภาระที่ควบคุมได้
รันการทดสอบจากปลาย LAN ที่เป็นตัวแทนแอปพลิเคชัน ไม่ใช่จากเกตเวย์เอง เพราะโพรบที่เกตเวย์สร้างอาจปฏิบัติตามนโยบายภายในที่ต่างออกไป วัดทิศทางเดียวก่อนเพิ่มสตรีมที่สอง และบันทึกทั้งอัตราที่เสนอและสิ่งที่ผู้รับได้รับจริง การรัน UDP แบบจำกัดอัตราแยกภาระที่เสนอออกจากการตอบสนองต่อความแออัดของ TCP ขณะที่ผู้ส่ง UDP แบบไม่จำกัดไม่ใช่การวินิจฉัยที่เป็นกลาง บันทึกความยาวเพย์โหลดด้วย เพราะดาตาแกรมที่ใหญ่ขึ้นเปลี่ยนทั้งอัตราแพ็กเก็ตและค่าใช้จ่ายในการห่อหุ้ม
show crypto ipsec sa peer 203.0.113.9
iperf3 -c 10.20.0.10 -u -b 200M -l 1200 -t 30รันการทดสอบเดิมสองครั้งด้วยความยาวเพย์โหลดและระยะเวลาเดียวกัน เพราะการรันครั้งเดียวแยกเพดานออกจากนาทีที่แย่ไม่ได้ ถ้าผู้รับรายงานแพ็กเก็ตน้อยกว่าที่ผู้ส่งส่งไป การสูญเสียคือสิ่งที่คุณค้นพบ และเอนจินเข้ารหัสเป็นเพียงหนึ่งในผู้ต้องสงสัยหลายราย
อธิบายช่องว่างก่อนจะปรับอะไร
ตรวจสอบนโยบายการส่งต่อ การทิ้งคิว ข้อผิดพลาดของอินเทอร์เฟซ และขีดจำกัดทรัพยากรควบคู่กับเส้นทางการเข้ารหัส เพราะการขาดอัตราเพียงอย่างเดียวไม่เคยชี้ตัว CPU ได้ รักษาชั้นบัญชีให้ชัดเจนด้วย ไบต์ของอุโมงค์ชั้นนอกมีการห่อหุ้มอยู่ และการส่งซ้ำเลื่อนความสัมพันธ์ระหว่างตัวนับชั้นในกับชั้นนอก การเปรียบเทียบตัวนับที่ไม่เกี่ยวข้องกันทีละไบต์สร้างความคลาดเคลื่อนที่ไม่เคยมีอยู่
ขนาดแพ็กเก็ตสมควรได้รับการเปรียบเทียบแบบควบคุมของตัวเอง ไม่ใช่ตัวเลขที่คัดลอกจากตัวอย่างเก่า TCP MSS ปรับ TCP และไม่มีผลกับดาตาแกรม UDP ใดๆ ดังนั้นค่าคงที่ 1350 ที่ยกมาจากเอกสารเก่าไม่ได้วัดอะไรเลย จงเปลี่ยนความยาวเพย์โหลดโดยตั้งใจและดูว่าผู้รับรายงานอะไร
เปลี่ยนตัวแปรเดียวและคงภาระงานไว้
เมื่อเส้นฐานเกิดซ้ำในช่วงแคบ ให้เปลี่ยนตัวแปรที่รองรับหนึ่งตัวแล้วรันงานแอปพลิเคชันเดิมอีกครั้ง ขั้นตอนนั้นคือสิ่งที่เปลี่ยนตัวเลขให้เป็นสาเหตุ และเป็นสิ่งเดียวที่ทำให้การแตะต้องการกำหนดค่ามีเหตุผล ทำซ้ำภาระงานเดิมไม่ใช่ภาระที่สบายกว่า
อย่าถอนข้อเสนอ ลดความแข็งแรงของการพิสูจน์ตัวตน หรือปิดการป้องกันเพื่อทำให้ตัวเลขสังเคราะห์ใหญ่ขึ้น การกระทำเหล่านั้นเปลี่ยนท่าทีด้านความปลอดภัยแล้ววัดผลของการเปลี่ยนแปลงนั้น ไม่ใช่ขีดความสามารถของอุโมงค์