การเปิดเผยหลายเซิร์ฟเวอร์ที่อยู่เบื้องหลัง NAT โดยใช้ที่อยู่ IP สาธารณะเดียว

นี่เป็นคำถามที่ยอมรับได้เกี่ยวกับ NAT และ DNS

ขณะนี้ฉันกำลังพยายามตั้งค่าเครือข่ายด้วย DMZ ที่มีเว็บเซิร์ฟเวอร์และเซิร์ฟเวอร์อีเมลที่แยกออกจากอินเทอร์เน็ตโดยใช้ไฟร์วอลล์การแปลที่อยู่เครือข่าย (NAT)

ฉันได้ติดตั้งไฟร์วอลล์ NAT ด้วยอินเตอร์เฟสต่อไปนี้:

WAN - x.x.x.x (redacted public IP address)
DMZ - 192.168.124.5/24
LAN - 192.168.123.5/24

ใน DMZ ของฉันฉันมีโฮสต์ทั้งสองของฉัน:

Web server - 192.168.124.30
E-mail server - 192.168.124.32

ฉันรู้ว่าฉันจะต้องกำหนดค่า DNS สำหรับexample.comโดเมนที่จะแก้ปัญหาทั้งสองexample.comและmail.example.comที่อยู่ IP สาธารณะของฉัน

ฉันต้องการไฟร์วอลล์ NAT ของฉันเพื่อส่งต่อคำขอขาเข้าทั้งหมดไปexample.comยังเว็บเซิร์ฟเวอร์ที่ 192.168.124.30 และคำขอขาเข้าทั้งหมดไปmail.example.comยังเซิร์ฟเวอร์อีเมลที่ 192.168.124.32 ฉันเห็นคุณลักษณะ "การส่งต่อพอร์ต" ในการกำหนดค่าไฟร์วอลล์ NAT ของฉัน แต่ดูเหมือนจะไม่สามารถบรรลุสิ่งที่ฉันกำลังมองหา

คุณกำลังสับสนในความคิดของคุณเกี่ยวกับการไหลของข้อมูลระหว่างเลเยอร์ของโปรโตคอล TCP / IP สแต็ค - ระหว่าง DNS และโปรโตคอลเลเยอร์แอปพลิเคชันโดยเฉพาะ

คุณมีที่อยู่ IP สาธารณะหนึ่งแห่ง DNS ของคุณอย่างแน่นอนสามารถแก้ไขทั้งสองmail.example.comและexample.comไปยังที่อยู่ IP สาธารณะเดียวกัน

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

โปรโตคอล TCP และ UDP แยกความแตกต่างบริการเฉพาะที่นำเสนอโดยโฮสต์โดยใช้หมายเลขพอร์ต ในกรณีตัวอย่างของคุณอาจเป็นไปได้ที่จะใช้คุณสมบัติการส่งต่อพอร์ต (หรือที่เรียกว่าการแปลที่อยู่พอร์ตหรือ PAT) ของไฟร์วอลล์ NAT ของคุณเพื่อส่งคำขอขาเข้าไปยังพอร์ต TCP 80 (HTTP) ไปยังเว็บเซิร์ฟเวอร์ขณะส่งพอร์ต TCP ขาเข้า 25 (SMTP) ไปยังเซิร์ฟเวอร์อีเมลของคุณ

อย่างไรก็ตามหากคุณวางแผนที่จะโฮสต์บริการเดียวกันบนทั้งสองเครื่องกลยุทธ์นี้จะเป็นปัญหา สมมติว่าคุณกำลังจะโฮสต์ทั้งเว็บไซต์ที่ปลอดภัยบนเว็บเซิร์ฟเวอร์ของคุณ (สำหรับการเข้าถึงลูกค้า) และเว็บไซต์ที่ปลอดภัยบนเซิร์ฟเวอร์อีเมลของคุณ (สำหรับเว็บเมล) คำขอที่มาถึงที่อยู่ IP สาธารณะของไฟร์วอลล์ NAT ของคุณไปยังพอร์ต TCP 443 (HTTPS) สามารถกำหนดเส้นทางไปยังเซิร์ฟเวอร์หนึ่งหรืออื่น ๆ เท่านั้น

ทางออกทั่วไปสำหรับสถานการณ์นี้คือมีที่อยู่ IP สาธารณะมากขึ้น เนื่องจากที่อยู่ IPv4 เริ่มมีน้อยซึ่งอาจเป็นปัญหาได้เช่นกัน

เราสิ้นสุดการทำงานเกี่ยวกับการขาดแคลนที่อยู่ IP สาธารณะในโปรโตคอลบางตัวที่ชั้นแอปพลิเคชัน ตัวอย่างเช่น HTTP / 1.1 เพิ่มHost:ส่วนหัวโดยเฉพาะเพื่อให้เว็บเซิร์ฟเวอร์โฮสต์เว็บไซต์หลายแห่งในที่อยู่ IP สาธารณะเดียวกัน TLS เพิ่มส่วนขยายServer Name Indication (SNI) เพื่อให้สามารถเลือกใบรับรองที่เหมาะสมตามชื่อโฮสต์ที่ป้อนโดยไคลเอนต์ระยะไกล

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

