OpenVPN อุโมงค์เต็มรูปแบบ: เพิ่มทางออกอินเทอร์เน็ตฝั่งเซิร์ฟเวอร์

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

ดันเส้นทางเริ่มต้นและยืนยันว่าไคลเอนต์ติดตั้งอะไรไป

บรรทัดฝั่งเซิร์ฟเวอร์นั้นสั้น และมันมีผลเฉพาะไคลเอนต์ที่ยอมรับตัวเลือกที่ถูกดันไป รูปแบบ def1 ติดตั้งเส้นทางครึ่งเริ่มต้นสองเส้นแทนการลบเส้นทางเริ่มต้นเดิม ซึ่งรักษาการเชื่อมต่อปัจจุบันให้คงอยู่และยังคงดักจับทุกปลายทาง

push "redirect-gateway def1"

หลังจากเชื่อมต่อใหม่ ให้อ่านตารางเส้นทางของไคลเอนต์แทนการเชื่อถือโปรไฟล์ บน Linux รายการ /1 สองรายการจะปรากฏข้างเส้นทางเริ่มต้นเดิม และ Windows แสดงคู่นี้เป็น 0.0.0.0/1 และ 128.0.0.0/1 ไคลเอนต์ที่เพิกเฉยต่อตัวเลือกที่ถูกดันไป หรือถูกตั้งค่าให้ปฏิเสธ จะยังคงใช้เส้นทางเริ่มต้นเดิมและไม่ส่งทราฟฟิกอินเทอร์เน็ตเข้าอุโมงค์เลย จงตัดสินคำถามนี้ก่อนเปลี่ยนแปลงสิ่งใดบนเซิร์ฟเวอร์ เพราะไม่มีกฎฝั่งเซิร์ฟเวอร์ใดชดเชยได้

การส่งต่อเป็นการตั้งค่าของเซิร์ฟเวอร์ ไม่ใช่ของ VPN

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

sysctl net.ipv4.ip_forward
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-vpn-forward.conf
sudo sysctl --system

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

อนุญาตเฉพาะการผ่านที่คุณตั้งใจ และไม่มีอย่างอื่น

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

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

sudo iptables -A FORWARD -i tun0 -o eth0 -s 10.90.0.0/24 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

การเปลี่ยนทุกเชนเป็นยอมรับทำให้การทดสอบผ่านและลบเหตุผลที่ไฟร์วอลล์มีอยู่ รักษาขอบเขตไว้ที่พูลและอินเทอร์เฟซขาออก และปล่อยการส่งต่อที่ไม่เกี่ยวข้องไว้

ให้คำตอบมีที่ไป

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

sudo iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o eth0 -j MASQUERADE

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

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

พิสูจน์จากไคลเอนต์ ไม่ใช่จากเชลล์ของเซิร์ฟเวอร์

เริ่มด้วยคำขอ IPv4 แบบตัวเลข จากนั้นค้นหาชื่อ จากนั้นแอปพลิเคชัน ping พิสูจน์การส่งต่อและการแปลแต่มันไม่ได้พิสูจน์อะไรเกี่ยวกับการแปลงชื่อ เพราะตัวเลือก DNS จะมีผลก็ต่อเมื่อการผสานรวมฝั่งไคลเอนต์ติดตั้งมันไว้

curl -4 -m 5 http://198.51.100.10/
dig +short example.com

บันทึกการเปลี่ยนแปลงและขั้นตอนย้อนกลับไปพร้อมกัน เพื่อให้ย้อนนโยบายขาออกได้ในครั้งเดียวเมื่อการทดสอบล้มเหลว สูตรนี้ครอบคลุมเฉพาะ IPv4 จงทำบัญชี IPv6 แยกต่างหากก่อนอ้างว่าการติดตั้งนั้นรองรับทราฟฟิกทั้งหมด