เซิร์ฟเวอร์ที่เชื่อมต่อผ่าน VPN ควรใช้ที่อยู่ใดใน DNS?
เซิร์ฟเวอร์ที่โฮสต์ไว้มีสามที่อยู่และใช้แทนกันไม่ได้ เลือกค่าที่แต่ละบริการต้องการ แล้วยืนยันค่าดังกล่าวจากภายนอกเครื่อง
เซิร์ฟเวอร์ที่โฮสต์ไว้ซึ่งติดตั้ง VPN จะมีที่อยู่สามแบบในที่สุด และมีเพียงแบบเดียวเท่านั้นที่เหมาะกับแต่ละตำแหน่งที่คุณกำลังจะกำหนดค่า การคัดลอกตัวเลขจากแดชบอร์ดของผู้ให้บริการไปยัง DNS ไปยังตัวรับฟัง หรือไปยังรายการที่อนุญาต คือเส้นทางที่ทำให้อุโมงค์ที่ทำงานอยู่กลายเป็นบริการที่ไม่มีใครเข้าถึงได้ คู่มือนี้จัดลำดับงานเพื่อให้แต่ละที่อยู่ถูกเลือกตามวัตถุประสงค์ที่ระบุไว้ และยังแสดงรายการคำสั่งที่ยืนยันสิ่งที่คุณเผยแพร่จริง
ทำแผนที่ที่อยู่ทั้งสามก่อนเผยแพร่สิ่งใด
ตั้งชื่อตามหน้าที่ ที่อยู่ underlay คือสิ่งที่เครื่องใช้เพื่อเข้าถึงปลายทางของ VPN ผ่านอินเทอร์เน็ต และมักเป็นที่อยู่ส่วนตัวหลัง NAT ของผู้ให้บริการ ที่อยู่ของอุโมงค์อยู่ภายใน VPN โดยเซิร์ฟเวอร์หรือไคลเอนต์เป็นผู้กำหนดขึ้นอยู่กับผลิตภัณฑ์ ทางออกสาธารณะคือที่อยู่ที่เว็บไซต์ระยะไกลบันทึกไว้หลังการแปลและไม่จำเป็นต้องมีอยู่บนอินเทอร์เฟซใดที่คุณสอบถามได้
แดชบอร์ดที่แสดงที่อยู่สาธารณะเพียงหนึ่งรายการสำหรับเครื่องหนึ่งเครื่องบอกคุณได้น้อยมากเกี่ยวกับอีกสองบทบาท การเข้าถึง underlay เป็นข้อกำหนด ไม่ใช่การซื้อ เครื่องแล็ปท็อปหลังเราเตอร์ในบ้านสามารถเข้าถึงปลายทาง VPN ที่โฮสต์ไว้ได้โดยไม่ต้องมีที่อยู่ IPv4 สาธารณะ สิ่งที่คุณทำไม่ได้คือสร้างเส้นทางขาเข้าขึ้นมาเองด้วยการเขียนชื่อที่แปลงเป็นที่อยู่ซึ่งไม่มีใครส่งต่อ
เลือกที่อยู่ตามบริการ ไม่ใช่ตามป้ายกำกับ
จดไว้ว่าเซิร์ฟเวอร์ต้องทำอะไรก่อนเลือกตัวเลข การเรียก API ขาออกต้องมีทางออกที่มั่นคงเมื่ออีกฝ่ายถือรายการที่อนุญาต การเข้าถึงแบบส่วนตัวต้องมีที่อยู่ของอุโมงค์ที่ไคลเอนต์กำหนดเส้นทางไปได้และตัวรับฟังที่ผูกกับที่อยู่นั้น การโฮสต์สาธารณะต้องมีการแมปขาเข้าที่ผู้ให้บริการเสนอจริง และที่อยู่ขาออกเพียงอย่างเดียวไม่ได้ให้สิ่งนั้น
เครื่องเดียวสามารถให้บริการครบทั้งสามวัตถุประสงค์และยังใช้ที่อยู่ต่างกันสามแบบได้ สิ่งที่พังคือสมมติฐานว่าค่าเดียวครอบคลุมทั้งหมด:
| Requirement | Value that belongs there | What you see when the roles are swapped |
|---|---|---|
| Outbound allowlisting | Public exit | Requests reach the service but are rejected |
| Private client access | Tunnel address | Client connects, nothing answers |
| Inbound web service | Provider mapping | Name resolves, connection times out |
แถวขาเข้าคือแถวที่ผู้คนถกเถียงกัน บันทึกที่ชี้ไปยังที่อยู่ขาออกไม่ได้สร้างตัวรับฟัง ไม่ได้เปิดช่องไฟร์วอลล์ และไม่ได้แมปพอร์ต และการรอไม่ทำให้สิ่งนั้นเปลี่ยนไป เมื่อผู้ให้บริการขายที่อยู่เฉพาะพร้อมกฎขาเข้า ชุดนั้นคือความสามารถที่คุณซื้อไว้ ที่อยู่เพียงอย่างเดียวไม่ใช่สิทธิ์
คำสั่งที่แสดงว่าที่อยู่ใดเป็นที่อยู่ใด
อ่านเครื่อง ไม่ใช่อ่านแดชบอร์ด ชื่ออินเทอร์เฟซต่างกันในแต่ละระบบ ดังนั้นจับคู่ที่อยู่กับอุปกรณ์แทนที่จะเชื่อป้ายกำกับ
บรรทัดแรกระบุที่อยู่ IPv4 ทุกที่อยู่และอุปกรณ์ของที่อยู่นั้น และบรรทัดที่สองถามเคอร์เนลว่าจะใช้อุปกรณ์ใดสำหรับปลายทางภายนอกที่รู้จัก:
ip -brief -4 addr show
ip -4 route get 198.51.100.10
curl -4 -s https://ifconfig.me
ss -lntp | grep -E ':(443|1194)'หากการค้นหาเส้นทางตอบกลับด้วยอุปกรณ์อุโมงค์สำหรับทราฟฟิกสาธารณะ แสดงว่าอุโมงค์แบบเต็มของคุณมีผลอยู่ การตรวจสอบตัวรับฟังสำคัญพอ ๆ กัน เพราะกระบวนการที่ผูกกับ 127.0.0.1 เท่านั้นจะไม่ตอบสนองบนที่อยู่ของอุโมงค์เลย ไม่ว่าคุณจะเผยแพร่ชื่อใด
เผยแพร่แล้วตรวจสอบจากภายนอก
เผยแพร่เฉพาะค่าที่บริการต้องการและไม่มากไปกว่านั้น บันทึก A หรือ AAAA สำหรับการโฮสต์ รายการในรายการที่อนุญาตสำหรับการเรียกขาออก และโปรไฟล์ไคลเอนต์สำหรับการเข้าถึงแบบส่วนตัว จากนั้นทดสอบจากตำแหน่งที่สำคัญ และตำแหน่งนั้นไม่ใช่เครื่องที่คุณเพิ่งแก้ไข
การตรวจสอบสองอย่างครอบคลุมส่วนใหญ่ และทั้งสองถูกพอที่จะเก็บไว้ในสคริปต์:
dig +short vpn.example.net A
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/healthคำตอบ DNS ที่พิสูจน์ว่าบันทึกของคุณมีอยู่ไม่ใช่หลักฐานว่าคำขอมาถึง และคำขอที่สำเร็จหนึ่งครั้งพิสูจน์เพียงว่าเส้นทางหนึ่งทำงานจากเครือข่ายหนึ่งเท่านั้น ทำการตรวจสอบซ้ำจากการเชื่อมต่อมือถือเมื่อมีรายการที่อนุญาตเข้ามาเกี่ยวข้อง เพราะทางออกที่คุณสังเกตเห็นอาจขึ้นอยู่กับตระกูลที่อยู่และเส้นทางที่ใช้ บันทึกว่าคุณยืนยันตระกูลใด เส้นทาง IPv4 ที่ใช้งานได้ไม่บอกอะไรเลยเกี่ยวกับ IPv6
หากบริการเป็นขาเข้า ที่อยู่ขาออกไม่เพียงพอ
การเข้าถึงขาเข้าต้องมีสี่สิ่งเรียงกัน ชื่อหรือที่อยู่ที่ไคลเอนต์เข้าถึงได้ เส้นทางที่นำแพ็กเก็ตไปยังเครื่อง ตัวรับฟังที่ยอมรับแพ็กเก็ตนั้น และนโยบายที่ไม่ทิ้งแพ็กเก็ตนั้น VPN เปลี่ยนรายการที่สองและบางครั้งรายการแรก และไม่ได้ทำอะไรให้รายการที่สามและสี่ เมื่ออุโมงค์เป็นเส้นทางส่งมอบ ไคลเอนต์จะเชื่อมต่อกับที่อยู่ของอุโมงค์ ไม่ใช่ทางออก
บันทึกว่าแต่ละบริการขึ้นอยู่กับที่อยู่ใด แล้วทบทวนบันทึกนั้นทุกครั้งที่ผู้ให้บริการเปลี่ยนรูปแบบการกำหนดเส้นทาง เซิร์ฟเวอร์ที่ตอบสนองแบบส่วนตัวแต่ล้มเหลวแบบสาธารณะมักไม่ได้เสีย แต่กำลังตอบสนองด้วยตัวตนที่ผิด และการซ่อมแซมคือการตัดสินใจเรื่องการแมป ไม่ใช่การเปลี่ยนไฟร์วอลล์