ไคลเอนต์ OpenVPN สำหรับทั้ง LAN บน OpenWrt: ลำดับการทำงาน

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

ตัดสินใจว่าอะไรใช้ร่วมกันในอุโมงค์

เราเตอร์ที่แจก Wi-Fi และ DHCP สามารถรันไคลเอนต์เองได้ นั่นทำให้ทุกอุปกรณ์ที่เชื่อมต่ออยู่หลังอุโมงค์โดยไม่ต้องตั้งค่าทีละเครื่อง และเป็นรูปแบบที่ไซต์เล็ก ๆ ส่วนใหญ่ต้องการ มันยังเป็นรูปแบบที่ผลกระทบกว้างที่สุดเมื่ออุโมงค์ล่ม เพราะทุกอุปกรณ์เสียเส้นทางพร้อมกัน ไม่มีอะไรบน LAN ที่ยังมีเส้นทางออกที่ใช้งานได้

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

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

มอบเจ้าของให้อุโมงค์

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

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

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

ใส่ในโซน แล้วส่งต่อไปยังโซนนั้น

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

config interface 'vpn'
    option device 'tun0'
    option proto 'none'

config zone
    option name 'vpn'
    list network 'vpn'
    option input 'REJECT'
    option output 'ACCEPT'
    option forward 'REJECT'
    option masq '1'

config forwarding
    option src 'lan'
    option dest 'vpn'

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

Masquerade บนโซน VPN ยุบทุกที่อยู่ LAN ให้เป็นที่อยู่อุโมงค์ของเราเตอร์ก่อนแพ็กเก็ตออกไป นั่นตัดความจำเป็นของเส้นทางย้อนกลับไปยังซับเน็ตของคุณที่ฝั่งตรงข้าม

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

ระบุอัปลิงก์จริงใน NAT

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

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

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

จากนั้นเพิ่มตัวเลือกไคลเอนต์ที่กำหนดว่าอะไรเข้าอุโมงค์ คำสั่ง redirect-gateway ส่งทราฟฟิกอินเทอร์เน็ตของไคลเอนต์ผ่าน VPN และหากไม่มี อุโมงค์จะพาเฉพาะเส้นทางที่เซิร์ฟเวอร์ดันมาเท่านั้น ตรวจสอบตารางเส้นทางที่ได้ก่อนแตะ DNS

แยก Wi-Fi ด้วยตารางที่สอง

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

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

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

สงสัยนาฬิกาและแฟล็กของอุปกรณ์

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

นาฬิกาคือความล้มเหลวเงียบอีกอย่าง เราเตอร์ที่ไม่มีนาฬิกาแบตเตอรี่เริ่มจากยุคศูนย์ ซึ่งหมายความว่าการตรวจสอบใบรับรองล้มเหลวจนกว่า NTP จะตามทัน เปรียบเทียบเวลในบันทึกกับเวลาจริงก่อนแตะใบรับรอง เพราะไคลเอนต์ที่เชื่อมต่อหนึ่งนาทีหลังบูตมักกำลังรอการซิงโครไนซ์เวลา