VirtualBox VPN แล็บ: VM เกตเวย์ หรือเครือข่ายเฉพาะโฮสต์
เลือกหว่าง VM เกตเวย์ที่กำหนดเส้นทางกับเซกเมนต์เฉพาะโฮสต์สำหรับแล็บ VPN บน VirtualBox แล้วทำให้แขกล้มเหลวแบบปิดเมื่ออุโมงค์ขาด
คุณต้องตัดสินใจว่าแล็บ VPN ของคุณสมควรได้เครื่องจักรกลมากแค่ไหน VM เกตเวย์ที่กำหนดเส้นทางระหว่างสองเซกเมนต์ของ VirtualBox จะจำลองการแปลที่อยู่ เส้นทางย้อนกลับ และตำแหน่งไฟร์วอลล์ที่ไคลเอนต์จริงนั่งอยู่ข้างหลัง เซกเมนต์เดียวแบบเฉพาะโฮสต์ให้ประตูที่ควบคุมได้หนึ่งบานและไม่มีอะไรอื่น เวอร์ชันเกตเวย์ต้องใช้แขกสามเครื่องและตารางเส้นทางที่คุณดูแล ส่วนเวอร์ชันเฉพาะโฮสต์ใช้แขกหนึ่งเครื่องและนโยบายหนึ่งอย่าง คำถามสามข้อแยกทั้งสองออกจากกัน และข้อที่สามตัดสินว่าการทดสอบของคุณจะผ่านได้เลยหรือไม่
ตอบคำถามสามข้อก่อนคัดลอกอะไรก็ตาม
เริ่มจากสิ่งที่เซิร์ฟเวอร์ VPN ต้องสังเกต หากเซิร์ฟเวอร์ต้องเห็นที่อยู่ต้นทางที่ไม่ใช่ของแขกทดสอบ จะต้องมีบางสิ่งแปลระหว่างทั้งสอง และสิ่งนั้นต้องเป็นเราเตอร์ที่คุณควบคุม เครือข่ายเฉพาะโฮสต์ให้อะแดปเตอร์แก่โฮสต์บนเซกเมนต์ของแขก ไม่ใช่ตัวแปล เมื่อแขกต้องเข้าถึงบางสิ่งภายนอก คุณจะต่ออะแดปเตอร์ NAT และเอนจิน NAT ของ VirtualBox เองจะเขียนที่อยู่ต้นทางใหม่โดยไม่ถามคุณ
จากนั้นถามว่าแขกเข้าถึงสิ่งอื่นใดได้หรือไม่นอกเหนือจากอุโมงค์ คำตอบนั้นเลือกภายในหรือเฉพาะโฮสต์ และนี่คือคำถามที่บทความแล็บส่วนใหญ่ข้ามไป สุดท้ายถามว่าจะเกิดอะไรขึ้นเมื่ออุโมงค์ล่ม เพราะสิ่งนั้นกำหนดนโยบายไม่ใช่โทโพโลยี และแล็บที่พิสูจน์เพียงเส้นทางที่มีความสุขแทบไม่ได้ทดสอบอะไรเลย
| What the test requires | Routed gateway VM | Host-only guest |
|---|---|---|
| Server sees a translated source address | Yes, from your own MASQUERADE rule | No, VirtualBox NAT does it instead |
| The guest has exactly one egress | Yes, while the second adapter faces the tunnel | Only until a NAT adapter is attached |
| Policy is testable during a tunnel failure | Rules live in one place | Rules live on each guest |
เชื่อมสามบทบาทด้วยเครือข่ายภายใน
ใช้แขกสามเครื่องและเซกเมนต์ที่ตั้งชื่อสองเซกเมนต์ โดยให้เกตเวย์เป็นเครื่องเดียวที่มีอะแดปเตอร์ทั้งสองด้าน
VBoxManage modifyvm lab-client --nic1 intnet --intnet1 WAN
VBoxManage modifyvm lab-server --nic1 intnet --intnet1 LAN
VBoxManage modifyvm lab-gw --nic1 intnet --intnet1 WAN --nic2 intnet --intnet2 LANไม่มีขั้นตอนสร้างแยกสำหรับเครือข่ายภายใน สตริงใน --intnet1 คือเซกเมนต์นั้นเอง สองเครื่องจะใช้ร่วมกันก็ต่อเมื่อชื่อตรงกันทุกตัวอักษร และไม่มีสิ่งใดบนโฮสต์เชื่อมต่ออยู่ คุณสมบัติสุดท้ายนี้คือเหตุผลที่แล็บทำซ้ำได้อย่างสะอาด เพราะเส้นทางของโฮสต์ ไคลเอนต์ VPN ของโฮสต์เอง และไฟร์วอลล์ของโฮสต์ไม่สามารถเข้าถึงแขกได้โดยบังเอิญ เซกเมนต์ภายในยังไม่มีเซิร์ฟเวอร์ DHCP เว้นแต่คุณจะเพิ่มเข้าไป ที่อยู่แบบคงที่จึงเป็นทางที่สั้นที่สุด
ให้ไคลเอนต์มีเฉพาะที่อยู่ WAN ของตน โดยเกตเวย์เริ่มต้นชี้ไปที่ที่อยู่ WAN ของเกตเวย์ เซิร์ฟเวอร์ได้ที่อยู่ LAN และใช้ที่อยู่ LAN ของเกตเวย์เป็นเกตเวย์เริ่มต้น แขกที่ถือสองที่อยู่บนเซกเมนต์เดียว หรือมีเส้นทางหลงผิดไปยังอีกเซกเมนต์หนึ่ง มีเส้นทางอ้อมเราเตอร์ และการทดสอบด้านล่างจะโกหกคุณ
ฉันเก็บไฟล์ข้อความข้างชื่อ VM พร้อมที่อยู่ทั้งสี่และชื่อเซกเมนต์ทั้งสอง แล้ววางลงในทุกเชลล์ หลายสัปดาห์ต่อมา เมื่อการเปลี่ยนโปรไฟล์ทำอะไรบางอย่างพัง ไฟล์นั้นคือความแตกต่างระหว่างการดีบักโปรไฟล์กับการดีบักความจำของฉันเอง
เลือกภายในหรือเฉพาะโฮสต์สำหรับเซกเมนต์ที่ไม่ควรรั่ว
โหมดเฉพาะโฮสต์สร้างอะแดปเตอร์เสมือนบนโฮสต์เอง โดยปกติคือ vboxnet0 และให้ที่อยู่แก่โฮสต์บนเซกเมนต์ของแขก นั่นสะดวกสำหรับการดูแลระบบและเป็นอันตรายถึงตายสำหรับการทดสอบการแยก เพราะโฮสต์สามารถเข้าถึงแขกได้โดยตรง และทุกบริการฝั่งโฮสต์กลายเป็นเส้นทางที่เป็นไปได้ โหมดภายในไม่มีอะแดปเตอร์โฮสต์เลย สองโหมดนี้สับสนกันง่ายในแผงการตั้งค่าเครือข่าย ดังนั้นให้ตรวจสอบความแตกต่างที่จัดทำเป็นเอกสารไว้แทนที่จะดูที่ป้ายชื่อ (ดูหน้า รายละเอียดเครือข่ายของ VirtualBox)
สำหรับแขกที่ต้องใช้อุโมงค์ ภายในเป็นค่าเริ่มต้นที่ปลอดภัยกว่า โดยเกตเวย์เป็นทางออกเดียว หากคุณเก็บเฉพาะโฮสต์ไว้ ให้ถือว่าอะแดปเตอร์โฮสต์เป็นเส้นทางบริหารจัดการและพูดออกมาดัง ๆ ว่า โฮสต์เข้าถึงแขกได้ และแขกต้องไม่สามารถใช้โฮสต์เป็นทางออกได้
VBoxManage modifyvm lab-client --nic1 hostonly --hostonlyadapter1 vboxnet0การแยกที่คุณพิสูจน์ได้คือการแยกที่คุณกำหนดค่า แขกที่มีอะแดปเตอร์ภายในหนึ่งตัว มีเส้นทางเริ่มต้นที่เกตเวย์ และไม่มีอะแดปเตอร์ NAT ไม่มีเส้นทางที่ข้ามเกตเวย์ไป แขกที่มีอะแดปเตอร์เฉพาะโฮสต์และอะแดปเตอร์ NAT มีสองเส้นทาง และมีเพียงเส้นทางเดียวเท่านั้นที่คุณตั้งใจจะทดสอบ
กำหนดเส้นทางและแปลที่เกตเวย์ แล้วทำให้ล้มเหลวแบบปิด
VirtualBox ไม่ส่งต่อระหว่างเซกเมนต์ แขกเป็นผู้ทำ เมื่อ VM เซิร์ฟเวอร์ VPN อยู่หลังเกตเวย์ ให้เปิดการส่งต่อและแปลทราฟฟิกของไคลเอนต์ขณะที่ออกไปยังเซิร์ฟเวอร์
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADEด้วยกฎนั้น เซิร์ฟเวอร์จะเห็นที่อยู่ LAN ของเกตเวย์แทนที่อยู่ของไคลเอนต์ และนั่นคือลักษณะที่ไคลเอนต์จริงหลัง NAT ของผู้ให้บริการปรากฏต่อหัวเครือข่าย บันทึกค่า sysctl ไว้ใน /etc/sysctl.d/ และกฎไว้ในบริการไฟร์วอลล์ที่ดิสทริบิวชันใช้ มิฉะนั้นการรีบูตจะพาแล็บกลับไปสู่สถานะที่กำหนดเส้นทางแล้วแต่ยังไม่ได้แปลอย่างเงียบ ๆ
การส่งต่อไม่ใช่การอนุญาต ภายใต้นโยบาย FORWARD ค่าเริ่มต้นของ ACCEPT แขกที่มีเส้นทางเริ่มต้นชี้ไปที่เกตเวย์จะออกผ่านอินเทอร์เฟซที่ตารางเส้นทางเลือก ไม่ว่าจะมีอุโมงค์หรือไม่ หากเกตเวย์มีอะแดปเตอร์ NAT สำหรับติดตั้งแพ็กเกจด้วย อะแดปเตอร์นั้นคือทางออกที่ไม่เข้ารหัสซึ่งใช้งานได้ในวินาทีที่อุโมงค์ล่ม และการทดสอบเฉพาะ VPN ของคุณก็ไม่เคยเป็นการทดสอบเฉพาะ VPN เลย
เมื่อเซิร์ฟเวอร์อยู่ระยะไกลและเกตเวย์เองเป็นผู้สิ้นสุดอุโมงค์ การตัดสินใจเดียวกันจะชี้ไปที่อินเทอร์เฟซอุโมงค์ ไม่ใช่การ์ดเครือข่ายที่ไปถึงอินเทอร์เน็ต
iptables -P FORWARD DROP
iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPTแยกการขนส่งภายนอกของอุโมงค์เองและเส้นทางบริหารจัดการนอกแบนด์ออกจากทราฟฟิกที่ส่งต่อ หากวิธีเดียวที่จะซ่อมเกตเวย์คือผ่านอุโมงค์ที่คุณกำลังดีบัก แล็บจะกลายเป็นแบบฝึกหัดการล็อกตัวเองออก คอนโซลอนุกรม อะแดปเตอร์บริหารเฉพาะโฮสต์ หรือสแนปช็อตของสถานะดีที่รู้จัก ถูกกว่าการกู้เราเตอร์ที่พังด้วยมือ
ตรวจสอบเส้นทางจากแขก ไม่ใช่จากโฮสต์
ทำงานจากข้างในออกไป ยืนยันว่าไคลเอนต์เข้าถึงที่อยู่ WAN ของเกตเวย์ได้ จากนั้นเข้าถึงเซิร์ฟเวอร์ผ่านเกตเวย์ จากนั้นการเชื่อมต่อไปยังพอร์ต VPN ออกไปและกลับมา การดักจับบนอินเทอร์เฟซทั้งสองของเกตเวย์แสดงว่าคำตอบมาถึงและถูกทิ้งบนเส้นทางย้อนกลับหรือไม่ ซึ่งการดักจับเฉพาะบนไคลเอนต์แยกไม่ได้
tcpdump -ni eth0 udp port 1194
tcpdump -ni tun0 udp port 1194จากนั้นพิสูจน์ทางออก ถามบริการสะท้อนที่อยู่จากแขกว่าเห็นที่อยู่ต้นทางใด แล้วเทียบกับที่อยู่ทางออกของเกตเวย์เอง หากคำตอบตรงกับที่อยู่ของโฮสต์ แสดงว่ามีเส้นทางอ้อมอุโมงค์อยู่ ตรวจสอบว่าแขกใช้ตัวแก้ชื่อใดจริง และตรวจสอบ IPv6 แยกต่างหาก เพราะเซกเมนต์ที่เปิด IPv6 ไว้ในขณะที่อุโมงค์บรรทุกเพียง IPv4 จะรั่วตามการออกแบบไม่ใช่โดยบังเอิญ
สุดท้าย ทำลายมันโดยเจตนา หยุดอุโมงค์ หรือบล็อกพอร์ตภายนอกของมัน แล้วเปิดการเชื่อมต่อใหม่จากแขก มันต้องล้มเหลว และเหตุผลต้องเป็นสิ่งที่คุณระบุชื่อได้ ไม่มีเส้นทาง มีกฎปฏิเสธ หรือตัวแก้ชื่อตายแล้ว รีสตาร์ทอุโมงค์และยืนยันว่าแขกฟื้นตัวโดยไม่ต้องสร้างเครือข่ายใหม่ หากมี mesh VPN เช่น Hamachi หรือ ZeroTier ใช้แล็บร่วมกัน จำไว้อะแดปเตอร์แบบบริดจ์เป็นไปตามชื่ออะแดปเตอร์ ไม่ใช่ mesh ดังนั้นต้องชี้บริดจ์ใหม่หลังจากไคลเอนต์ติดตั้งอะแดปเตอร์เสมือนของตนเอง
VBoxManage list bridgedifs
VBoxManage modifyvm lab-client --bridgeadapter1 <mesh-adapter-name>การแบ่งอุโมงค์ของแขกกับโฮสต์สะท้อนปัญหาเดียวกัน การชี้เส้นทางเริ่มต้นของโฮสต์ไปที่แขกได้ผล และพร็อกซีภายในแขกก็ได้ผล ส่วน NAT ผ่านโฮสต์ไม่ได้บรรทุกอุโมงค์ของแขกสำหรับทราฟฟิกที่โฮสต์เป็นผู้เริ่ม บันทึกชื่อเซกเมนต์และกฎไฟร์วอลล์ไว้ที่เดียว ถ่ายสแนปช็อตของสถานะที่ใช้งานได้ และบันทึกที่อยู่ต้นทางที่เซิร์ฟเวอร์สังเกตเห็น การเปลี่ยนโปรไฟล์ครั้งถัดไปก็จะมีค่าใช้จ่ายเท่าการรันสคริปต์หนึ่งครั้งแทนที่จะสร้างแล็บใหม่