VirtualBox NAT หรือ bridge: VPN ของ VM สิ้นสุดตรงไหน

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

ใครเป็นผู้สิ้นสุดเซสชันที่เข้ารหัสจริง ๆ

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

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

NAT เขียนแขกใหม่จนดูเหมือนโฮสต์

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

# on the host: adapter mode and NAT DNS behaviour
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
VBoxManage modifyvm "lab-vm" --natdnshostresolver1 on

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

บริดจ์ให้แขกมีสัญญาเช่าและความเปิดเผยของตัวเอง

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

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

ทำไมแขกจึงเป็นเกตเวย์ของโฮสต์ไม่ได้

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

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

ssh -N -f -L 8080:internal-host.example:80 user@lab-vm

ตัวแปลงกับเส้นทางไม่ข้ามพรมแดน

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

# on the host
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
# inside a Linux guest
ip -4 route
resolvectl status
# inside a Windows guest
Get-DnsClientServerAddress

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