สองไซต์มือถือที่ไม่มีพอร์ตขาเข้า: สร้างฮับที่ใช้งานได้

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

ไม่มีไซต์ใดถูกเรียกเข้าได้ ทั้งสองจึงต้องโทรออก

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

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

คำสั่งสองคำสั่งตอบคำถามเรื่องที่อยู่ของไซต์ที่คุณยืนอยู่ข้างหน้า รันบนเราเตอร์ของไซต์ ไม่ใช่บนแล็ปท็อปที่อยู่ข้างหลัง:

ip -4 addr show scope global
ip -6 addr show scope global

ใครแนะนำเพื่อนร่วมเครือข่าย และใครขนส่งแพ็กเก็ต

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

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

หนึ่งเส้นทางต่อไซต์ เป็นเจ้าของโดยเพื่อนร่วมเครือข่าย

ฮับต้องมีอุโมงค์หนึ่งต่อไซต์ มีคำนำหน้า LAN แยกต่างหากอยู่ข้างหลังแต่ละไซต์ และมีเส้นทางสำหรับแต่ละคำนำหน้าที่ระบุเจ้าของ ในตัวอย่างฮับคือ 10.61.0.1 ไซต์ A คือ 10.61.0.11 ที่มี LAN 10.60.10.0/24 และไซต์ B คือ 10.61.0.12 ที่มี LAN 10.60.20.0/24 เส้นทางแต่ละเส้นด้านล่างชี้ไปที่เพื่อนร่วมเครือข่ายที่เป็นเจ้าของคำนำหน้า ไม่ใช่อินเทอร์เฟซของอุโมงค์:

ip route add 10.60.10.0/24 via 10.61.0.11 dev wg0
ip route add 10.60.20.0/24 via 10.61.0.12 dev wg0
sysctl net.ipv4.ip_forward
ip route get 10.60.20.55 from 10.60.10.77

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

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

รักษาการแมปปิ้งแต่ละรายการให้มีชีวิตผ่านผู้ให้บริการ

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

[Peer]
PublicKey = <hub public key>
Endpoint = 192.0.2.10:51820
AllowedIPs = 10.61.0.1/32, 10.60.20.0/24
PersistentKeepalive = 25

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

พิสูจน์ทั้งสองทิศทาง แล้วพิสูจน์การกู้คืน

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

wg show wg0 latest-handshakes
ping -c 3 10.60.20.55
traceroute -n 10.60.20.55

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