Enjoying the last night

before sending the mail.
being early or being late, it should be done, monkey!
give up fighting and start thinking about yourself first :)

Nhiều kết nối hơn

Trong bài viết trước về kết nối từ xa giải pháp kết nối ngược dùng SSH đã được đưa ra. Tuy nhiên, đó chưa là tất cả.

Thứ nhất, nếu tận dụng công cụ netcat (nc) thì không những chỉ TCP connnection được tunneling mà cả UDP connection cũng được tunneling dễ dàng. Nếu tốc độ của kết nối đủ cao, thực hiện tunneling cho 2 port 27015 TCP và UDP qua SSH là bạn có thể chơi được Mini-dust-pro từ xa :D

Thứ hai, nếu không phải dùng một SSH Server, một SSH client mà là 2 SSH client thì sao? Kết hợp 2 lần tunneling liên tiếp bạn có thể là cho 2 máy workstation không có IP thật kết nối TCP được với nhau. Khi đó, bạn có thể đi xa, mang theo laptop, dùng kết nối Internet của khách sạn chẳng hạn mà vẫn có thể điều khiển được workstation trong công ty.

Kết nối

Tình huống và nhu cầu
Trong công việc của một developer, mọi người rất dễ gặp tình huống làm việc từ xa. Mỗi developer thường có một workstation trong công ty và một máy tính ở nhà với kết nối ADSL hoặc dialup. Nhu cầu nảy sinh trong làm việc từ xa là làm sao có thể "truy cập" vào máy tính trong công ty từ máy tính ở nhà. Truy cập ở đây có nghĩa rộng, nó bao gồm hầu hết các loại kết nối có thông dụng, như kết nối Remote Desktop thông qua RDP, kết nối X server, kết nối VNC, kết nối để truyền nhận file...

Giải pháp có sẵn
Nhu cầu này không hề mới và có nhiều giải pháp được đưa ra để dùng, trong đó có:

1. VPN: Hoàn toàn có thể tạo ra VPN dễ dàng với một front gateway dùng Windows Server hoặc một hiện thực PPTP nào đó trên Linux, đây là cách cung cấp nhiều tiện lợi nhất. Tuy nhiên, có nhiều nhược điểm phát sinh:
• Cần phải có một Windows Server làm front gateway; chi phí không phải thấp. Hơn nữa, M$ nổi tiếng là bèo nhèo về security và dùng Windows làm Gateway trong quan điểm của tôi là không thích hợp. Nếu mua thêm một ISA server nữa thì quả là quá tốn kém.
• Cần phải được cài đặt, cấu hình bởi quản trị hệ thống và phải nằm trong chính sách/quy định của công ty. Việc này không phải là khả thi với tất cả mọi nhân viên.
  
  
2. Incoming SSH Tunneling: Cũng có thể được tạo ra và sử dụng một cách dễ dàng, bảo mật. Một điểm quan trọng là giải pháp này đòi hỏi hầu như là $0 chi phí phần mềm vì hoàn toàn có thể dùng một Unix/Linux server làm front gateway vì trên các hệ nền này đã có sẵn SSHD. Hơn nữa Unix/Linux nhìn chung vẫn ổn định và an toàn hơn Windows, lại hoàn toàn miễn phí. Tuy nhiên nó cũng có nhược điểm:
• Nó vẫn đòi hỏi sự cài đặt của quản trị hệ thống và phải nằm trong chính sách/quy định của công ty.
• Vẫn phải tốn kém ít nhất một máy chủ để chạy SSHD
  
  
3. Các dịch vụ kết nối từ xa: có nhiều dịch vụ trực tuyến hỗ trợ việc này, chẳng hạn LogMeIn, pcAnyWhere... Các dịch vụ này có cả ưu điểm lẫn nhược điểm:
   
• Ưu điểm: Máy làm việc và máy ở nhà đều không cần có IP thật, dễ cấu hình, hầu hết có thể dùng trình duyệt web để điều khiển
• Nhược điểm: Khá nhiều. Đa phần đều là dich vụ phải trả tiền nếu không thì kết nối không phải là dạng kết nối bảo mật. Đa phần sử dụng Java Applet. Người dùng luôn phải lệ thuộc vào sự tồn tại của dịch vụ online này. Một số dịch vụ đòi hỏi máy từ xa phải là máy Windows và điều này là vô cùng đáng ghét. Kết nối chậm vì phải thông qua máy chủ của nhà cung cấp dịch vụ (thường là ở nước ngoài, trong khi văn phòng công ty và nhà đều nằm trong nước và thậm chí còn nằm chung trong mạng khi sử dụng cùng nhà cung cấp dịch vụ Internet)

