แล็ปท็อป VPN ต้องเปิด IP forwarding เพื่อให้เร็วขึ้นหรือไม่?
การส่งต่อแพ็กเก็ตข้ามอินเทอร์เฟซไม่ทำให้เบราว์เซอร์ในเครื่องเร็วขึ้น แยกบทบาทไคลเอนต์ออกจากบทบาทเกตเวย์ก่อนขยายกฎ
การเปลี่ยนแล็ปท็อปให้เป็นเราเตอร์เป็นวิธียอดนิยมในการแก้ปัญหาที่ผิด การส่งต่อมีไว้เพื่อให้เครื่องส่งแพ็กเก็ตที่ปลายทางไม่ใช่ตัวเองได้ และไม่มีความเห็นว่าเบราว์เซอร์บนเครื่องเดียวกันโหลดหน้าได้เร็วแค่ไหน เส้นทางทั้งสองดูเหมือนกันเพียงเพราะทั้งคู่ส่งทราฟฟิกผ่านอุโมงค์เดียว แยกทั้งสองออกจากกันสักครั้ง แล้วคำแนะนำเรื่องการเปิดใช้การส่งต่อหรือเปิดไฟร์วอลล์จำนวนมากจะกลายเป็นการอธิบายโครงสร้างที่คุณไม่มี
สองเส้นทางแพ็กเก็ตที่ดูเหมือนกันจากโต๊ะทำงาน
เบราว์เซอร์บนแล็ปท็อปสร้างคำขอของตัวเอง โฮสต์เลือกเส้นทางอุโมงค์ กระบวนการไคลเอนต์ห่อแพ็กเก็ตและส่งไปยังคู่ของมัน และคำตอบกลับมาที่แอปพลิเคชัน ไม่มีสิ่งใดในลำดับนั้นข้ามการตัดสินใจเรื่องการส่งต่อ เพราะเครื่องนี้เป็นทั้งต้นทางและปลายทางของการสนทนา
ตอนนี้วางอุปกรณ์อีกเครื่องบนเซกเมนต์อีเทอร์เน็ตที่กำหนดค่าไว้โดยเจตนา และทำให้แล็ปท็อปเป็นเกตเวย์เริ่มต้นของอุปกรณ์นั้น อุปกรณ์นั้นเริ่มคำขอ แล็ปท็อปได้รับแพ็กเก็ตที่ส่งไปที่อื่น และเคอร์เนลต้องตัดสินใจว่าจะส่งต่อหรือไม่ นั่นคือบทบาทการส่งต่อ และมันมาพร้อมเงื่อนไขที่บทบาทไคลเอนต์ไม่เคยต้องการ: เส้นทางทรานซิตที่ได้รับอนุญาต เส้นทางทั้งสองด้าน และเส้นทางขากลับที่ยังทำงานหากการแปลเป็นส่วนหนึ่งของการออกแบบ
| Role | Who originates the traffic | What has to be true |
|---|---|---|
| Client only | The laptop itself | Tunnel route, working resolver, supported profile |
| Gateway | Another device | Forwarding enabled, permitted transit, routes both ways, return-path decision |
ip_forward เปลี่ยนอะไรจริง ๆ
เอกสาร IPv4 sysctl ของเคอร์เนลอธิบาย ip_forward ว่าเป็นสวิตช์ที่ให้โฮสต์ส่งต่อแพ็กเก็ตระหว่างอินเทอร์เฟซ ไม่ใช่ทางลัดสำหรับทราฟฟิกที่โฮสต์สร้างเอง และการอ่านพารามิเตอร์นั้นไม่ทำให้เบราว์เซอร์ในเครื่องเร็วขึ้น หากมีอะไร การส่งต่อกลับเพิ่มสถานะและนโยบายให้กับเครื่องที่ก่อนหน้านี้ทำงานน้อยกว่า
เอกสารเดียวกันเตือนว่าการเปลี่ยนค่าจะรีเซ็ตพารามิเตอร์ IPv4 อื่นกลับเป็นค่าเริ่มต้นของโฮสต์หรือเราเตอร์ นั่นทำให้สวิตช์เป็นการเปลี่ยนแปลงการกำหนดค่ามากกว่าการทดสอบ: การตั้งค่าที่ปรับไว้แล้วอาจย้อนกลับได้ใต้เท้าของคุณ และการเปลี่ยนแปลงอาจเป็นสาเหตุของการถดถอยที่ไม่มีใครคิดจะโยงถึงมัน การสลับระหว่างการสอบสวนความช้าคือกรณีเดียวที่ผลข้างเคียงจะถูกสับสนกับอาการอย่างแน่นอน
สามคำถามของไฟร์วอลล์ที่ไม่ใช่คำถามเดียวกัน
การอนุญาตให้ตัวรับฟัง VPN การอนุญาตบริการที่แล็ปท็อปเรียกใช้ และการอนุญาตให้ทราฟฟิกผ่านแล็ปท็อปเป็นสามสิทธิ์แยกกัน อย่างแรกให้คู่ของมันเข้าถึงแดมอน อย่างที่สองเปิดเผยบางอย่างในเครื่อง และอย่างที่สามเปลี่ยนเครื่องให้เป็นทางผ่านของคนอื่น แต่ละอย่างมีขอบเขตต่างกัน และอย่างสุดท้ายกว้างกว่าคำตอบที่แอปพลิเคชันขาออกทั่วไปต้องการมาก
เมื่อโฟลว์หนึ่งถูกบล็อก ให้ระบุต้นทาง ปลายทาง ทิศทาง และเจ้าของนโยบายก่อนแก้ไขกฎ กฎแคบสำหรับโฟลว์นั้นคือการแก้ไข การยอมรับทุกอย่างบนอินเทอร์เฟซอุโมงค์คือการเปลี่ยนนโยบายที่บังเอิญรวมการแก้ไขไว้ด้วย เบราว์เซอร์ที่ทำงานได้หลังจากนั้นพิสูจน์ว่าโฟลว์ทำงาน ไม่ได้พิสูจน์ว่ากฎกว้างจำเป็น
วัดเมื่อเส้นทางถูกต้องแล้วเท่านั้น
วัดด้วยปลายทางเดิม ภาระงานเดิม และเงื่อนไขที่เทียบกันได้ และเปลี่ยนตัวแปรทีละตัว การทดสอบที่รวมการเปลี่ยนการส่งต่อ การขยายไฟร์วอลล์ และการตั้งไซเฟอร์ที่คัดลอกมาไว้ด้วยกันให้ตัวเลขและไม่มีคำอธิบาย เพราะไม่มีอะไรในนั้นบอกว่าสิ่งใดในสามอย่างขยับผลลัพธ์
แยกความล้มเหลวของเส้นทางและตัวแก้ชื่อออกจากบทสนทนาเรื่องประสิทธิภาพโดยสิ้นเชิง ชื่อที่แก้ได้ช้าไม่ใช่ปัญหาแบนด์วิดท์ และการถ่ายโอนที่หยุดที่ขนาดคงที่หนึ่งมักเป็นคำถามเรื่อง MTU ไม่ใช่ขีดจำกัดความเร็ว บันทึกว่าคุณสังเกตเห็นสิ่งใดในสามอย่างนี้จริง ๆ ก่อนเปรียบเทียบตัวเลขใด ๆ มิฉะนั้นผู้อ่านคนถัดไปจะได้มรดกเป็นการวัดที่วัดผิดสิ่งและการเปลี่ยนแปลงที่ไม่มีใครให้เหตุผลได้
อธิบายโครงสร้างที่คุณมี ไม่ใช่ป้ายบนไคลเอนต์
แล็ปท็อปที่แชร์การเชื่อมต่อ โฮสต์เครือข่ายคอนเทนเนอร์ที่มีเส้นทาง หรือแบกทราฟฟิกให้เครื่องเสมือน คือเกตเวย์ ไม่ว่าซอฟต์แวร์จะเรียกตัวเองว่าอะไร คำว่าไคลเอนต์อธิบายว่าอุโมงค์ถูกกำหนดค่าอย่างไร ไม่ใช่ว่าแพ็กเก็ตถูกส่งต่อให้คนอื่นหรือไม่
ทำให้บทบาทชัดเจนในคู่มือปฏิบัติการ: อะไรสร้างทราฟฟิก อะไรต้องผ่านเครื่อง และงานปัจจุบันเกี่ยวกับสิ่งใดในสองอย่างนี้ เปิดบทบาทเกตเวย์เมื่อมันเป็นส่วนหนึ่งของแผนที่รองรับ ไม่ใช่ในฐานะการปรับความเร็วที่อธิบายไม่ได้ซึ่งใช้กับโครงสร้างที่ไม่เคยต้องการมัน