พอร์ต UDP แบบตายตัวข้ามการส่งต่อพอร์ตได้ แต่ไม่ใช่ทุก NAT

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

การเปรียบเทียบที่ไฟร์วอลล์ทำ

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

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

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

การตรึงพอร์ตเดียวที่แต่ละปลาย

พอร์ต UDP ค่าเริ่มต้นของ OpenVPN คือ 1194 และ lport กำหนดพอร์ตต้นทางที่ใช้ส่ง ตรึงคู่ค้าทั้งสอง แล้วทูเพิลขาออกของแต่ละฝ่ายจะชี้ไปยังพอร์ตที่อีกฝ่ายกำลังฟังอยู่:

# peer A
lport 1194
remote 198.51.100.20 1194
# peer B
lport 1194
remote 203.0.113.10 1194

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

จุดที่ทูเพิลหยุดตรงกัน

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

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

การขนส่งแบบสตรีมแย่กว่า แฮนด์เชก TCP ถูกติดตามทีละขั้น ดังนั้น VPN ที่ใช้ TCP จึงเจาะผ่านวิธีนี้ไม่ได้เลยและต้องมีตัวฟังที่ใดที่หนึ่งบนเส้นทาง

โดยปกติฝ่ายหนึ่งจะล้มเหลวก่อน

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

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

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

เมื่อใดควรหยุดลอง

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

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

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