NAT แบบสมมาตรกับ VPN: วัดการแมป ไม่ใช่วัดป้ายชื่อ
การแมปที่ขึ้นกับปลายทางมีผลต่อการค้นหาคู่-peer ไม่ใช่ต่ออุโมงค์ไคลเอนต์-เซิร์ฟเวอร์ทั่วไป วัดพอร์ตก่อน แล้วจึงใช้รีเลย์หากเส้นทางตรงล้มเหลว
กระทู้ช่วยเหลือจบลงด้วยคำตัดสินว่า “NAT แบบสมมาตร VPN จะใช้ไม่ได้ที่นี่” แล้วไคลเอนต์ก็ถูกติดตั้งใหม่สามครั้งโดยไม่มีเหตุผล ป้ายชื่อสร้างความเสียหายเพราะมันตอบคำถามที่ไม่มีใครถาม ไคลเอนต์ที่เชื่อมต่อออกไปยังเซิร์ฟเวอร์คงที่จะสร้างการแมปทันทีที่ส่งแพ็กเก็ตแรก และคำตอบได้รับอนุญาตให้กลับมาตามกฎที่เกือบทุกเครือข่ายใช้งาน สิ่งที่การแมปที่ขึ้นกับปลายทางทำให้ซับซ้อนจริง ๆ คือการที่สองคู่พยายามเข้าหากันในเวลาเดียวกัน และนั่นคือการทดสอบอีกแบบหนึ่ง
มีสองคำถามซ่อนอยู่หลังป้ายชื่อเดียว
คำถามแรกคือโฮสต์ที่อยู่หลังเครือข่ายนี้จะเปิดเซสชันไปยังที่อยู่สาธารณะและพอร์ตที่รู้จักได้หรือไม่ สำหรับไคลเอนต์อุโมงค์นั่นคือกรณีปกติ และคำตอบคือใช่เกือบทุกครั้ง เราเตอร์บันทึกต้นทางภายใน จัดสรรพอร์ตภายนอก และปล่อยคำตอบผ่านเพราะมันเป็นของเซสชันที่เริ่มจากข้างใน
คำถามที่สองคือโฮสต์สองตัวที่อยู่หลังเครือข่ายต่างกันจะหาเส้นทางร่วมและส่งถึงกันได้หรือไม่โดยไม่มีเซิร์ฟเวอร์อยู่ตรงกลาง นั่นขึ้นอยู่กับว่าแต่ละเครือข่ายจัดสรรพอร์ตภายนอกเหล่านั้นอย่างไร และเป็นที่เดียวที่พฤติกรรมการแมปมีความสำคัญ
การสับสนสองเรื่องนี้ทำให้เกิดการวินิจฉัยผิดแบบคลาสสิก คือฟีเจอร์ระหว่างคู่ล้มเหลว มีคนรันการทดสอบประเภท NAT เห็นหมวดหมู่ที่แย่ที่สุด แล้วสรุปว่าอุโมงค์ธรรมดาก็ใช้ไม่ได้เช่นกัน อุโมงค์ไม่เคยเป็นสิ่งที่ล้มเหลว
การแมปและการกรองเป็นสองคุณสมบัติที่แยกจากกัน
คำศัพท์ของ RFC แม่นยำกว่าชื่อที่ผู้ขายใช้ และคุ้มค่าที่จะนำไปใส่ในตั๋วเพราะมันยุติข้อโต้แย้ง การแมปคือวิธีจัดสรรพอร์ตภายนอก การกรองคือแพ็กเก็ตขาเข้าชนิดใดที่ได้รับอนุญาตให้ผ่าน เครือข่ายหนึ่งอาจเข้มงวดในด้านหนึ่งและผ่อนปรนในอีกด้าน และการผสมผสานนั้นคือสิ่งที่โปรโตคอลระหว่างคู่ต้องอดทน
| Behaviour | What it means | Effect on a direct peer path |
|---|---|---|
| Endpoint-independent mapping | One external port for every destination | Discovery works if the port is advertised |
| Address-dependent mapping | New port per remote address | Works only if both sides probe the same pair |
| Address-and-port-dependent | New port per remote address and port | Usually needs a relay |
แถวที่สามคือสิ่งที่เราเตอร์สำหรับผู้บริโภคและผู้ให้บริการมือถือส่วนใหญ่หมายถึงคำว่าสมมาตร สังเกตว่าป้ายชื่ออธิบายเฉพาะการจัดสรร เครือข่ายที่มีการแมปนั้นและการกรองแบบผ่อนปรนยังคงรับแพ็กเก็ตขาเข้าที่พอร์ตที่เพิ่งจัดสรรได้ ซึ่งเป็นเหตุผลว่าทำไมการเจาะรูจึงสำเร็จในบางเครือข่ายและล้มเหลวในบางเครือข่าย
การกรองมีสามกรณีของตัวเองและมีชื่อของตัวเองสำหรับแต่ละกรณี การเขียนว่า “NAT แบบสมมาตร” ในตั๋วทั้งที่หมายถึง “การกรองที่ขึ้นกับที่อยู่และพอร์ต” จะส่งคนถัดไปไปยังบทที่ผิดของคู่มือ ทั้งสองทำงานต่างกันในการทดสอบ ดังนั้นข้อผิดพลาดนี้ไม่ใช่แค่เชิงวิชาการ
วัดการแมปแทนการตั้งชื่อให้มัน
คุณสามารถสังเกตพอร์ตที่จัดสรรได้โดยตรงจากฝั่งเซิร์ฟเวอร์ของบริการ UDP ใดก็ได้ที่คุณควบคุม เริ่มดักจับบนโฮสต์สาธารณะ ส่งจากไคลเอนต์ แล้วอ่านพอร์ตต้นทางที่แพ็กเก็ตมาถึง:
sudo tcpdump -ni eth0 -c 10 'udp port 51820'
sudo wg show wg0 endpoints
sudo conntrack -L -p udp --dport 51820บรรทัดปลายทางมีประโยชน์ที่สุดในสามอย่าง เพราะ WireGuard บันทึกที่อยู่และพอร์ตล่าสุดที่ได้รับจากแต่ละคู่ เปรียบเทียบพอร์ตนั้นกับพอร์ตที่ไคลเอนต์คิดว่ากำลังใช้ ทั้งสองจะต่างกันทุกครั้งที่มีการแปลที่อยู่ และ คำถามสำคัญคือค่าดังกล่าวคงที่หรือไม่
ทำการสังเกตซ้ำกับพอร์ตปลายทางที่สองหรือเซิร์ฟเวอร์ที่สองแล้วเปรียบเทียบอีกครั้ง หากพอร์ตภายนอกเปลี่ยนตามปลายทาง การแมปก็ขึ้นกับที่อยู่และพอร์ต หากยังคงเดิม เครือข่ายให้การแมปเดียวและโอกาสในการค้นหามีอยู่
เครื่องมือที่ใช้ STUN รายงานการจำแนกประเภทเดียวกันในขั้นตอนเดียว และใช้ได้เมื่อเครือข่ายอนุญาต UDP ขาออกไปยังเซิร์ฟเวอร์ STUN สาธารณะ เมื่อไม่อนุญาต วิธีการดักจับข้างต้นยังใช้ได้และไม่ต้องใช้อะไรนอกจากโฮสต์ที่คุณควบคุมอยู่แล้ว
เลือกวิธีแก้ที่ตรงกับความล้มเหลว
หากฟีเจอร์ที่ล้มเหลวคือระหว่างคู่ คำตอบที่รองรับคือรีเลย์ บริการนัดพบที่ทั้งสองคู่เข้าถึงได้ หรือโทโพโลยีแบบอื่น TURN มีอยู่เพื่อสิ่งนี้โดยเฉพาะ และผลิตภัณฑ์ที่มีรีเลย์ของตัวเองกำลังบอกคุณว่าคาดว่าบางเครือข่ายจะเป็นศัตรู
หากฟีเจอร์ที่ล้มเหลวคืออุโมงค์ธรรมดา พฤติกรรมการแมปไม่ใช่ปัญหาของคุณและไม่มีข้อใดข้างต้นใช้บังคับ ตรวจสอบว่าไคลเอนต์ส่งจริง เซิร์ฟเวอร์เห็นแพ็กเก็ต และคำตอบกลับมา ลำดับนั้นคือการสังเกตสามอย่าง และไม่ต้องรู้สิ่งใดเกี่ยวกับหมวดหมู่ NAT ของเราเตอร์
สิ่งที่ไม่ทำงานคือการกระจายการเปลี่ยนพอร์ตภายในจนกว่าจะมีบางอย่างเชื่อมต่อได้ การเปลี่ยนพอร์ตต้นทางของไคลเอนต์ไม่เปลี่ยนวิธีที่เครือข่ายจัดสรรการแมป ความสำเร็จโดยบังเอิญในการลองครั้งที่ห้าเป็นผลบวกลวง และจะถูกอ้างอิงเป็นวิธีแก้เป็นเวลาหลายเดือน
บันทึกสถาปัตยกรรม ไม่ใช่คำตัดสิน
บันทึกที่มีประโยชน์บอกว่าโปรโตคอลใด เซสชันเริ่มไปในทิศทางใด มีรีเลย์อยู่ในเส้นทางหรือไม่ และสังเกตเห็นอะไรบนสาย “NAT แบบสมมาตร ใช้ไม่ได้” นั้นใช้ประโยชน์ไม่ได้ เพราะผิดเกี่ยวกับอุโมงค์และไม่ให้ข้อมูลเกี่ยวกับเส้นทางของคู่ในเวลาเดียวกัน
รวมความเสถียรของพอร์ตที่วัดได้และพฤติกรรมการกรองหากคุณได้ทดสอบ ข้อเท็จจริงสองข้อนี้ทำให้คนอื่นคาดการณ์ได้ว่าฟีเจอร์ใหม่จะทำงานบนเครือข่ายนั้นหรือไม่โดยไม่ต้องทำการสอบสวนซ้ำทั้งหมด มันยังเสื่อมสภาพช้ากว่าหมวดหมู่ของผู้ขายซึ่งหมายถึงสิ่งที่ต่างกันเล็กน้อยในแต่ละหน้าช่วยเหลือ
สุดท้าย เก็บ คำศัพท์ของ RFC 4787 ไว้ให้พร้อมเมื่อคุณเขียนสิ่งนี้ การใช้คำศัพท์ที่แม่นยำมีต้นทุนเพียงหนึ่งประโยคและป้องกันไม่ให้ผู้อ่านคนถัดไปทำการวินิจฉัยผิดซ้ำ และนั่นคือจุดประสงค์ทั้งหมดของการเขียนบันทึก