ก่อนจะโฮสต์ VPN ของคุณ VPS ต้องอนุญาตอะไรบ้าง

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

ยืนยันอินเทอร์เฟซที่โปรโตคอลต้องการ

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

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

sudo ip tuntap add dev tun9 mode tun
sudo ip tuntap del dev tun9 mode tun
sudo ip link add wgtest type wireguard && sudo ip link del wgtest

การถูกปฏิเสธในคู่แรกหมายความว่า TUN ไม่พร้อมใช้และโหมดเริ่มต้นของ OpenVPN เริ่มไม่ได้ การถูกปฏิเสธในบรรทัดสุดท้ายหมายความว่าอินเทอร์เฟซเคอร์เนลของ WireGuard หายไป เอกสารเคอร์เนลเกี่ยวกับ TUN/TAP อธิบายอุปกรณ์ที่การตรวจข้อแรกทดสอบ ความล้มเหลวทั้งสองไม่ได้รับการแก้ไขด้วยการติดตั้งแพ็กเกจ VPN ใหม่

จำไว้ว่าเส้นทางขาเข้ามีเจ้าของสองราย

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

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

วางแผนเส้นทางกลับ ไม่ใช่แค่ทางออก

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

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

sysctl -n net.ipv4.ip_forward
sudo nft list ruleset | head -n 40
ip -4 route show default

ตัดสินเรื่อง IPv6 อย่างชัดเจน

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

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

พิสูจน์จากไคลเอนต์ภายนอก

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

sudo wg show wg0 latest-handshakes
ip -4 route get 203.0.113.44
sudo journalctl -u wg-quick@wg0 -n 15 --no-pager

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