VPN กับ leased line? แปลความต้องการก่อน

ข้อเสนอระบุ leased line เฉพาะสำหรับ VPN ของสำนักงาน และตัวเลขก็มาพร้อมคำอธิบายเป็นศูนย์ ก่อนเซ็น ให้แยกประโยคออกเป็นสี่ข้อกำหนดที่มันซ่อนไว้จริง ๆ: การส่งมอบทางกายภาพ วิธีการส่งมอบ IP ความจุทั้งสองทิศทาง และพันธะการสนับสนุนที่อยู่เบื้องหลังวงจร ตรวจสอบสิ่งเหล่านี้ตามลำดับนั้นในฐานะประตู เพราะวงจรที่ล้มเหลวในการส่งมอบไม่อาจกู้ได้ด้วยตัวเลขแบนด์วิดท์ที่ใหญ่กว่า จากนั้นตรวจสอบสิ่งที่ส่งมอบจริงกับสิ่งที่คุณจดไว้

แปลความต้องการ ไม่ใช่ชื่อผลิตภัณฑ์

IPsec ปกป้องทราฟฟิกที่ชั้น IP และปล่อยการรับส่งให้กับวงจรที่คุณซื้อ สถาปัตยกรรม IPsec อธิบายว่าทราฟฟิกได้รับการปกป้องระหว่างคู่ปลายทางอย่างไร ไม่ได้กล่าวถึงประเภทการส่งมอบ อัตราที่รับประกัน หรือกรอบเวลาการซ่อมแซม สิ่งเหล่านั้นเป็นคุณสมบัติของสัญญาบริการ

ความแตกต่างนี้คือเหตุผลทั้งหมดที่ข้อกำหนดของวงจรอาจชอบด้วยกฎหมายและยังไม่เป็นข้อกำหนดของ VPN เกตเวย์ที่มีเพียงอินเทอร์เฟซแบบอนุกรมจำเป็นต้องมีการส่งมอบแบบอนุกรมจริง ๆ และนั่นเป็นข้อจำกัดของฮาร์ดแวร์ ไม่ใช่ของโปรโตคอล เปลี่ยนอุปกรณ์แล้วข้อจำกัดก็หายไป เขียนแต่ละข้อกำหนดในรูปแบบ «เกตเวย์ต้องการ X เพราะ Y» และปฏิเสธบรรทัดใดก็ตามที่เติมให้สมบูรณ์ไม่ได้

ตั้งชื่อการส่งมอบก่อนตั้งชื่อความเร็ว

การส่งมอบคือการเชื่อมต่อทางกายภาพและชั้นลิงก์ ณ จุดแบ่งเขต: Ethernet ทองแดง ไฟเบอร์พร้อมทรานซีฟเวอร์เฉพาะ อินเทอร์เฟซแบบอนุกรม หรือสิ่งที่เก่ากว่าซึ่งมีอยู่เพียงเพราะอุปกรณ์ปัจจุบันมีมัน การผิดพลาดตรงนี้มีราคาแพงในแบบที่แบนด์วิดท์ไม่เคยเป็น เพราะโดยปกติหมายถึงฮาร์ดแวร์ใหม่ที่ปลายทั้งสองข้าง ออปติกที่หายไปไม่ใช่ปัญหาความจุ และไม่มีการอัปเกรดใดแก้ไขได้

ยืนยันตัวเชื่อม การเจรจาความเร็ว และใครเป็นผู้จัดหาตัวแปลงสื่อหรือเราเตอร์ จากนั้นยืนยันว่าความรับผิดชอบของคุณสิ้นสุดที่ใด เพราะจุดแบ่งเขตเป็นตัวกำหนดว่าใครได้รับอนุญาตให้แตะอะไรเมื่อลิงก์ล่มเมื่อเวลา 03:00 เขียนขอบเขตนั้นลงในบันทึกข้างตัวระบุวงจร มันเป็นบรรทัดเดียวที่เปลี่ยนสายสนับสนุนให้เป็นการสนทนาห้านาทีแทนการโอนย้ายหนึ่งชั่วโมง

ip -br link show
ethtool eth0 | head -20
sudo lshw -class network -short

ยืนยันการส่งมอบ IP ไม่ใช่แค่ที่อยู่

ถามว่าบริการส่งมอบที่อยู่หรือคำนำหน้าใดจริง ๆ และเป็นแบบคงที่หรือไม่ วงจรที่แจกที่อยู่แบบไดนามิกไม่เหมาะกับเกตเวย์ระหว่างไซต์ เพราะการกำหนดค่าของคู่ต้องอยู่รอดจากการเปลี่ยนแปลงที่คุณไม่ได้วางแผนไว้ ยืนยันความยาวคำนำหน้าด้วย เพราะที่อยู่เดียวกับ /29 ที่กำหนดเส้นทางเป็นผลิตภัณฑ์ที่แตกต่างกัน

จากนั้นถามว่ามีอะไรแปลที่อยู่ก่อนถึงคุณหรือไม่ NAT ฝั่งผู้ให้บริการหรือ NAT ระดับผู้ให้บริการโทรคมนาคมที่อยู่หน้าบริการทำลายเซสชันขาเข้า เกตเวย์ที่คาดว่าจะรับ IPsec จากไซต์ระยะไกลจึงเข้าถึงไม่ได้ ความเร็วชดเชยไม่ได้: ลิงก์เร็วที่อยู่หลังตัวแปลที่คุณไม่ได้ควบคุมก็ยังรับการเชื่อมต่อขาเข้าบนพอร์ตที่ไม่มีใครส่งต่อไม่ได้

