VPN ในสภาพแวดล้อมคลาวด์โฮสติ้ง / เซิร์ฟเวอร์เฉพาะ IPSec tunnels vs tinc


9

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

เรากำลังมองหาการสนับสนุนโฮสต์เพื่อโฮสต์ IPSec (ESP และ AH) และแน่นอนอุโมงค์ SSH แต่สิ่งเหล่านี้ไม่ได้มีความสามารถในการใช้อะแดปเตอร์ VPN เรากำลังพิจารณาที่จะเพิ่มอย่างน้อยบางส่วนต่อไปนี้ แต่เนื่องจากพื้นที่มีค่าสูงเราจึงต้องการสร้างมาตรฐานบนไม่เกินหนึ่งหรือสองแห่ง (ซึ่งจะดีกว่า):

  1. การสนับสนุนทันเนลของ IPSec บนโฮสต์เสมือนหรือโฮสต์เฉพาะ
  2. Tinc
  3. PPTP

เนื่องจากเซิร์ฟเวอร์ของเราทำการสำรองข้อมูล ฯลฯ อาจอยู่ในดาต้าเซ็นเตอร์ที่แตกต่างกันเราต้องการที่จะสามารถใช้วิธี VPN อีกครั้งได้ที่นี่ ดูเหมือนว่าจะตัดการใช้ PPTP ความคิดปัจจุบันของฉันคือ IPSec น่าจะดีกว่าเพราะเราสามารถใช้อะแดปเตอร์ VPN มาตรฐานได้ แต่การตั้งค่าการกำหนดเส้นทาง (ตามความต้องการของลูกค้า) น่าจะยากขึ้นอย่างมากซึ่งเป็นสาเหตุที่เราดูด้วย tinc

ข้อใดที่สองข้อนี้เป็นที่นิยมกว่า ฉันกลัวว่าการจัดการเส้นทางมีแนวโน้มที่จะปวดหัวอย่างรุนแรงกับ IPSec หรือไม่? มีวิธีง่ายๆในการนี้หรือไม่? มี gotchas อื่น ๆ เกี่ยวกับ tinc ที่ฉันหายไป (เช่นอื่นที่ไม่ใช่ลูกค้าแยกต่างหาก)?

อัปเดตเพื่อตอบสนองต่อคำตอบของ @ Wintermute :

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

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

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

สิ่งนี้ไม่มีผลกับคำถามโดยรวมเลย มันอาจจะเป็นบริบทที่มีประโยชน์

คำตอบ:


6

ไม่แน่ใจเกี่ยวกับ tinc แต่ IPSec นั้นเกือบจะบังคับแล้ว ไม่มีธุรกิจที่จริงจังที่จะไว้วางใจ PPTP

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

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

  • VPN concentrator บางชนิดที่อนุญาตโปรไฟล์ ลูกค้าทุกคนลงชื่อเข้าใช้ VPN concentrator จากนั้นขึ้นอยู่กับโปรไฟล์ / กลุ่ม / สิ่งที่ผู้จำหน่ายได้รับสิทธิ์ในการใช้โปรโตคอล X ถึง IP Y (เช่นเซิร์ฟเวอร์ของตนเอง)

  • Cisco ASR1000V เราเตอร์เสมือน - ลูกค้าแต่ละรายจะได้รับจากนั้นคุณสามารถเรียกใช้อุโมงค์ IPSec โดยตรง (ด้วย VTIs ทำให้การกำหนดเส้นทางปรากฏง่าย) หรือแม้แต่สั่ง MPLS กลับไปยังลูกค้าดังนั้นเราเตอร์จะปรากฏเป็นสาขาอื่นในโครงสร้างของพวกเขาแล้วจัดสรร VNIC VLANs ฯลฯ อยู่ข้างในเพื่อให้ได้ 'สาขา' เสมือนที่ดี

  • รุ่นที่เล็กกว่าของข้างต้นเราใช้ monowall เพื่อเอฟเฟกต์ที่ยอดเยี่ยมสำหรับจุดประสงค์นี้ (เช่นลูกค้าแต่ละคนจะได้รับอุปกรณ์เสมือนเลเยอร์ 3 ที่ทำหน้าที่เป็นเราเตอร์ / ไฟร์วอลล์พวกเขาใช้ VPN ในอุปกรณ์นี้และเข้าถึง VLAN เท่านั้น) อย่างไรก็ตามเราเตอร์ / ไฟร์วอลล์แต่ละตัวต้องใช้ที่อยู่ IP สาธารณะของตนเอง

Re: วิธีการปัจจุบันของคุณคุณรู้แล้วแต่ละเซิร์ฟเวอร์ต้องการ IP สาธารณะหรือคุณมีระบบที่ซับซ้อนและซับซ้อนของ NATs ที่เส้นทาง VPN ของลูกค้าแต่ละรายได้รับการจัดสรรพอร์ตเดียวหรือคล้ายกัน

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


2
นอกจากนี้อาจดูเหมือน nitpick เล็กน้อย แต่คุณไม่สามารถแมป ESP กลับด้วยพอร์ต TCP โดยไม่ต้องตั้งค่าช่องสัญญาณก่อนหน้าผ่านโปรโตคอลอื่น นี่เป็นเพราะ ESP ทำงานที่ระดับ IP และดังนั้นจึงไม่มีสิทธิ์เข้าถึงหมายเลขพอร์ต มี Nat-T ซึ่งเป็น ESP บน UDP แต่มันก็ซับซ้อนกว่า อย่างไรก็ตามคิดว่าฉันจะแนะนำการแก้ไขนี้
Chris Travers

1

ใช่คุณพูดถูก. ดูเหมือนว่าคุณจะต้องจัดการกับการมี IP แยกต่างหากเว้นแต่จะรวมกันผ่านตัวรวม VPN TBH the concentrator น่าจะเป็นทางออกที่ดีที่สุดคุณเพียงแค่ต้องการ IP เพิ่มเติม 1 อันสำหรับการเชื่อมต่อ VPN ทั้งหมด แต่อินเทอร์เฟซภายนอกของมันจะต้องอยู่ใน subnet / VLAN อื่นจากโฮสต์ IP สาธารณะ ฉันจะไปกับที่อื่นคุณกำลังกำหนดค่า IPSEC VPN โดยตรงบนแต่ละเซิร์ฟเวอร์สิ่งที่ฝันร้าย

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