VPN trong môi trường lưu trữ đám mây / máy chủ chuyên dụng, đường hầm IPSec so với tinc


9

Tôi đang trong quá trình thiết kế một thiết lập mạng riêng ảo cho môi trường lưu trữ đám mây. Đưa ra các yêu cầu của chúng tôi, tôi không thực sự thấy điều này khác với môi trường máy chủ chuyên dụng. Ý tưởng là chúng tôi muốn cho phép khách hàng có thể yêu cầu người dùng của họ kết nối với các máy ảo cụ thể hoặc máy chủ chuyên dụng bằng VPN có thể cung cấp mã hóa phụ trợ (ví dụ: cho các công việc in được gửi lại cho mạng của khách hàng).

Chúng tôi đang xem xét việc hỗ trợ máy chủ lưu trữ IPSec (ESP và AH), và tất nhiên là các đường hầm SSH, nhưng cả hai đều không thực sự cung cấp khả năng sử dụng bộ điều hợp VPN. Do đó, chúng tôi đang xem xét bổ sung ít nhất một số điều sau đây, nhưng vì không gian ở mức cao, chúng tôi muốn tiêu chuẩn hóa không quá một hoặc hai trong số này (một sẽ tốt hơn):

  1. Hỗ trợ đường hầm IPSec trên máy chủ ảo hoặc chuyên dụng
  2. tin
  3. PPTP

Vì các máy chủ của chúng tôi đang sao lưu, v.v. có thể ở các trung tâm dữ liệu khác nhau, chúng tôi muốn sử dụng lại phương pháp VPN của chúng tôi ở đây. Điều này dường như sẽ loại trừ PPTP. Suy nghĩ hiện tại của tôi là IPSec có khả năng tốt hơn bởi vì chúng tôi có thể sử dụng các bộ điều hợp VPN tiêu chuẩn, nhưng việc thiết lập định tuyến (dựa trên yêu cầu của khách hàng) có thể khó khăn hơn đáng kể, đó là lý do tại sao chúng tôi cũng đang xem xét tinc.

Cái nào trong hai cái này là thích hợp hơn? Có phải nỗi sợ của tôi rằng quản lý định tuyến có thể là một vấn đề đau đầu nghiêm trọng với IPSec không chính đáng? Có một cách dễ dàng xung quanh này? Có những vấn đề khác liên quan đến tinc mà tôi đang thiếu (tức là ngoài việc yêu cầu một khách hàng riêng biệt)?

Cập nhật để trả lời câu trả lời của @ Wintermute :

Vâng, câu hỏi này là từ góc độ máy chủ. Lý do là đây là những máy chủ bị ngắt kết nối hiệu quả khỏi mạng của khách hàng. Có thị trường mục tiêu của chúng tôi là mạng lưới doanh nghiệp vừa và nhỏ. Có, chúng tôi đang mong đợi sử dụng IP công cộng cho mỗi máy chủ của khách hàng trừ khi họ cần một cái gì đó khác nhau (và sau đó chúng tôi có thể nói chuyện).

Giải pháp mà chúng tôi đang hướng tới là một trong đó khách hàng xác định các đường hầm IP và phạm vi mạng có thể truy cập được bởi các đường hầm đó và nơi chúng tôi kết hợp chúng với các công cụ quản lý riêng của chúng tôi (đang được phát triển), kết nối các yêu cầu của khách hàng với các thay đổi cấu hình. Vấn đề là vì chúng tôi không có khả năng chạy phần mềm định tuyến trên vms và máy chủ, nên bảng định tuyến cần được quản lý tĩnh để khách hàng mắc lỗi trong cấu hình sẽ thấy rằng VPN không hoạt động đúng.

Cũng có khả năng chúng tôi sẽ sử dụng ESP qua mạng cho các hoạt động nội bộ của chính chúng tôi (đối với những thứ như sao lưu). Toàn bộ thiết lập khá phức tạp và có nhiều quan điểm khác nhau, từ trung tâm máy chủ (máy khách vpn của chúng tôi đến máy chủ lưu trữ) đến trung tâm mạng (công cụ nội bộ), đến trung tâm cơ sở dữ liệu (công cụ của chúng tôi). Vì vậy, tôi sẽ không nói câu hỏi là đại diện cho toàn bộ cách tiếp cận của chúng tôi (và các câu hỏi đang được hỏi trên một loạt các trang web SE).

