6 điểm bởi GN⁺ 2024-09-20 | 1 bình luận | Chia sẻ qua WhatsApp

Hướng dẫn trực quan về SSH tunneling và port forwarding

  • Tóm tắt: Bài viết blog này được viết nhằm giúp hiểu rõ hơn về SSH tunneling và port forwarding. Nội dung bao gồm các trường hợp sử dụng, cấu hình, SSH jump host, port forwarding cục bộ/từ xa/động và các giới hạn.
Trường hợp sử dụng
  • Bảo mật:

    • Mã hóa các kết nối không an toàn như FTP
    • Truy cập bảng quản trị web thông qua SSH tunnel (xác thực bằng khóa công khai)
    • Giảm số lượng cổng bị lộ ra ngoài (chỉ mở cổng 22)
  • Khắc phục sự cố:

    • Vượt qua tường lửa/bộ lọc nội dung
    • Chọn tuyến đường khác
  • Kết nối:

    • Truy cập máy chủ nằm sau NAT
    • Truy cập máy chủ nội bộ qua Internet bằng jump host
    • Công khai cổng cục bộ ra Internet
Port forwarding
  • Cấu hình/chuẩn bị:
    • Người dùng cục bộ và từ xa cần có quyền để mở cổng
    • Các cổng từ 0-1024 cần quyền root
    • Cần cấu hình đúng tường lửa phía client và mạng
    • Phải bật port forwarding trên máy chủ SSH: AllowTcpForwarding yes
    • Nếu muốn forward cổng từ các interface khác, cần bật GatewayPorts yes
SSH jump host / SSH tunnel
  • Kết nối qua jump host:

    ssh -J user@REMOTE-MACHINE:22 -p 22 user@10.99.99.1
    
  • Sử dụng nhiều jump host:

    ssh -J user@REMOTE-MACHINE:22,user@ANOTHER-REMOTE-MACHINE:22 -p 22 user@10.99.99.1
    
Port forwarding cục bộ
  • Ví dụ 1:

    ssh -L 10.10.10.1:8001:localhost:8000 user@REMOTE-MACHINE
    
  • Ví dụ 2:

    ssh -L 8001:10.99.99.1:8000 user@REMOTE-MACHINE
    
Port forwarding từ xa
  • Ví dụ 1+2:

    ssh -R 8000:localhost:8001 user@REMOTE-MACHINE
    ssh -R 8000:10.10.10.2:8001 user@REMOTE-MACHINE
    
  • Ví dụ 3:

    ssh -R 10.99.99.2:8000:10.10.10.2:8001 user@REMOTE-MACHINE
    
Port forwarding động
  • Sử dụng giao thức SOCKS:
    ssh -D 10.10.10.1:5555 user@REMOTE-MACHINE
    
SSH TUN/TAP tunneling
  • Tạo tunnel TCP hai chiều:
    ssh -w local_tun[:remote_tun]
    
Chạy SSH ở chế độ nền
  • Chạy ở chế độ nền:

    ssh -fN -L 8001:127.0.0.1:8000 user@REMOTE-MACHINE
    
  • Dừng SSH chạy nền:

    ps -ef | grep ssh
    kill <PID>
    
Duy trì kết nối SSH
  • Xử lý timeout:
    • ClientAliveInterval 15
    • ClientAliveCountMax 3
Giới hạn
  • UDP:

    • SSH yêu cầu truyền tải đáng tin cậy nên không hỗ trợ UDP
  • TCP-over-TCP:

    • Do tăng overhead nên thông lượng giảm và độ trễ tăng
  • Không thay thế VPN:

    • SSH tunneling có thể thay thế VPN, nhưng về mặt hiệu năng thì VPN phù hợp hơn
  • Rủi ro bảo mật tiềm ẩn:

    • Nên tắt các tính năng không cần thiết

Tóm tắt của GN⁺

  • Bài viết này giải thích nhiều trường hợp sử dụng và cách cấu hình khác nhau của SSH tunneling và port forwarding
  • SSH tunneling hữu ích để cung cấp kết nối an toàn và vượt qua tường lửa
  • Tuy nhiên, nó không thể thay thế hoàn toàn VPN và có những giới hạn như suy giảm hiệu năng
  • Các dự án liên quan khác bao gồm những giải pháp VPN như OpenVPN

1 bình luận

 
GN⁺ 2024-09-20
Ý kiến trên Hacker News
  • Trong năm 2024, thay vì tự viết trực tiếp lệnh SSH, nên dùng tệp ~/.ssh/config để cấu hình LocalForward, RemoteForward và ProxyJump

    • Có thể tiết kiệm thời gian khi truyền dữ liệu qua nhiều kết nối SSH trung gian bằng các cấu hình ví dụ
    • Sau khi cấu hình, có thể dùng bí danh để sử dụng SSH, SCP và RSYNC với target-server
    • Có thể port forwarding dễ dàng bằng cấu hình LocalForward và RemoteForward
  • SSH tunneling là thứ thiết yếu trong các môi trường công ty phức tạp

    • Do nhiều thủ tục quan liêu và thời gian chờ đợi, việc có được quyền truy cập cần thiết thường mất thời gian
    • Dùng lệnh ssh -D 8888 someserver rồi đặt SOCKS proxy của trình duyệt thành localhost:8888 thì lưu lượng trình duyệt sẽ được định tuyến qua máy chủ đó
  • Khi muốn SSH vào một máy chủ Linux hoặc thiết bị IoT nằm sau tường lửa và không có IP tĩnh, có thể dùng dịch vụ tunneling

  • Trải nghiệm “hack” SSH tunneling phức tạp nhất xảy ra khi kết nối giữa các trung tâm dữ liệu

    • Cần chuyển dữ liệu từ A sang B, rồi từ B sang C
    • Đã kết hợp rsync, SSH tunnel, khóa và routing để chuyển dữ liệu thành công
    • Khi đó là một thành tựu lớn, và đến giờ ký ức ấy vẫn còn rất rõ
  • Mong có nhiều hình thức trực quan hóa mạng hơn

    • Đặc biệt cần trực quan hóa lưu lượng ở các kết nối mức thấp
  • TCP-over-TCP có thể làm tăng overhead và độ trễ, từ đó làm giảm hiệu năng

    • Trong SSH tunnel thì đây không phải vấn đề trừ khi dùng TAP/TUN
    • Tuy nhiên, khi dùng nhiều kênh thì hiệu năng có thể bị suy giảm
  • SSH tunnel là một công cụ tuyệt vời, nhưng dạo gần đây người ta dùng nhiều hơn các công cụ có tích hợp TLS và tính năng reverse proxy

  • sshuttle là công cụ tốt hơn cho tunneling

    • Có thể dùng như VPN bằng lệnh sshuttle -r user@host 10.0.0.0/8
  • 15 năm trước đã bắt đầu dùng SSH tunnel để vượt tường lửa của mạng trường đại học

    • Đã đổi cổng mặc định sang 443 để sử dụng
    • Từ đó đến nay vẫn dùng cho nhiều mục đích khác ngoài việc vượt tường lửa
  • Tò mò liệu bản thân SSH có tính năng redirect hay không

    • Khi A cố SSH vào B, B sẽ bảo hãy kết nối tới C, và A sẽ trực tiếp kết nối tới C một cách trong suốt
    • Khi đó B không còn là một phần của đường đi dữ liệu quan trọng nữa
    • Muốn biết liệu có tính năng như vậy tồn tại hay không