Nhờ giúp một giải pháp truyền Data cho HN<->SG

[diendan]

Hiện nay đang phải làm project cho một cty bạn, nối hai sites. Một đầu ở HN, còn đầu kia ở SG... Mục đích tạo một đường link data để phục vụ cho một ứng dụng N-Tears, hoặc Citrix. Tôi đang tính toán đến ba giải pháp với mục tiêu tối đa hóa LỢI ÍCH/CHI PHÍ. Đường truyền đảm bảo guaranteed bandwidth 256kbps. Có ba giải pháp:

1. Thuê đường truyền dữ liệu (kênh trắng) của VTN
2. Dùng dịch vụ BGP/MPLS VPN của VDC
3. Dùng VPN/NGN của VTN

::: Nếu có cách khác hay hơn, làm ơn chỉ giúp :)

Mình chưa biết giá cả, đã triển khai thực sự chưa của (2) và (3). Xin hỏi có ai biết thông tin về các service này, đánh giá giúp DỰ TOÁN cho giải pháp và phí hàng tháng duy trì dịch vụ là bao nhiêu..., chỉ cần recommend chọn cái nào hợp lý nhất

Anh Minh cho em một lời khuyên nha, cảm ơn anh và các bạn,

Em Diendan@

[kimlong]

Dịch vụ (2) và (3) chỉ đang ở mức thử nghiệm sao anh diendan có thể sử dụng được?

Xét về lý thuyết, hai loại dịch vụ sau chắc sẽ có cost nhỏ hơn loại (1).
Khách hàng của anh đã có sẵn đường truyền ra Internet chưa?

[diendan]

Bên đó có hai đường ADSL cho mỗi văn phòng kết nối internet rồi anh Long Nguyên, vì yêu cầu cho khoảng 40->60 users chạy ứng dụng nên cần một đường link đảm bảo tối thiểu 256kbps để có thể có dịch vụ chấp nhận được, nếu dùng Citrix thì đường 256 chỉ đáp ứng cho khoảng 15 concurrent users (mỗi session chiếm 9->24kbps, mình đã dùng khoảng 20k mới cho chất lượng OK). Như thế việc dùng ADSL là không thể đáp ứng, nếu thuê hai đường Leaseline với hai cổng internet rồi tunnel sẽ bị mất phí cổng, mất phí truy cập internet, overhead… do đó việc dính vào internet cho case này rủi ro hơi cao…, đã khuyến nghị nó chạy MTS/MSMQ/RDBMS [HN]-----[SG] MTS/MSMQ/RDBMS nhưng supplier đòi phí cao hơn cuối cùng đành bỏ do bên CTY không đánh giá được lợi hại của mô hình. Đành đốt tiền cho Telco vậy.

Đó là yêu cầu bài toán, và xin trả lời cho câu hỏi của anh về thực trạng, anh vui lòng cho lời khuyên nhé

Cảm ơn anh,

[itmansaigon]

Chỉ cần thuê VTN một đường private line 128 hay 192 kbps sau đó dùng hai cục nén data (real-time) ở hai đầu là xong, nếu chịu khó thì có thể dùng linux để làm cái cục compression đó đấy :wink:

http://www.oberhumer.com/opensource/lzo/

[robedan]

Nếu dùng VPN, cần phải đảm bảo chắc chắn là các ứng dụng Citrix có thể chạy được trên kết nối VPN này. Theo tôi biết, các ứng dụng Citrix sử dụng một số port trong tầm &lt;1000 cũng có và > 1000 cũng có.

Nếu chọn lựa VPN và dùng IPSec VPN thì cần xem xét cẩn thận yếu tố trên.

Tôi hướng về giải pháp dùng kênh truyền của VTN do các yêu cầu xác định về băng thông đã nêu ở đề bài.

[itmansaigon]