Không ai trong số này thực sự ảnh hưởng đến toàn bộ câu hỏi. Nó có lẽ là bối cảnh hữu ích mặc dù.

Câu trả lời:


6

Không chắc chắn về tinc nhưng IPSEC gần như là bắt buộc. Không có doanh nghiệp nghiêm túc sẽ tin tưởng PPTP.

Không chắc chắn làm thế nào IPSEC ảnh hưởng đến định tuyến. Một đường hầm là một đường hầm là một đường hầm bất kể mã hóa. Bạn sẽ gặp phải vấn đề tương tự: tách đường hầm hay không, khiến khách hàng hiểu khái niệm / ồ nhìn một cuộc đụng độ LAN IP của một khách hàng cụ thể với nhóm VPN bạn đã chọn, v.v.

Âm thanh giống như bạn đang nhắm vào thị trường SME (máy chủ cá nhân, đăng nhập trực tiếp, v.v.) để loại trừ các giải pháp tinh vi hơn, nhưng tôi sẽ liệt kê hai cách tiếp cận có thể

  • một số loại tập trung VPN cho phép cấu hình. Tất cả khách hàng đăng nhập vào bộ tập trung VPN sau đó tùy thuộc vào hồ sơ / nhóm / bất kỳ nhà cung cấp nào của nhà cung cấp, có quyền sử dụng giao thức X đến IP Y (tức là máy chủ của riêng họ).

  • Các bộ định tuyến ảo Cisco ASR1000V - mỗi khách hàng có một, sau đó bạn có thể chạy các đường hầm IPSEC trực tiếp (với VTI để giúp việc định tuyến xuất hiện dễ dàng) hoặc thậm chí chuyển trực tiếp MPLS cho khách hàng để bộ định tuyến xuất hiện như một nhánh khác trong cấu trúc liên kết của họ, sau đó phân bổ các VNIC của bạn Vlan, vv ở bên trong để họ có được một 'nhánh' ảo đẹp.

  • một phiên bản quy mô nhỏ hơn ở trên, chúng tôi đã sử dụng monowall để đạt được hiệu quả tuyệt vời cho mục đích này (tức là mỗi khách hàng có một thiết bị ảo lớp 3 hoạt động như một bộ định tuyến / tường lửa, họ VPN vào thiết bị này và chỉ truy cập vào Vlan của họ) , tuy nhiên sau đó mỗi bộ định tuyến / tường lửa cần địa chỉ IP công cộng của riêng họ.

Re: cách tiếp cận hiện tại của bạn, bạn nhận ra rằng mỗi máy chủ cần một IP công cộng hoặc bạn có một hệ thống NAT phức tạp và phức tạp trong đó mỗi đường dẫn VPN của khách hàng được cấp một cổng hoặc tương tự.

Tôi khuyên bạn nên có một nhà mạng toàn thời gian để xem xét bất kỳ thiết kế / đề xuất nào bạn có, có vẻ như bạn đang đến với nó từ nền máy chủ.


2
Ngoài ra, điều này có vẻ giống như một nitlog nhỏ, nhưng, bạn không thể ánh xạ lại ESP bằng cổng TCP mà không thiết lập đường hầm trước qua giao thức khác. Điều này là do ESP hoạt động ở cấp IP và do đó không có quyền truy cập vào số cổng. Có Nat-T là ESP trên UDP nhưng điều đó thậm chí còn phức tạp hơn. Dù sao, tôi sẽ đề nghị chỉnh sửa này.
Chris Travers

1

Vâng bạn đã đúng. Có vẻ như bạn sẽ phải đối phó với việc có các IP riêng trừ khi tổng hợp thông qua bộ tập trung VPN. TBH bộ tập trung có lẽ là lựa chọn tốt nhất, bạn sẽ chỉ cần thêm 1 IP cho tất cả các kết nối VPN, nhưng giao diện bên ngoài của nó sẽ cần nằm trong một mạng con / Vlan khác từ các máy chủ IP công cộng. Tôi sẽ nói rằng nếu không bạn đang cấu hình IPSEC VPN trực tiếp trên mỗi máy chủ riêng lẻ thì thật là một cơn ác mộng

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.