Rõ ràng chưa có giải pháp nào thực sự an toàn, tiết kiệm, dễ triển khai, nhanh cho người dùng là các developer bình thường?

Lật ngược suy nghĩ
Tuy nhiên, nếu nhìn lại kỹ hơn, bạn có thể thấy rằng những điểm sau đây đã bị bỏ qua:

1. Nếu máy ở nhà dùng ADSL hay dialup thì hầu hết đều có IP thật, tuy có thể động. Việc này có thể dàn xếp tốt bằng cách dùng các dịch vụ dynamic DNS.
2. SSH Tunneling là 2 chiều. Nếu dùng Local Forwarding thì chỉ mới tận dụng được một nửa sức mạnh tunneling của SSH mà thôi.

Như vậy, tại sao không lật ngược suy nghĩ lại trong việc áp dụng SSH tunneling? Nếu như máy ở nhà là một SSH server, máy trong công ty là client rồi dùng Remote Forwarding thay vì Local Forwarding?

?!?

Hoàn toàn có thể được mà lại đạt được nhiều thứ:

1. Không cần phải có bất cứ thiết lập nào của công ty, máy làm việc trong công ty chỉ cần kết nối được ra internet không thông qua proxy (hầu hết các cty đều cho phép việc này.)
2. Không tốn bất cứ chi phí phần mềm nào (SSHD trên Unix/Linux thì có sẵn, trên Windows thì có FreeSSHD và OpenSSH chạy với Cygwin). SSH Client thì rất nhiều và cái free chạy tốt hơn cái phải trả tiền.
3. Không bị ràng buộc bởi hệ điều hành. Không có chuyện anh phải là Windows User (hừ!)
4. Có thể thực hiện rất nhiều loại kết nối, không riêng gì các kết nối để điều khiển từ xa
5. Thậm chí có thể kết nối đến máy khác trong công ty (ặc ặc, vụ này căng à nha)
6. Kết nối hoàn toàn bảo mật, thậm chí bảo mật hơn khi dùng public key authentication
7. Kết nối là trực tiếp từ máy ở nhà đến máy công ty, không thông qua hay lệ thuộc một dịch vụ trực tuyến nào (bạn có thể không đồng ý vì vẫn lệ thuộc các dịch vụ DNS động, tuy nhiên cái này hoàn toàn có thể vượt qua được nếu chịu khó tự lập trình. Khi đó, chẳng cần ai bên ngoài cung cấp dịch vụ cả.) Và khi đó, bạn tự vận hành dịch vụ cho chính mình, không lệ thuộc ai cả.

Nghe rất hứa hẹn! :)

Nhưng bên trong nó ẩn chứa vấn đề:

• Nếu máy trong cty là client, bạn không có trong cty, ai vận hành chương trình client? Bạn cần phải kết nối vào được thì mới tự tay vận hành được, nhưng phải vận hành được thì mới kết nối vào được chứ! Ặc ặc, trứng và gà.

Điều đó dập tắt mọi toan tính?

Không!

1. Nếu mình không tự tay vận hành được thì mình sẽ để chương trình client đó... tự vận hành mà cung cấp thông tin từ xa để nó biết nên vận hành thế nào! (Nghe hơi giống IoC nhể :D)
2. Mà như vậy thì chương trình client đó không thể là các SSH client bình thường được. Cũng chẳng sao. Java có JSCH. Chạy tuyệt vời. Tại sao không tự viết một SSH client chỉ cần tunneling và khả năng tự vận hành theo chỉ thị từ xa? (thông qua HTTP connect chẳng hạn ?!?!)

Kết luận
Rõ ràng là làm được!

Nhưng vấn đề là phải code :(

Phải chăng, cái đầu của developer nó vậy? Nghĩ đâu rồi cuối cùng cũng quay về với code.