Nếu dùng VPN, cần phải đảm bảo chắc chắn là các ứng dụng Citrix có thể chạy được trên kết nối VPN này. Theo tôi biết, các ứng dụng Citrix sử dụng một số port trong tầm &lt;1000 cũng có và > 1000 cũng có.

Nếu chọn lựa VPN và dùng IPSec VPN thì cần xem xét cẩn thận yếu tố trên.



Khà khà,

Đã là VPN rồi mà lại còn sợ conflict port nữa :lol: , VPN chẳng qua là một hình thức kết nối WAN over Internet

[diendan]

Nếu đã dùng Citrix/Internet sẽ chẳng có VPN nào hết, tôi sẽ PAT Citrix ra ngoài và cho các client kết nối thẳng. VPN trong trường hợp này là một sự trả giá, tôi cũng không cần chức năng compress của VPN, Citrix đã làm được hết rồi..., VPN đồng nghĩa với Latency.

[itmansaigon]

Nếu đã dùng Citrix/Internet sẽ chẳng có VPN nào hết, tôi sẽ PAT Citrix ra ngoài và cho các client kết nối thẳng. VPN trong trường hợp này là một sự trả giá, tôi cũng không cần chức năng compress của VPN, Citrix đã làm được hết rồi..., VPN đồng nghĩa với Latency.

Compress cho private line chứ

Thực ra khi dùng VPN thì latency chỉ đáng kể khi thiết lập kết nối VPN, một khi các SA đã trao đổi xong rồi thì chạy vù vù, latency không đáng kể vì khi đó nó dùng symmetric encryption algorithm

Nếu ai đã có dịp dùng thử skype.com thì biết, khi conferencing với nhau nó dùng AES 256 bit để encrypt voice data đấy các bác ạ, nghe thử xem có phát hiện ra latency không :wink:

[robedan]

phải kiểm tra chắc chắn là Citrix có thể work với VPN được.
Việc VPN không làm việc với một số ứng dụng là chuyện bình thường.

VPN không nhất thiết lúc nào cũng dùng symmetric algorithm đâu.

[itmansaigon]

VPN không nhất thiết lúc nào cũng dùng symmetric algorithm đâu.

-> Bác này không có căn bản về VPN

VPN khi thiết lập kết nối & trao đổi key: asymmetric algorithm
VPN khi vận chuyển data: symmetric algorithm

[robedan]

có các giải thuật mã hóa sau đuợc dùng trong vpn

des
3des
aes
Cisco CET

itman cho hỏi là đặc trưng nào của các giải thuật này đề gọi nó là "symetric"?

[itmansaigon]

Bác có thể tham khảo thêm về VPN khi đọc bài viết này:

http://www.diendantinhoc.org/portal/NewsTopic/Security/1023504532/

[robedan]

DES, 3DES...là các gíải thuật đồng bộ
vẫn có giải thuật là bất đồng bộ.

Do đó tôi nói rằng "VPN không phải lúc nào cũng dùng giải thuật mã hóa đồng bộ" thì mất cơ bản điểm nào?

Xem thêm slide của Cisco nhé?

[itmansaigon]

DES, 3DES...là các gíải thuật đồng bộ
vẫn có giải thuật là bất đồng bộ.

Do đó tôi nói rằng "VPN không phải lúc nào cũng dùng giải thuật mã hóa đồng bộ" thì mất cơ bản điểm nào?

Xem thêm slide của Cisco nhé?

Nam mô a di đà phật! thiện tai, thiện tai

Nói thật nhé, robedan làm gì có cơ bản về VPN đâu mà sợ mất

[robedan]

ngay trong bản thân bài viết củ chuối của itmansg đăng trong cái link đó, anh ta cũng viết là "asynmetric". Các giải thuật DES/3DES và ÁES được xếp vào nhóm symetric.

Nói thật nhé, cá tính của anh hơi bất ổn thì phải?

[Simon]

DES, 3DES...là các gíải thuật đồng bộ
vẫn có giải thuật là bất đồng bộ.


Cái này sao giống truyền data quá vậy lol