โฮสต์สาธารณะเดียวสำหรับ VPN และเว็บ: จะแบ่งบทบาทอย่างไร

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

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

เลือกเจ้าของที่อยู่ก่อนเลือกพอร์ต

ปลายทางของทันเนลและเว็บเซิร์ฟเวอร์ใช้เคอร์เนลร่วมกันได้; การแบ่งที่อยู่ พอร์ต และโปรโตคอลเดียวกันในเวลาเดียวกันคือสิ่งที่ล้มเหลว WireGuard มักใช้ UDP 51820, OpenVPN ใช้ UDP 1194 หรือ TCP 443 และเว็บเซิร์ฟเวอร์ใช้ TCP 443 คู่ที่เจ็บปวดคือ OpenVPN บน TCP 443 ข้าง HTTPS เพราะทั้งคู่ต้องการซ็อกเก็ตเดียวกันและเคอร์เนลมอบให้ตัวที่ผูกก่อน มีเพียงตัวแยกสัญญาณด้านหน้า เช่น sslh หรือพร็อกซีที่เข้าใจ TLS เท่านั้นที่ให้ทั้งคู่ใช้พอร์ตร่วมกันได้ และมันเพิ่มองค์ประกอบที่ความล้มเหลวดูเหมือนปัญหไฟร์วอลล์ทุกประการ

ดูเจ้าของก่อนที่จะเปลี่ยนอะไร: ss -lntup พิมพ์ที่อยู่ภายใน พอร์ต และโปรเซสของทุกซ็อกเก็ตที่กำลังฟังอยู่ สองแถวที่แสดง 0.0.0.0:443 หมายความว่าบริการที่สองไม่เคยผูกเลย ไม่ว่าสคริปต์ init ของมันจะร่าเริงเพียงใด การทำบริดจ์ก็ย้ายเจ้าของด้วย เมื่อ eth0 เข้าร่วมกับ br0 ที่อยู่ IP จะย้ายไปที่ br0 และทุกกฎไฟร์วอลล์ที่ระบุ eth0 จะเลิกตรงกัน ดังนั้นผูกบริการบนบริดจ์และยืนยันด้วย ip -br addr.

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

กำหนดเส้นทางระหว่าง LAN สองเครือข่ายหรือทำ NAT ด้านหนึ่ง

LAN สองเครือข่ายที่มองไม่เห็นกันสามารถหมุนหาที่อยู่โฮสต์สาธารณะ ซึ่งจะส่งต่อระหว่างทันเนล การออกแบบที่กำหนดเส้นทางนี้ต้องมีสามอย่าง: เปิดการส่งต่อ มีเส้นทางไปยังทุกคำนำหน้าปลายทางไกล และมีนโยบายการส่งต่อที่ยอมให้ข้อมูลผ่าน sysctl -w net.ipv4.ip_forward=1 ครอบคลุมอย่างแรก ip route add 10.20.0.0/24 dev wg1 อย่างที่สอง และบรรทัด nftables เช่น nft add rule inet filter forward iifname "wg0" oifname "wg1" accept อย่างที่สาม

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

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

ทดสอบการแยกขณะที่สองบทบาทหยุดทำงาน

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

สามคำสั่งทำให้การทดสอบนั้นเป็นรูปธรรม curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ พิสูจน์ว่าตัวฟังภายในตอบสนองโดยไม่ต้องใช้ DNS ภายนอก wg show บนไคลเอนต์พิสูจน์ว่าการจับมือเสร็จสมบูรณ์ และ tcpdump -ni any port 51820 บนฮับแยกปัญหาการกำหนดเส้นทางออกจากปัญหาคีย์ การจับมือที่ไม่เคยปรากฏในการดักจับนั้นตายก่อนถึงโฮสต์: ไฟร์วอลล์ของผู้ให้บริการ ที่อยู่สาธารณะผิด หรือกฎ NAT ระหว่างทาง

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

รักษาชุดกฎให้อ่านได้ขณะที่คุณลบบทบาท nft list ruleset ควรแสดงกฎอนุญาตหนึ่งข้อต่อทิศทางที่คุณต้องการจริง ๆ และเชนการส่งต่อที่ยอมรับทุกอย่างไม่ใช่การแยก นั่นคือเดโมที่ใช้งานได้

สายการเข้าถึงแบบ IPv6 เท่านั้นและบริการ IPv4

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

ทดสอบแต่ละตระกูลแยกกันด้วย curl -4 และ curl -6 เพราะคำขอที่สำเร็จหนึ่งครั้งไม่ได้บอกอะไรเกี่ยวกับเส้นทางที่คุณไม่ได้ลอง ความเป็นเจ้าของพอร์ตไม่เปลี่ยนระหว่างตระกูล แต่ตัวฟังเปลี่ยน: ss -lntup แสดงซ็อกเก็ต IPv4 และ IPv6 เป็นแถวแยกกัน และ 0.0.0.0:443 ไม่ครอบคลุม [::]:443 เว้นแต่โปรเซสจะขอซ็อกเก็ตแบบ dual-stack

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