ปัญหาการเชื่อมต่อบางอย่างไม่ได้เกิดจากแอปที่คุณใช้ มาจากเส้นทางเครือข่ายระหว่างอุปกรณ์
คุณอาจสังเกตเห็นสิ่งนี้เมื่อมีสายเชื่อมต่อทันทีที่บ้าน Wi-Fi แต่ประสบปัญหาในโรงแรม Wi-Fi เมื่อล็อบบี้เกมใช้งานได้สำหรับผู้เล่นคนหนึ่งแต่ล้มเหลวสำหรับอีกคนหนึ่ง หรือเมื่อเครื่องมือความเป็นส่วนตัวทำงานแตกต่างออกไปหลังจากที่คุณเปลี่ยนจากข้อมูลมือถือเป็นเครือข่ายสำนักงาน สาเหตุทั่วไปประการหนึ่งคือ NAT: เลเยอร์การแปลที่อยู่เครือข่ายที่ช่วยให้อุปกรณ์จำนวนมากแบ่งปันที่อยู่อินเทอร์เน็ตสาธารณะที่อยู่เดียว
บทความนี้จะอธิบายว่า NAT traversal คืออะไร เหตุใดจึงมีการเจาะรู UDP เมื่อรีเลย์ทางเลือกมีประโยชน์ และเหตุใดผู้อ่าน VPN Satelites จึงควรถือว่าแนวคิดเหล่านี้เป็นบริบทการเชื่อมต่อมากกว่าการรับประกันเวทมนตร์
NAT ทำอะไรในเครือข่ายทุกวัน
คนส่วนใหญ่ใช้เครือข่ายส่วนตัวโดยไม่ได้คำนึงถึงพวกเขา แล็ปท็อป โทรศัพท์ แท็บเล็ต และทีวีของคุณอาจอยู่หลังเราเตอร์ตัวเดียว ภายในบ้าน อุปกรณ์แต่ละชิ้นจะมีที่อยู่ส่วนตัวของตัวเอง สำหรับอินเทอร์เน็ตในวงกว้าง พวกเขามักจะแบ่งปันที่อยู่สาธารณะหนึ่งรายการ
การแปลนั้นมีประโยชน์ ช่วยให้เครือข่ายรักษาที่อยู่สาธารณะ IPv4 และช่วยให้การจัดการเส้นทางบ้านตามปกติได้ แต่ยังสร้างปัญหาในทางปฏิบัติด้วย กล่าวคือ อุปกรณ์ที่อยู่นอกเครือข่ายของคุณมักจะไม่สามารถเปิดการเชื่อมต่อโดยตรงกับอุปกรณ์ภายในเครือข่ายของคุณได้ เว้นแต่เราเตอร์จะรู้ว่าการรับส่งข้อมูลขาเข้านั้นควรไปที่ใด
สำหรับการท่องเว็บแบบธรรมดาก็เป็นเรื่องปกติ อุปกรณ์ของคุณเริ่มการเชื่อมต่อออกไปด้านนอก เราเตอร์จะจดจำการแมป และการตอบกลับกลับมาผ่านเส้นทางชั่วคราวนั้น สำหรับแอปที่ต้องการปลายทางสองจุดเพื่อสื่อสารโดยตรงมากขึ้น โดยเฉพาะบน UDP สถานการณ์อาจคาดเดาได้น้อยลง
นั่นคือการตั้งค่าพื้นฐานสำหรับการเคลื่อนที่ของ NAT
การเดินทางข้ามผ่าน NAT คืออะไร?
การแวะผ่าน NAT เป็นชื่อทั่วไปสำหรับเทคนิคที่ช่วยให้แอปพลิเคชันสื่อสารข้ามเครือข่ายโดยที่จุดปลายหนึ่งหรือทั้งสองจุดอยู่หลัง NAT
ในภาษาอังกฤษธรรมดา แอปนี้พยายามตอบคำถามเชิงปฏิบัติ: “อุปกรณ์ทั้งสองนี้สามารถค้นหาเส้นทางการทำงานระหว่างกันได้ แม้ว่าเราเตอร์จะแปลที่อยู่และกรองการรับส่งข้อมูลที่เข้ามาหรือไม่”
ไม่มีคำตอบที่เป็นสากลเพียงคำตอบเดียวเนื่องจากพฤติกรรมของ NAT แตกต่างกันไป มาตรฐาน เช่น IETF RFC 4787 อธิบายพฤติกรรมของ NAT สำหรับ UDP และอธิบายว่าทำไมความสอดคล้องจึงมีความสำคัญสำหรับแอปแบบเรียลไทม์ เช่น การสื่อสารมัลติมีเดียและเกมออนไลน์ ปัญหากว้างๆ เดียวกันนี้ปรากฏในแอปสมัยใหม่หลายประเภท เช่น การโทร เครื่องมือการทำงานร่วมกัน เกม เครื่องมือการเข้าถึงระยะไกล ระบบแบบเพียร์ทูเพียร์ และแอปที่มีลักษณะคล้าย VPN ล้วนได้รับผลกระทบจากวิธีที่เครือข่ายจัดการการรับส่งข้อมูล
สำหรับเครื่องอ่าน VPN Satelites ประโยชน์ที่เป็นประโยชน์นั้นง่ายมาก: หากการเชื่อมต่อมีพฤติกรรมแตกต่างกันในเครือข่าย ซึ่งสามารถสะท้อนถึงพฤติกรรมของเราเตอร์, NAT ระดับผู้ให้บริการ, นโยบายไฟร์วอลล์, การกรองแพ็กเก็ต, ความแออัด หรือเงื่อนไขเส้นทางอื่น ๆ ไม่ควรอ่านโดยอัตโนมัติเพื่อเป็นข้อพิสูจน์ว่าการตั้งค่าแอปหนึ่งเสียหาย
การเจาะรู UDP คืออะไร?
UDP มักใช้โดยแอปพลิเคชันแบบเรียลไทม์ เนื่องจากสามารถหลีกเลี่ยงความล่าช้าและค่าใช้จ่ายที่เกี่ยวข้องกับการรับส่งข้อมูลที่เน้นการเชื่อมต่อได้ แต่ UDP ไม่ได้สร้างเซสชันที่มีอายุการใช้งานยาวนานในลักษณะเดียวกับที่หลายๆ คนจินตนาการถึงการเชื่อมต่อแบบเดิมๆ
การเจาะรู UDP เป็นเทคนิคการเคลื่อนที่ของ NAT โดยที่จุดปลายสองจุดแต่ละจุดส่งแพ็กเก็ต UDP ขาออก ดังนั้นอุปกรณ์ NAT จะสร้างการแมปชั่วคราว หากจังหวะเวลาและพฤติกรรมของ NAT ตรงกัน การรับส่งข้อมูลจากอีกด้านหนึ่งสามารถกลับมาผ่านการแมปเหล่านั้นได้
วลีนี้ฟังดูก้าวร้าว แต่แนวคิดนั้นดูธรรมดามากกว่าชื่อที่แนะนำ เป็นเรื่องเกี่ยวกับการทำงานกับกฎที่มีอยู่ของเราเตอร์สำหรับการรับส่งข้อมูลขาออกและขากลับ การวิจัยพื้นฐานจาก Bryan Ford, Pyda Srisuresh และ Dan Kegel อธิบายว่าการเจาะรูเป็นแนวทางปฏิบัติที่ใช้โดยแอปพลิเคชันที่ใช้ UDP ในขณะเดียวกันก็เน้นย้ำถึงข้อจำกัดที่สำคัญ: ไม่มีเทคนิคการเคลื่อนที่ผ่านในทุกการตั้งค่า NAT
ข้อจำกัดนั้นสำคัญ บางเครือข่ายนำการแมปมาใช้ซ้ำในลักษณะที่เป็นประโยชน์ คนอื่นๆ สร้างการแมปที่เชื่อมโยงกับจุดหมายปลายทางเฉพาะเจาะจงมากขึ้น บางเครือข่ายเพิ่มพฤติกรรมไฟร์วอลล์ไว้ด้านบนของ NAT เครือข่ายมือถือและ ISP บางแห่งวางผู้ใช้ไว้หลัง NAT ระดับผู้ให้บริการ โดยที่ผู้ใช้ไม่สามารถควบคุมเลเยอร์การแปลอัปสตรีมได้เลย
ดังนั้นเมื่อมีคนถามว่าการเจาะรู UDP คืออะไร คำตอบสั้นๆ ก็คือ: มันเป็นวิธีสำหรับแอปพลิเคชันในการลองใช้เส้นทาง UDP โดยตรงผ่านการแมปที่สร้างโดย NAT คำตอบอย่างระมัดระวังคือ: สามารถทำงานได้ดีในหลายสภาพแวดล้อม แต่ก็ไม่รับประกัน
เหตุใดบางครั้งการเชื่อมต่อโดยตรงจึงล้มเหลว
การเชื่อมต่อโดยตรงอาจล้มเหลวได้จากสาเหตุทั่วไปหลายประการ:
- เราเตอร์ไม่อาจใช้การแมปพอร์ตภายนอกเดียวกันซ้ำได้เมื่อแอปติดต่อกับปลายทางที่แตกต่างกัน
- เครือข่ายอาจกรองแพ็กเก็ต UDP ขาเข้าที่เข้มงวดกว่าเครือข่ายอื่น
- เลเยอร์ NAT ระดับผู้ให้บริการอาจอยู่ระหว่างผู้ใช้กับอินเทอร์เน็ตสาธารณะ
- เครือข่ายสถานที่ทำงาน โรงเรียน โรงแรม หรือสถานที่จัดงานอาจจำกัดการจราจรตามนโยบายของตนเอง
- เครือข่ายมือถืออาจเปลี่ยนเส้นทางตามคุณภาพสัญญาณหรือการเปลี่ยนแปลงสิ่งที่แนบมากับเครือข่าย
- ผลิตภัณฑ์รักษาความปลอดภัยหรือไฟร์วอลล์ในเครื่องอาจบล็อกการรับส่งข้อมูลก่อนที่จะเข้าถึงแอป
กรณีเหล่านี้ไม่ได้หมายความว่าผู้ใช้ควรพยายามเลี่ยงกฎที่ตนไม่ได้ควบคุม ประเด็นในทางปฏิบัติคือการทำความเข้าใจว่าพฤติกรรมการเชื่อมต่อขึ้นอยู่กับการตั้งค่าแอปมากกว่าหนึ่งรายการ หากเครือข่ายจงใจบล็อกหรือจำกัดการรับส่งข้อมูลประเภทหนึ่ง ขั้นตอนถัดไปที่ถูกต้องคือการใช้เครือข่ายที่ได้รับอนุญาต ตรวจสอบข้อกำหนดการบริการ หรือพูดคุยกับผู้ดูแลระบบเครือข่าย
ตำแหน่งที่ Relay Fallbacks พอดี
เมื่อการเชื่อมต่อโดยตรงไม่น่าเชื่อถือ บางระบบจะใช้รีเลย์: อุปกรณ์ปลายทางทั้งสองเชื่อมต่อภายนอกกับเซิร์ฟเวอร์ตัวกลาง และเซิร์ฟเวอร์ส่งการรับส่งข้อมูลระหว่างกัน IETF RFC 5766 อธิบาย TURN ย่อมาจาก traversal โดยใช้รีเลย์รอบๆ NAT เป็นโปรโตคอลสำหรับการสื่อสารแบบใช้รีเลย์ช่วย เมื่อไม่สามารถสื่อสารแบบเพียร์โดยตรงได้ในบางสถานการณ์ของ NAT
รีเลย์แก้ปัญหาที่แตกต่างจากการเคลื่อนที่ของ NAT โดยตรง รีเลย์สามารถปรับปรุงการเข้าถึงได้เนื่องจากอุปกรณ์ทั้งสองจำเป็นต้องเข้าถึงบริการรีเลย์เท่านั้น ข้อดีข้อเสียก็คือการรับส่งข้อมูลต้องใช้เส้นทางพิเศษ ซึ่งอาจเพิ่มเวลาแฝง ต้นทุนแบนด์วิธ และความซับซ้อนในการดำเนินงาน
นี่คือเหตุผลว่าทำไมการออกแบบการเชื่อมต่อจำนวนมากจึงนิยมลองใช้เส้นทางตรงก่อน แล้วจึงถอยกลับเมื่อจำเป็น IETF RFC 8445 อธิบาย ICE ว่าเป็นแนวทางมาตรฐานสำหรับการสำรวจ NAT สำหรับการสื่อสารบน UDP ที่ใช้แนวคิด STUN และ TURN เพื่อค้นหาและทดสอบเส้นทางที่เป็นไปได้ นั่นไม่ได้หมายความว่าเครื่องมือที่เกี่ยวข้องกับ VPN ทุกตัวจะใช้ ICE, STUN หรือ TURN เพียงแสดงรูปแบบทางวิศวกรรมทั่วไป: ทดสอบว่าเส้นทางใดใช้ได้ผล จากนั้นใช้ทางเลือกสำรองหากไม่มีการเชื่อมต่อโดยตรง
สำหรับผู้อ่าน บทเรียนสำคัญคือการตั้งความคาดหวังที่สมจริง การสำรองรีเลย์อาจทำให้การเชื่อมต่อเป็นไปได้ในสถานการณ์ที่เส้นทางตรงล้มเหลว แต่ก็ไม่เหมือนกับการทำให้ทุกสภาพเครือข่ายหายไป
สิ่งนี้หมายความว่าสำหรับผู้อ่าน VPN Satelites
เนื้อหา VPN Satelites มักจะอยู่ใกล้กับหัวข้อต่างๆ เช่น ความเป็นส่วนตัว การเชื่อมต่อ การกำหนดเส้นทางอินเทอร์เน็ต และความคาดหวังของผู้ใช้ การแวะผ่าน NAT อยู่ในละแวกสถานศึกษาเดียวกันนั้น เพราะมันอธิบายว่าทำไมเครือข่ายรอบแอปจึงมีความสำคัญพอๆ กับตัวแอปเอง
สำหรับหัวข้อนี้ สิ่งสำคัญคือต้องรักษาการเชื่อมต่อผลิตภัณฑ์ให้พอประมาณ บทความนี้ไม่ได้อ้างว่า VPN Satelites ใช้วิธีการแวะผ่าน NAT สถาปัตยกรรมการถ่ายทอด การตั้งค่าการส่งต่อพอร์ต ตัวเลือก IP แบบคงที่ หรือสแต็กโปรโตคอล คุณค่าที่นี่คือความรู้เชิงปฏิบัติ: การทำความเข้าใจข้อกำหนดจะช่วยให้คุณอ่านคำแนะนำในการแก้ไขปัญหาได้ละเอียดยิ่งขึ้น และประเมินปัญหาการเชื่อมต่อโดยไม่ต้องคาดหวังว่าแอปที่เกี่ยวข้องกับ VPN จะแทนที่กฎเครือข่ายทั้งหมด
หากการเชื่อมต่อไม่เสถียร การตรวจสอบที่มีความเสี่ยงต่ำบางอย่างสามารถช่วยคุณแยกพฤติกรรมของแอพออกจากพฤติกรรมของเครือข่ายได้:
- ลองใช้เครือข่ายอื่นที่ได้รับอนุญาต เช่น Wi-Fi ที่บ้านเทียบกับข้อมูลมือถือ และสังเกตว่าปัญหาเกิดขึ้นที่แอปหรือเครือข่าย
- รีสตาร์ทเราเตอร์ท้องถิ่นหากคุณควบคุมและการเชื่อมต่อปกติดูลดระดับลง
- ตรวจสอบว่าเครือข่ายได้รับการจัดการโดยที่ทำงาน โรงเรียน โรงแรม สถานที่ หรือ ISP โดยมีข้อจำกัดด้านการจราจรหรือไม่
- อัปเดตแอปและระบบปฏิบัติการอยู่เสมอ เนื่องจากการจัดการการเชื่อมต่อสามารถเปลี่ยนแปลงได้ในเวอร์ชันต่างๆ
- หลีกเลี่ยงการเปลี่ยนแปลงการตั้งค่าเราเตอร์หรือไฟร์วอลล์ขั้นสูง เว้นแต่คุณจะเข้าใจถึงผลกระทบหรือได้รับการอนุมัติจากผู้ดูแลระบบ
ขั้นตอนเหล่านี้ไม่ข้ามข้อจำกัด ช่วยระบุว่าปัญหาการเชื่อมต่ออาจมาจากที่ใด
วิธีอ่านการเรียกร้องการเดินทางข้าม NAT อย่างระมัดระวัง
เมื่อคุณเห็นผลิตภัณฑ์ โปรโตคอล หรือแอปพูดคุยเกี่ยวกับการแวะผ่าน NAT โปรดอ่านคำกล่าวอ้างอย่างแม่นยำ
คำถามที่เป็นประโยชน์ได้แก่:
- การกล่าวอ้างเกี่ยวกับเทคนิคเครือข่ายทั่วไปหรือคุณลักษณะของผลิตภัณฑ์ที่ได้รับการยืนยันหรือไม่
- มันอธิบายว่าเงื่อนไขเครือข่ายใดบ้างที่รองรับ และเงื่อนไขใดที่ไม่รองรับ?
- มีการกล่าวถึงพฤติกรรมทางเลือกโดยไม่สัญญาว่าจะเข้าถึงได้อย่างสมบูรณ์แบบหรือไม่
- เป็นการหลีกเลี่ยงการแนะนำว่าผู้ใช้สามารถเพิกเฉยต่อสถานที่ทำงาน โรงเรียน ISP แพลตฟอร์ม หรือข้อจำกัดทางกฎหมายได้หรือไม่
- แยกการเรียกร้องความเป็นส่วนตัวจากการเรียกร้องการเชื่อมต่อหรือไม่
จุดสุดท้ายนั้นพลาดได้ง่าย คุณลักษณะที่ช่วยให้สองปลายทางเชื่อมต่อไม่ได้รับประกันความเป็นส่วนตัวโดยอัตโนมัติ คุณลักษณะความเป็นส่วนตัวไม่ใช่การรับประกันการเชื่อมต่อโดยอัตโนมัติ เอกสารที่ดีควรแยกแนวคิดเหล่านั้นออกจากกัน
คำถามที่พบบ่อย
การข้ามผ่าน NAT เหมือนกับ VPN หรือไม่?
ไม่ NAT traversal คือชุดของเทคนิคเครือข่ายสำหรับจัดการกับการแปลที่อยู่และการกรองระหว่างจุดปลาย VPN เป็นเทคโนโลยีประเภทที่กว้างขึ้นสำหรับการสร้างอุโมงค์เครือข่ายที่ได้รับการป้องกัน แอปที่คล้ายกับ VPN บางแอปอาจต้องคำนึงถึงพฤติกรรมของ NAT ด้วย แต่แนวคิดไม่เหมือนกัน
การเจาะรู UDP ได้ผลเสมอหรือไม่?
ไม่ การเจาะรู UDP ขึ้นอยู่กับพฤติกรรมของ NAT กฎการกรอง เวลา และโทโพโลยีเครือข่าย การอภิปรายด้านการวิจัยและมาตรฐานต่างชี้ไปที่ความเป็นจริงในทางปฏิบัติที่เหมือนกัน: พฤติกรรมของ NAT นั้นแตกต่างกัน ดังนั้นจึงอาจจำเป็นต้องมีเส้นทางสำรอง
รีเลย์สำรองดีกว่าการเชื่อมต่อโดยตรงหรือไม่
พวกเขาแตกต่างกัน รีเลย์สามารถช่วยได้เมื่อไม่สามารถสื่อสารโดยตรงได้ แต่อาจเพิ่มเวลาแฝง การใช้แบนด์วิธ และต้นทุนการดำเนินงาน เส้นทางตรงอาจมีประสิทธิภาพมากกว่าเมื่อใช้งานได้ แต่อาจล้มเหลวบนเครือข่ายที่เข้มงวดกว่า
บทความนี้บอกว่า VPN Satelites ใช้ STUN, TURN, ICE, รีเลย์ หรือการส่งต่อพอร์ตหรือไม่?
ไม่ ข้อกำหนดเหล่านี้ถูกกล่าวถึงในฐานะแนวคิดทั่วไปของเครือข่ายและพื้นฐานมาตรฐาน บทความนี้ไม่ได้อ้างสิทธิ์การใช้งานเฉพาะผลิตภัณฑ์ใดๆ เกี่ยวกับ VPN Satelites
NAT traversal bypass กฎเครือข่ายได้หรือไม่
บทความนี้ไม่ได้ให้คำแนะนำในการบายพาส การข้ามผ่าน NAT สามารถช่วยอธิบายลักษณะการเชื่อมต่อได้ แต่ผู้ใช้ควรปฏิบัติตามกฎหมาย เงื่อนไขการบริการ และนโยบายเครือข่ายที่บังคับใช้
บรรทัดล่าง
การแวะผ่าน NAT มีความสำคัญเนื่องจากเส้นทางอินเทอร์เน็ตระหว่างอุปกรณ์สองเครื่องนั้นไม่ได้ตรงหรือคาดเดาได้เสมอไป UDP hole punching can help some applications establish direct communication across NAT, while relay fallbacks can help when direct paths fail. แนวคิดทั้งสองมีประโยชน์ แต่ก็ไม่ใช่การแก้ไขที่เป็นสากลเช่นกัน
สำหรับผู้อ่าน VPN Satelites บทเรียนที่เป็นประโยชน์มากที่สุดคือการกำหนดความคาดหวังที่สมจริง ความน่าเชื่อถือในการเชื่อมต่อขึ้นอยู่กับแอป อุปกรณ์ เครือข่ายท้องถิ่น นโยบายเครือข่ายอัปสตรีม และเส้นทางที่กว้างขึ้นระหว่างอุปกรณ์ปลายทาง การทำความเข้าใจเลเยอร์เหล่านั้นทำให้การแก้ไขปัญหาสงบลงและการกล่าวอ้างผลิตภัณฑ์อ่านเชิงวิพากษ์ได้ง่ายขึ้น