พร็อกซีสาธารณะเข้าถึงต้นกำเนิดส่วนตัวผ่าน VPN ได้อย่างไร

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

สองแบบจำลองที่ดูคล้ายกันบนแผนภาพ

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

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

TLS หยุดที่ใด และมันพิสูจน์อะไรได้จริง

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

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

เชื่อถือเฮดเดอร์ที่ส่งต่อมาจากพร็อกซีเท่านั้น

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

curl -s -o /dev/null -w '%{http_code}
' -H 'X-Forwarded-For: 203.0.113.9' http://172.20.5.40/

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

รักษาต้นกำเนิดให้เข้าถึงได้จากที่เดียวเท่านั้น

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

ss -ltnp | grep -E ':(80|443)'

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