ไคลเอนต์ VPN แบบเคลื่อนที่สามารถโฮสต์บริการให้สำนักงานได้หรือไม่?

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

ทิศทางของการ dial in ไม่ได้บอกอะไรเกี่ยวกับทิศทางของบริการ

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

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

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

ตามเส้นทางตอบกลับก่อนเปิดพอร์ต

เส้นทางมีสามส่วน ได้แก่ เส้นทางบนเกตเวย์ที่ชี้ไปยังที่อยู่ภายในของไคลเอนต์ นโยบายที่อนุญาตผู้เรียกที่ระบุ และบริการที่รับฟังบนเป้าหมาย แต่ละส่วนล้มเหลวต่างกัน นั่นคือเหตุผลที่ «VPN เปิดอยู่» แทบไม่บอกอะไรเลย

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

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

ชื่อและที่อยู่คือการตัดสินใจด้านการออกแบบ

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

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

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

ทดสอบบริการ ไม่ใช่สมาชิกภาพ

จากเป้าหมาย ยืนยันว่าอะไรและรับฟังที่ที่อยู่ใด แล้วยืนยันมุมมองของเกตเวย์ต่อเส้นทางตอบกลับ:

$ ss -ltnp | grep 8080
LISTEN 0 128 10.80.0.23:8080 0.0.0.0:*
$ ip -4 addr show tun0 | grep inet
inet 10.80.0.23/24 scope global tun0
$ ip route get 10.80.0.1
10.80.0.1 dev tun0 src 10.80.0.23

ตอนนี้ทดสอบจากฝั่งสำนักงานด้วยคำขอจริงแทนการสะท้อน curl ที่สำเร็จต่อบริการพิสูจน์เส้นทาง นโยบาย และผู้รับฟังในครั้งเดียว ขณะที่ ping ที่สำเร็จพิสูจน์เพียงว่า ICMP ได้รับอนุญาต หากคำขอล้มเหลว ให้ย้อนกลับผ่านทั้งสามส่วนแทนการขยายไฟร์วอลล์และหวัง

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

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