สามการตัดสินใจเรื่องที่อยู่ก่อนวางเซ็นเซอร์ IoT ไว้หลัง VPN
ที่อยู่สามอย่างทำหน้าที่สามอย่าง คือฮับสาธารณะ เพียร์ของไซต์ที่ผ่านการรับรอง และที่อยู่ส่วนตัวของเซ็นเซอร์ วางแผนแต่ละอย่างก่อนจัดสรรสิ่งใดที่เป็นสาธารณะ
ที่อยู่สามอย่างพันกันอยู่ในทุกแผน IoT ผ่าน VPN และไม่ใช่การตัดสินใจแบบเดียวกัน อย่างแรกคือวิธีที่ผู้ปฏิบัติงานระยะไกลค้นหาปลายทางของอุโมงค์ อย่างที่สองคือวิธีที่ไซต์พิสูจน์ว่าตนคือไซต์นั้น และอย่างที่สามคือตำแหน่งที่บริการของเซ็นเซอร์รับฟังจริง ๆ ตอบคำถามเหล่านี้ตามลำดับนั้น แล้วการออกแบบก็มักจะออกมาเอง ตอบเป็นคำถามเดียวแล้วคุณจะลงเอยด้วย การกำหนดที่อยู่สาธารณะให้อุปกรณ์ที่ไม่เคยต้องการมันเลย เซ็นเซอร์ที่อยู่หลังอุโมงค์ขาออกของไซต์นั้นเข้าถึงได้โดยผู้ปฏิบัติงานที่ได้รับอนุญาตโดยไม่มีกฎขาเข้าใด ๆ ชี้ไปที่เซ็นเซอร์เลย
เริ่มจากใครเป็นผู้เริ่ม
ใครเป็นผู้เรียกเป็นตัวกำหนดเกือบทุกอย่างที่ตามมา เมื่อไซต์เรียกไปยังฮับ ไซต์ไม่ต้องการการเข้าถึงขาเข้า และฮับต้องการชื่อหรือที่อยู่ที่ไซต์แก้ได้ การเลือกเพียงครั้งเดียวนั้นขจัดข้อโต้แย้งเรื่องที่อยู่สาธารณะแบบคงที่ส่วนใหญ่ก่อนที่มันจะเริ่ม
จากนั้นบทบาททั้งสามก็แยกจากกันอย่างชัดเจน และตารางด้านล่างคือรูปแบบที่สั้นที่สุดของการตัดสินใจ
| Decision | What you are actually choosing | Usual default |
|---|---|---|
| Hub endpoint | How the tunnel service is published | A DNS name, no inbound rule toward the site |
| Site peer | How the site proves its identity and which prefixes it carries | One key pair or certificate per site, prefix in the tunnel config |
| Sensor service | How the application is addressed inside the site | A stable private address from the site plan |
แต่ละแถวมีเจ้าของต่างกัน และนั่นคือประเด็นจริง ฮับเป็นของใครก็ตามที่ดูแลบริการ VPN เพียร์ของไซต์เป็นของทีมเครือข่าย และที่อยู่ของเซ็นเซอร์เป็นของใครก็ตามที่ถือครองอุปกรณ์
ที่อยู่ของฮับคือการเริ่มต้น ไม่ใช่ปลายทาง
ชื่อที่แก้เป็นที่อยู่สาธารณะที่มีการดูแลก็เพียงพอสำหรับฮับ บันทึก DNS ติดตามปลายทางได้เมื่อมันย้าย โดยไม่ต้องแก้ไขการกำหนดค่าของแต่ละไซต์ด้วยมือ สิ่งที่ DNS ไม่ได้ทำคือสร้างการเข้าถึงหรือรีเฟรชไคลเอนต์ที่แคชคำตอบเก่าไว้ และนั่นเป็นปัญหาคนละเรื่องกับวิธีแก้คนละแบบ
หากคุณเดินอุโมงค์แบบไซต์ถึงไซต์โดยไม่มีฮับ ตรรกะเดียวกันก็ยังใช้ในอีกรูปแบบหนึ่ง ฝั่งหนึ่งต้องการปลายทางที่เข้าถึงได้ หรือทั้งสองฝั่งเรียกไปยังบุคคลที่สาม มีคนที่ยังต้องถือครองที่อยู่และต่ออายุมันอยู่ดี
เพียร์ของไซต์คือตัวตนที่มีคำนำหน้าติดอยู่
เพียร์คือตัวตนก่อนและเป็นคำนำหน้าทีหลัง ในแง่ของ WireGuard เพียร์ถือคู่กุญแจ และรายการ AllowedIPs ของฮับผูกกุญแจนั้นเข้ากับคำนำหน้าของไซต์ ในแง่ของ IKEv2 ใบรับรองหรือกุญแจที่แบ่งปันล่วงหน้าจะระบุไซต์ และตัวเลือกทราฟฟิกของไซต์บอกว่ามันขนส่งอะไรได้ การเปลี่ยนเพียงครึ่งเดียวทำให้การจัดวางเสีย และนั่นคือเหตุผลว่าทำไมการเปลี่ยนที่อยู่จึงต้องไม่ถูกถือเป็นการเปลี่ยนตัวตนเลย
เก็บความเป็นเจ้าของกุญแจหรือใบรับรองไว้ที่ไซต์ไม่ใช่ที่ผู้ปฏิบัติงานของฮับ เพื่อการเปลี่ยนผู้ให้บริการจะไม่กลายเป็นการเปลี่ยนตัวตน
คำนำหน้าคือส่วนที่คนมักลืมวางแผน ฮับต้องเชื่อมซับเน็ตของเซ็นเซอร์เข้ากับเพียร์ที่ถูกต้อง และไคลเอนต์ของผู้ปฏิบัติงานต้องการเส้นทางไปยังมัน เส้นทางที่มีอยู่เฉพาะบนไคลเอนต์จะส่งทราฟฟิกเข้าไปในอุโมงค์ที่ทิ้งมันอย่างเงียบ ๆ เขียนคำนำหน้าไว้ในบันทึกของไซต์ข้างลายนิ้วมือของกุญแจ เพื่อให้เกตเวย์ที่เข้าแทนไม่สามารถเกิดขึ้นพร้อมขอบเขตที่ต่างออกไปโดยไม่มีใครสังเกต
ที่อยู่ของเซ็นเซอร์เป็นของแอปพลิเคชัน
ที่อยู่ส่วนตัวจากแผนของไซต์ก็เพียงพอ และสิ่งที่มันต้องการคือความเสถียรไม่ใช่การเข้าถึงจากสาธารณะ การจอง DHCP การกำหนดแบบคงที่ หรือชื่อในโซนของไซต์เอง หากอุปกรณ์ไม่สามารถกำหนดหมายเลขใหม่ได้ การแปลที่เกตเวย์ของไซต์ก็เป็นคำตอบที่ชอบด้วยเหตุผล ตราบใดที่การแปลนั้นถูกบันทึกไว้และทราฟฟิกขากลับทำตาม
อีกนิสัยหนึ่งที่ควรเก็บไว้ คืออย่าวางที่อยู่สาธารณะของฮับลงในช่องฮอปถัดไปบนโฮสต์ของเซ็นเซอร์ VPN ติดตั้งเส้นทางของตัวเอง และความใกล้เคียงแบบอีเทอร์เน็ตธรรมดากับปลายทางสาธารณะเป็นเรื่องสมมติที่สร้างการกำหนดค่าที่ดูน่าเชื่อ
คำตอบคือครึ่งหนึ่งที่มักถูกข้าม อุปกรณ์ต้องส่งคำตอบกลับไปยังอุโมงค์ ไม่ว่าจะผ่านเส้นทางไปยังไคลเอนต์ของผู้ปฏิบัติงานหรือผ่านเกตเวย์เดียวกันที่แปลคำขอ เซ็นเซอร์ที่มีเกตเวย์เริ่มต้นผิดจะรับคำขอและตอบไปในความว่างเปล่า และ บันทึกเรื่องการส่งต่อ อธิบายว่าทำไมการมาถึงและการกำหนดเส้นทางของคำตอบจึงเป็นสองข้อกำหนดไม่ใช่ข้อเดียว
ตัดสินใจ แล้วเขียนขอบเขต
เขียนขอบเขตการเข้าถึงไว้ก่อนที่ใครจะเชื่อมต่อ จำกัดเกตเวย์ไว้ที่ส่วน IoT และบริการเฉพาะที่ผู้ปฏิบัติงานต้องการ เพราะเส้นทางที่ใช้งานได้มักกลายเป็นการเข้าถึงทั่วไปโดยอุบัติเหตุ รักษาการเฝ้าดูแบบอ่านอย่างเดียวและอำนาจในการกำหนดค่าให้เป็นบทบาทแยกกันพร้อมตัวตนแยกกัน และระบุชื่อผู้ถอนการเข้าถึงเมื่อสัญญาสิ้นสุด
การอนุมัติเป็นของผู้เป็นเจ้าของเครือข่าย และการอยู่ใน DMZ ไม่ใช่นโยบายการเข้าถึง
การทดสอบหลังการติดตั้งน่าเบื่อและชี้ขาด คำขอหนึ่งรายการภายในคำนำหน้าที่อนุญาตที่สำเร็จ ตัวนับที่เพิ่มขึ้นบนเกตเวย์ และความพยายามโดยเจตนาหนึ่งครั้งนอกคำนำหน้าที่ล้มเหลว