แทนการแก้ไขโปรโตคอลชั้นแอปพลิเคชันบางโปรโตคอลสามารถคล้อยตามการ "มัลติเพล็กซ์" ระหว่างโฮสต์หลาย ๆ เครื่องโดยใช้ซอฟต์แวร์ที่สามารถ "ขอเส้นทาง" ได้อย่างง่ายดาย สิ่งนี้มีแนวโน้มที่จะเหนือกว่าไฟร์วอลล์ NAT แบบธรรมดาที่มีความสามารถเพราะต้องตรวจสอบแพ็คเก็ตที่ชั้นแอปพลิเคชัน การใช้ reverse-proxy อย่าง nginxเป็นตัวอย่างที่ดีของ "multiplexing" (หรือกฎการเผยแพร่ทางเว็บบน Forefront TMG หรือ ISA Serverในสภาพแวดล้อมของ Microsoft) สำหรับโปรโตคอล HTTP ในทางทฤษฎีโปรโตคอลใด ๆสามารถมัลติเพล็กซ์ผ่านพร็อกซีย้อนกลับได้ แต่ยิ่งโปรโตคอลมีความลึกลับมากเท่าใดคุณก็จะยิ่งพูดถึงการเขียนโค้ดที่กำหนดเองมากขึ้นเท่านั้น

เมื่อคุณต้องการเสนอบริการเดียวกันจากโฮสต์ที่แตกต่างกันสองแห่งในที่อยู่ IP สาธารณะเดียวคุณจะมีตัวเลือกเพื่อย้ายโฮสต์หนึ่งไปยังพอร์ตที่ไม่ได้มาตรฐาน สิ่งนี้จะทำให้ลูกค้าต้องระวังพอร์ตที่ไม่ได้มาตรฐาน ในกรณีของ HTTP (S) ผลลัพธ์นี้เป็น URL ที่มีhttp://example.com:XXXเครื่องหมาย (ซึ่งXXXเป็นหมายเลขพอร์ตที่ไม่เป็นมาตรฐาน) ไม่ว่าจะเป็นปัญหาในสถานการณ์ของคุณหรือไม่เป็นสิ่งที่คุณเท่านั้นที่สามารถตัดสินใจได้ (ประสบการณ์ของฉันแสดงให้เห็นว่าแทบไม่มีผู้ใช้ปลายทางที่สามารถจัดการ:XXXสัญลักษณ์พอร์ตใน URL ใด ๆ ที่พวกเขาต้องป้อนด้วยมือ)

คุณสมบัติ "การส่งต่อพอร์ต" ของคุณอาจอนุญาตให้คุณส่งทราฟฟิกที่กำหนดสำหรับ: 80 และ: 443 ถึง 192.168.124.30 และพอร์ตที่เหลืออยู่ หากด้วยเหตุผลบางประการที่คุณต้องการทั้งสองพอร์ตสำหรับเซิร์ฟเวอร์อีเมลและสำหรับเว็บเซิร์ฟเวอร์แสดงว่าคุณกำลังมีปัญหา เพื่อให้วิธีการนี้ใช้งานได้การเข้าใช้เว็บเซิร์ฟเวอร์ของคุณจะต้องอยู่ในพอร์ตที่ต่างออกไป คุณอาจตั้งค่าเว็บเซิร์ฟเวอร์เพื่อเปลี่ยนเส้นทางสิ่งที่ระบุว่า " mail.example.com" เพื่อใช้แทนสำหรับผู้ใช้ที่ไม่รู้วิธีต่อท้ายหมายเลขพอร์ตและ / หรือระบุการเชื่อมต่อที่ปลอดภัย (คุณกำลังจะใช้การเชื่อมต่อเว็บที่ปลอดภัยไปยังเมลเซิร์ฟเวอร์เท่านั้นใช่ไหม)https://mail.example.com:other_port

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

หาก "คำขอขาเข้า" ของคุณเป็นสิ่งที่แตกต่างกันเช่นการรับส่งข้อมูลเว็บ (HTTP) สำหรับเว็บเซิร์ฟเวอร์และการรับส่งเมล (SMTP) สำหรับเซิร์ฟเวอร์อีเมลสิ่งนี้สามารถทำได้จริง: HTTP ใช้พอร์ต TCP 80 (443 สำหรับ HTTPS) ในขณะที่ SMTP ใช้พอร์ต TCP 25 ดังนั้นจากที่อยู่ IP สาธารณะเดียวกันคุณสามารถส่งต่อปริมาณข้อมูล HTTP ไปยังเว็บเซิร์ฟเวอร์ของคุณและปริมาณการใช้งาน SMTP ไปยังเซิร์ฟเวอร์อีเมลของคุณ นี่คือความหมายของ "การส่งต่อพอร์ต" ไฟร์วอลล์ที่เหมาะสมก็สามารถทำได้

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