ตัวโหลดบาลานซ์ฮาร์ดแวร์กำหนดเส้นทางทราฟฟิก SSL ด้วย SNI หรือไม่


9

ขณะนี้เรามีฟาร์มเซิร์ฟเวอร์ที่โฮสต์ 2 แอปพลิเคชัน - ทั้งสองแอปพลิเคชันทำงานบนเซิร์ฟเวอร์ทั้งหมด เราต้องการแยกสิ่งนี้เพื่อให้เรามีเซิร์ฟเวอร์ฟาร์มเฉพาะสำหรับแต่ละแอพ (เรามีเหตุผลที่ดีในเรื่องนี้)

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

ดูเหมือนว่าเราเตอร์ที่เรากำลังเสนอไม่ได้ทำเช่นนี้ ฉันขอขอบคุณที่ไม่มี SNI สิ่งนี้เป็นไปไม่ได้ แต่เราคาดหวังว่าตัวบ่งชี้ SNI เกี่ยวกับการรับส่งข้อมูลทั้งหมดของเรา

ตอนนี้ฉันเป็นโปรแกรมเมอร์ไม่ใช่คนเครือข่าย แต่เมื่อมีคำขอเชื่อมต่อ SSL ใหม่เข้ามาเราเตอร์จะไม่สามารถตรวจสอบส่วนหัว SNI และกำหนดเส้นทางไปยังฟาร์มที่ถูกต้องได้ ฉันสมมติว่าการเชื่อมต่อ SSL ขาเข้าถูกระบุโดย {source IP: source port} ดังนั้นจึงไม่สามารถจดจำสิ่งนี้ได้สำหรับแพ็กเก็ตขาเข้าที่ตามมา (หาก SNI แสดงเฉพาะในแพ็กเก็ตแรก)

เท่าที่ฉันสามารถบอกได้ Haproxy ทำเช่นนี้ แต่ดูเหมือนว่าตัวโหลดฮาร์ดแวร์ไม่ได้ทำ มีเหตุผลสำหรับสิ่งนี้หรือสิ่งที่เราควรผลักดันหรือไม่

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

คำตอบ:


10

ตามเว็บไซต์ของพวกเขา F5 load balancer สนับสนุน SNI:

https://devcentral.f5.com/articles/ssl-profiles-part-7-server-name-indication

คุณสามารถสร้าง iRules ตาม SNI

ข้อจำกัดความรับผิดชอบ:

  • ฉันไม่ได้ตรวจสอบสิ่งที่พวกเขาอ้างสิทธิ์ในเว็บไซต์
  • ฉันไม่ได้ทำงานกับ F5 และฉันไม่ได้ใช้ในการผลิตนานกว่า 3 ปี

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

1
AFAIK หน้านี้พูดถึงการกำหนดเส้นทางการรับส่งข้อมูล SSL "... BIG-IP ช่วยให้คุณสามารถกำหนดโปรไฟล์ SSL หลายรายการให้กับเซิร์ฟเวอร์เสมือนเพื่อรองรับการใช้งานคุณสมบัติ TLS SNI คุณลักษณะ TLS SNI ไม่พร้อมใช้งานใน BIG- ก่อนหน้า เวอร์ชั่น IP ดังนั้นคุณจะต้องอัปเกรดหากคุณไม่ได้อยู่ใน v11.1.0 หรือสูงกว่า! เพื่อรองรับคุณสมบัตินี้เซิร์ฟเวอร์เสมือนจะต้องกำหนดโปรไฟล์ SSL เริ่มต้นสำหรับทางเลือกและโปรไฟล์ SSL หนึ่งรายการต่อไซต์ HTTPS โปรไฟล์ SSL จะใช้เมื่อชื่อเซิร์ฟเวอร์ไม่ตรงกับคำขอของไคลเอ็นต์หรือเมื่อเบราว์เซอร์ไม่สนับสนุนส่วนขยาย SNI "
bgtvfr

"เซิร์ฟเวอร์เสมือน" เป็นวิธีที่ใหญ่ IP เส้นทาง http / https ปริมาณการเข้าชมไปยังเซิร์ฟเวอร์แบ็กเอนด์ (= apache, Tomcat, websphere ... )
bgtvfr

ผู้เล่นรายใหญ่ส่วนใหญ่ (cisco, big-IP) ทำสิ่งนี้ตามที่กล่าวไว้ข้างต้น ฉันไม่แน่ใจว่าทำไมคำตอบอื่นถูกทำเครื่องหมายเป็นคำตอบ
Jim B

@JimB ฉันทำเครื่องหมายอื่น ๆ เป็นคำตอบเพราะฉันเป็นโปรแกรมเมอร์ที่พยายามเจรจาความสามารถของฮาร์ดแวร์เครือข่าย! ฉันได้ดูบทความเพิ่มเติมและยังไม่สามารถทำงานได้หากอุปกรณ์เลือกที่จะส่งต่อทราฟฟิกไปยังเซิร์ฟเวอร์ที่มีอยู่จริงต่างกันตามส่วนขยาย SNI (เท่าที่เราต้องการ) สิ่งนี้ดูมีความเกี่ยวข้องแม้ว่า: devcentral.f5.com/questions/…
potomato

9

เราเตอร์ไม่สามารถตรวจสอบส่วนหัว SNI ได้

เราเตอร์มักจะทำงานที่ชั้น OSI 3 เท่านั้นเช่นไม่ได้ตรวจสอบเนื้อหาของแพ็กเก็ต แต่เฉพาะ IP เป้าหมาย สำหรับการกำหนดเส้นทางจาก SNI ความเข้าใจของ TCP และ TLS นั้นจำเป็นซึ่งมีความซับซ้อนและมีราคาแพงกว่า (เกี่ยวกับประสิทธิภาพ) จากนั้นเพียงกำหนดเส้นทางตามที่อยู่ IP และนี่ก็มักจะไม่เรียกว่าการกำหนดเส้นทางอีกต่อไปแล้ว

Haproxy ทำเช่นนี้ .. ฮาร์ดแวร์ตัวโหลดบาลานซ์ไม่ทำงาน

คุณกำลังผสมเราเตอร์ (เลเยอร์ 3), ฮาร์ดแวร์โหลดบาลานเซอร์ (เลเยอร์ 4 และอาจสูงกว่า) และ Haproxy (ซอฟต์แวร์โหลดบาลานซ์) ตัวโหลดบาลานซ์ของฮาร์ดแวร์ไม่ได้เป็นอะไรมากไปกว่าอุปกรณ์ที่มีตัวโหลดบาลานเซอร์ของซอฟต์แวร์อยู่แล้วและอาจมีการเร่งความเร็วฮาร์ดแวร์สำหรับการทำงานบางอย่าง ไม่มีสิ่งใดที่ทำให้การสร้างสมดุล (ไม่ใช่การกำหนดเส้นทาง) ตามข้อมูล SNI เป็นไปไม่ได้บนตัวโหลดบาลานซ์ฮาร์ดแวร์และเหมือนคำตอบอื่นที่แนะนำว่ามีผลิตภัณฑ์ที่รองรับสิ่งนี้ แต่แน่นอนว่าจะต้องมีการติดตั้งใช้งานและมีประสิทธิภาพด้านค่าใช้จ่าย - ยิ่งคุณตรวจสอบปริมาณการใช้งานมากขึ้นเท่าไร


ตกลงเป็นไปได้ทางเทคนิค แต่ไม่ใช่ความคิดที่ดีสำหรับเหตุผลด้านประสิทธิภาพซึ่งเป็นสาเหตุที่ไม่ได้ทำ ขอบคุณ
potomato
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.