VPN ที่ไม่ได้ใช้งานใช้แบนด์วิดท์หรือไม่ อ่านตัวนับให้ถูกตัว

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

ทำไมอุโมงค์ที่ไม่ได้ใช้งานยังคงเคลื่อนไบต์

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

OpenVPN มีตัวช่วย keepalive ที่ทำงานต่างออกไป มันกำหนดการตรวจสอบแบบ ping เพื่อให้ปลายทั้งสองแยกเซสชันที่ยังมีชีวิตออกจากเซสชันที่ตายแล้ว และไคลเอนต์ที่นำการรับส่งของตัวเองมาด้วยก็มีตัวจับเวลาที่เทียบเท่ากันในชื่ออื่น ไม่มีสิ่งใดปรากฏในหน้าต่างแอปพลิเคชัน หน้าจอว่างจึงไม่บอกอะไรเกี่ยวกับสิ่งที่อยู่บนสาย

แอปพลิเคชันที่ไม่ได้ใช้งานไม่ใช่อุปกรณ์ที่ไม่ได้ใช้งาน

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

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

เลือกตัวนับหนึ่งตัวแล้วบอกว่ามันนับอะไร

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

ip -s link show wg0
ip -s link show eth0

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

ทำการวัดสั้น ๆ แบบมีผู้ดูแล

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

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

อย่าซื้อศูนย์ที่สะอาดกว่าด้วยอุโมงค์ที่แย่กว่า

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

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