NGINX จะบันทึกหมายเลขต้นทางใดสำหรับไคลเอนต์ VPN
ตัดสินใจว่า NGINX เห็นอะไรข้าง OpenVPN บนโฮสต์เดียว ทั้งที่อยู่ภายในของอุโมงค์ ที่อยู่ขาออกสาธารณะ หรือเพียร์ที่ส่งต่อ ขึ้นอยู่กับเส้นทางที่ใช้
มีที่อยู่ไคลเอนต์สามแบบปรากฏในการติดตั้ง NGINX คู่กับ OpenVPN บนโฮสต์เดียวกัน หนึ่งแบบสำหรับแต่ละเส้นทางที่คำขออาจใช้ เบราว์เซอร์ที่เข้าถึงที่อยู่ของอุโมงค์ เบราว์เซอร์ที่เข้าถึงที่อยู่สาธารณะ และโปรแกรมที่ออกผ่านเส้นทางอินเทอร์เน็ตของเกตเวย์ ต่างก็ดูไม่เหมือนกันที่ซ็อกเก็ตที่กำลังรับฟัง ตัดสินใจว่าคุณกำลังดูเส้นทางใดก่อนตีความบรรทัดบันทึก การตัดสินใจขึ้นอยู่กับปลายทางที่ไคลเอนต์ใช้ ข้อยกเว้นที่ไคลเอนต์มีสำหรับปลายทางภายนอกของ VPN และมีอะไรบางอย่างแปลงแพ็กเก็ตระหว่างทางหรือไม่
ตัดสินใจจากปลายทาง ไม่ใช่จากว่าผู้ใช้เป็นใคร
เริ่มจากที่อยู่ที่คำขอถูกส่งไป เพราะที่อยู่นั้นเป็นตัวเลือกเส้นทาง คำขอไปยังที่อยู่ของอุโมงค์จะมาถึงอินเทอร์เฟซของอุโมงค์โดยมีที่อยู่ภายในของไคลเอนต์เป็นต้นทาง คำขอไปยังที่อยู่สาธารณะของโฮสต์มักมาถึงอินเทอร์เฟซที่หันสู่อินเทอร์เน็ตด้วยที่อยู่สาธารณะของไคลเอนต์ แม้แล็ปท็อปเครื่องเดียวกันจะมีอุโมงค์อยู่แล้วในขณะนั้น การเป็นสมาชิกพูล VPN จึงเป็นคุณสมบัติของเส้นทางแพ็กเก็ต ไม่ใช่คุณสมบัติที่ติดตามผู้ใช้ไป
| Path the request took | Source the site normally records |
|---|---|
| Client reaches the site at its tunnel address, 10.24.0.1 | Client inner address, 10.24.0.20 |
| Client reaches another internet site through the gateway | Gateway public egress address, 192.0.2.44 |
| Client reaches the gateway's public address through the endpoint exception | Client's own public access address |
แถวที่สามนั้นคือแถวที่ควรตรวจก่อนเมื่อผู้ใช้ VPN ปรากฏในบันทึกด้วยที่อยู่ที่ไม่เกี่ยวข้องกับอุโมงค์เลย อีกทั้งยังอธิบายว่าทำไมผู้ใช้สองคนบนโปรไฟล์เดียวกันจึงสร้างรายการต่างกันได้ เครือข่ายการเข้าถึงของผู้ใช้เองนั้นต่างกัน และไม่มีอะไรในอุโมงค์เขียนทับสิ่งนั้น
เหตุใดปลายทางภายนอกจึงสร้างเส้นทางสาธารณะเส้นที่สอง
ไคลเอนต์ต้องเข้าถึงที่อยู่สาธารณะของเกตเวย์เพื่อสร้างอุโมงค์ ดังนั้นเส้นทางไปยังที่อยู่นั้นต้องมีอยู่นอกอุโมงค์ เมื่อไคลเอนต์เปลี่ยนเส้นทางให้ทราฟฟิกทั้งหมดวิ่งเข้าไปด้านใน การติดตั้งที่สมเหตุสมผลจะเก็บเส้นทางโฮสต์ที่ชัดเจนไปยังที่อยู่สาธารณะของเซิร์ฟเวอร์ไว้ เพื่อหลีกเลี่ยงอุโมงค์ที่พึ่งพาตัวเอง ข้อยกเว้นนั้นไม่ได้เลือกตามบริการ ดังนั้นทุกคำขอไปยังที่อยู่สาธารณะเดียวกันจะตามข้อยกเว้นนั้น รวมถึงคำขอจากเบราว์เซอร์ไปยังไซต์ที่โฮสต์บนเกตเวย์
นี่คือกลไกเบื้องหลังรายงานที่สับสนส่วนใหญ่ในสาขานี้ และมันขึ้นอยู่กับการติดตั้งของไคลเอนต์ไม่ใช่เซิร์ฟเวอร์ ไคลเอนต์สองตัวที่มีโปรไฟล์เหมือนกันจึงอาจทำงานต่างกันได้ การลบข้อยกเว้นเพื่อ »ซ่อม« บันทึกจะทำให้อุโมงค์ล่มไปด้วย ดังนั้นเก็บไว้และออกแบบโดยคำนึงถึงมัน
อ่านซ็อกเก็ต ตาราง และรูปแบบบันทึกไปพร้อมกัน
การสังเกตสามอย่างตัดสินว่าคุณกำลังดูเส้นทางใด ซ็อกเก็ตกำลังรับฟังที่ใด อินเทอร์เฟซใดตอบปลายทาง และรูปแบบบันทึกบันทึกอะไรจริง ๆ ถ้าตัวรับฟังผูกกับที่อยู่ของอุโมงค์เท่านั้น คำขอสาธารณะก็ไปถึงไม่ได้เลย ซึ่งตัดสองแถวออกทันที ถ้าการค้นหาเส้นทางสำหรับไคลเอนต์คืนค่าอุปกรณ์อุโมงค์ แสดงว่าคำขอมาถึงพร้อมต้นทางภายใน และบันทึกควรแสดงเช่นนั้น
ss -lntp 'sport = :443'
ip route get 10.24.0.20
ip route get 192.0.2.44จากนั้นอ่านรูปแบบไม่ใช่บรรทัด ฟิลด์ที่ป้อนจากส่วนหัวที่ส่งต่อจะบันทึกคำกล่าวอ้าง ไม่ใช่เพียร์ของซ็อกเก็ต และคำกล่าวอ้างนั้นสำคัญเฉพาะเมื่อเพียร์ที่อยู่ติดกันเป็นพร็อกซีที่เชื่อถือได้ การเขียนทั้งสองค่าลงบันทึกจะยุติการโต้แย้งในภายหลัง เพราะเพียร์ที่อยู่ติดกันและที่อยู่ที่ถูกแทนที่เป็นข้อเท็จจริงคนละอย่าง และมีเพียงอย่างเดียวเท่านั้นที่มาจากเครือข่าย
log_format tunneled '$remote_addr $realip_remote_addr $request $status';
grep -n 'log_format' /etc/nginx/nginx.confเลือกจุดเข้าใช้งานที่ต้องการและทำให้ DNS สอดคล้อง
ถ้าไซต์ควรเข้าถึงได้ทางอุโมงค์เท่านั้น ให้ชื่อที่สำหรับไคลเอนต์ VPN จะแปลงเป็นที่อยู่ของอุโมงค์ และบังคับใช้นโยบายที่ซ็อกเก็ตที่รับฟัง คำตอบ DNS แบบแยกส่วนที่คืนค่า 10.24.0.1 สำหรับชื่อภายในเป็นการตัดสินใจเรื่องเส้นทางในคราบของรายละเอียดการแปลงชื่อ ถ้าไซต์ต้องเป็นสาธารณะด้วย ให้เก็บสองชื่อหรือสองพอร์ตไว้ และให้บันทึกบอกว่าอันใดให้บริการคำขอนั้น
กฎการอนุญาตเป็นไปตามตรรกะเดียวกัน การอนุญาตพูลอุโมงค์ไม่ได้ให้สิทธิ์กับคำขอสาธารณะ และจะไม่เติมที่อยู่ภายในบนการเชื่อมต่อที่มาจากอินเทอร์เน็ต การผสมจุดเข้าใช้งานทั้งสองไว้ใต้ชื่อเดียวทำให้ต้นทางที่บันทึกเป็นผลข้างเคียงของการกำหนดเส้นทางฝั่งไคลเอนต์ แทนที่จะเป็นการเลือกออกแบบ
ตรวจสอบเส้นทาง แล้วจึงตรวจสอบนโยบาย
ยืนยันเส้นทางด้วยการดักจับบนเกตเวย์และคำขอที่คุณควบคุม การดักจับบนอุปกรณ์อุโมงค์และบนอินเทอร์เฟซสาธารณะแสดงว่าอันใดขนไบต์ไป และลำดับของแพ็กเก็ตบอกคุณว่ามีการแปลงเกิดขึ้นระหว่างนั้นหรือไม่
tcpdump -ni tun0 port 443 -c 5
tcpdump -ni eth0 port 443 -c 5จากนั้นตรวจสอบการเข้าถึงทั้งสองทิศทาง จุดเข้าใช้งานที่มีชื่อตามที่ตั้งใจทำงานกับไคลเอนต์ที่ตั้งใจ และเส้นทางสาธารณะที่ไม่ได้รับอนุญาตจะถูกปฏิเสธไม่ใช่เพียงแค่ช้า ไซต์สะท้อน IP ทั่วไปพิสูจน์บางอย่างเกี่ยวกับทางออกอินเทอร์เน็ตของเกตเวย์ และไม่ได้พิสูจน์อะไรเกี่ยวกับไซต์นี้บนโฮสต์เดียวกัน เมื่อหน้าเว็บกับ WebSocket ไม่ตรงกัน ให้เปรียบเทียบ URL ตระกูลที่อยู่ และคำตอบ DNS ของทั้งสองก่อนแตะการตั้งค่าเซิร์ฟเวอร์