บันทึกว่าใครเป็นเจ้าของเราเตอร์และ DNS หากผู้ให้บริการจัดหาเราเตอร์ คุณจะสืบทอดเฟิร์มแวร์ พฤติกรรม NAT และแนวคิดเรื่องเส้นทางเริ่มต้นของมัน และทุกการเปลี่ยนแปลงในภายหลังต้องผ่านตั๋ว ให้คนนอกระบบเครือข่ายของคุณลองเชื่อมต่อขาเข้าที่พอร์ตที่คุณคาดว่าจะเข้าถึงได้ เพราะนั่นคือการทดสอบเดียวที่พิสูจน์เรื่องราวการแปลที่อยู่

ip -br addr
ip route get 198.51.100.10
traceroute -n 198.51.100.10

คำนวณความจุจากภาระงาน ทั้งสองทิศทาง

ความจุต้องอธิบายเป็นงาน ไม่ใช่ตัวเลขต่อผู้ใช้ การเข้าถึงไฟล์จำนวนมาก การดูแลแบบอินเทอร์แอกทีฟ และการสำรองข้อมูลข้ามคืนต่างสร้างรูปแบบทราฟฟิกที่แตกต่างกัน และมีเพียงหนึ่งเดียวที่สนใจอัตราการส่งขึ้นต่อเนื่อง ตัวเลขแบนด์วิดท์ต่อที่นั่งเป็นความสะดวกในการขาย ไม่ใช่แบบจำลอง

ประเมินทั้งสองทิศทาง บวกโอเวอร์เฮดของการห่อหุ้ม และบันทึกว่าทราฟฟิกเป็นแบบระเบิดหรือต่อเนื่อง จากนั้นตรวจสอบอัตราที่รับประกันของสัญญาไม่ใช่อัตราที่โฆษณา เพราะสิทธิ์เบิร์สต์ที่หมดอายุในไม่กี่วินาทีไม่ช่วยการสำรองข้อมูลข้ามคืน นับขีดจำกัดของเกตเวย์เองไว้ในงบเดียวกันด้วย เพราะการประมวลผลการเข้ารหัสและจำนวนเซสชันพร้อมกันอาจเป็นข้อจำกัดก่อนวงจรเสียอีก สายที่เร็วกว่าจะไม่แก้เกตเวย์ที่อิ่มตัว

กำหนดพันธะด้านปฏิบัติการให้ชัด

ความพร้อมใช้งาน การตอบสนองการซ่อมแซม เส้นทางการยกระดับ และการแจ้งเตือนการบำรุงรักษาต้องเป็นลายลักษณ์อักษร โดยระบุวิธีการวัด อัตราอินเทอร์เน็ตที่โฆษณาไม่ได้กำหนดคุณสมบัติเหล่านี้เลย และหน้าเพจการตลาดที่สัญญาความน่าเชื่อถือโดยไม่นิยามเหตุขัดข้องก็เช่นกัน ถามว่านาฬิกาเริ่มเมื่อใด เพราะเวลาตอบสนองที่วัดจากการยืนยันของผู้ให้บริการเองไม่ใช่ตัวเลขเดียวกับที่วัดจากการแจ้งเตือนการตรวจสอบของคุณ คำนิยามสองแบบนั้นต่างกันได้หลายชั่วโมงโดยไม่มีใครโกหก

บันทึกขอบเขตการสนับสนุนด้วย หากความรับผิดชอบของผู้ให้บริการสิ้นสุดที่การส่งมอบที่เราเตอร์ของคุณสิ้นสุด ชั่วโมงแรกของทุกเหตุการณ์จะหมดไปกับการตัดสินว่าใครเป็นเจ้าของความผิด และไม่มีนาฬิกา SLA ใดครอบคลุมสิ่งนั้น

ตรวจสอบวงจรกับข้อกำหนดที่เป็นลายลักษณ์อักษร

เมื่อบริการเปิดใช้งาน ให้วัดคุณสมบัติที่คุณทำสัญญาไว้จริง ไม่ใช่สิ่งที่ผู้ติดตั้งสาธิต ปริมาณงาน ความหน่วง และการสูญหายบนเส้นทางจริงคือหลักฐาน และควรบันทึกไว้ในเวลาและจากสถานที่ที่คุณระบุได้ ทำการวัดซ้ำในชั่วโมงที่มีการใช้งานสูง ไม่ใช่แค่ตอนส่งมอบ การทดสอบรับรองที่ทำเมื่อ 10:00 ในวันที่เงียบสงบบอกคุณได้น้อยมากเกี่ยวกับลิงก์เมื่อ 15:00

iperf3 -c speed.example.net -t 30 -P 4
mtr -n --report -c 50 198.51.100.10
curl -sS -o /dev/null -w '%{time_connect} %{time_starttransfer}\n' https://speed.example.net/

เก็บผลลัพธ์ไว้กับสัญญา เพราะการพูดคุยเรื่องประสิทธิภาพโดยไม่มีเส้นฐานคือการโต้เถียงเรื่องความรู้สึก หากการวัดไม่ถึงพันธะ ให้ยกขึ้นขณะหลักฐานยังใหม่และบริการยังอยู่ในหน้าต่างการรับรองที่สัญญากำหนด โฮสต์ที่ระบุชื่อในคำขอทำให้แฮนด์เชก TLS ยังใช้ได้ด้วย ดังนั้นคำเตือนใบรับรองจะไม่ถูกเข้าใจผิดว่าเป็นวงจรที่ล้มเหลว

สุดท้าย อ่านประตูทั้งสี่เทียบกับสิ่งที่ส่งมอบ การส่งมอบ การส่งมอบ IP ความจุ และข้อกำหนดการสนับสนุนแต่ละอย่างมีบรรทัดในบันทึก และแต่ละบรรทัดมีชื่ออยู่ข้าง ๆ