Đường hầm thông qua SSH hoặc "VPN cho người nghèo". Cài đặt và cấu hình

Đăng bởi: quản trị viên 17/10/2017

Cách hoạt động của đường hầm SSH

Đường hầm SSH, hay Chuyển tiếp cổng SSH như man(1) ssh gọi, là một chức năng giao thức tùy chọn chạy trên phiên SSH thông thường quen thuộc. Đường hầm SSH cho phép bạn gửi gói TCP từ một phía của kết nối SSH sang phía bên kia và phát tiêu đề IP theo quy tắc định trước trong quá trình truyền.

Rất đơn giản để hiểu cách hoạt động của đường hầm SSH: nếu bạn tưởng tượng nó như một kết nối điểm-điểm. Giống như trong PPP, bất kỳ gói nào chạm tới một đầu của kết nối sẽ được gửi và nhận ở đầu kia của đường hầm. Hơn nữa, tùy thuộc vào địa chỉ người nhận được chỉ định trong tiêu đề IP, gói sẽ được xử lý bởi phía nhận của đường hầm (nếu gói được gửi trực tiếp cho nó) hoặc được định tuyến sâu hơn vào mạng (nếu người nhận là một mạng khác). nút).

Sự khác biệt chính giữa đường hầm SSH và kết nối PPP là chỉ lưu lượng TCP mới có thể được bao bọc trong đường hầm SSH. (Lưu ý: Có một số cách để truyền UDP qua ổ cắm TCP bên trong đường hầm SSH, nhưng giải pháp đó nằm ngoài phạm vi của bài viết này.)

Điểm khác biệt thứ hai là trong kết nối điểm-điểm, lưu lượng truy cập đến có thể được bắt đầu từ bất kỳ phía nào, trong khi đối với đường hầm SSH, bạn phải đặt rõ ràng “điểm vào” cho lưu lượng. “Điểm vào” là một tham số có dạng<адрес>:<порт>, cho biết ổ cắm nào sẽ mở để vào đường hầm (từ phía cục bộ hoặc từ xa của phiên SSH).

Ngoài điểm vào, bạn phải chỉ định thêm quy tắc có dạng<адрес>:<порт>, theo đó tiêu đề (chính xác hơn là địa chỉ và cổng đích) của gói TCP phải được ghi lại trong quá trình truyền. Điểm vào có thể được đặt từ một trong hai đầu của đường hầm. Các phím –L (cục bộ) và –R (từ xa) chịu trách nhiệm cho tham số này. Theo cục bộ và từ xa, chúng tôi muốn nói đến các phía của đường hầm theo quan điểm của phía ban đầu, tức là máy chủ thiết lập phiên SSH.

Có vẻ hơi khó hiểu cho đến nay, vì vậy hãy xem xét nó bằng một ví dụ cụ thể.

Đường hầm SSH trực tiếp - cung cấp quyền truy cập vào máy chủ phía sau NAT

Alex làm việc quản trị hệ thống trong một công ty nhỏ tên là Qwerty Cakes, chuyên sản xuất bánh táo. Toàn bộ mạng của công ty được đặt trong một miền quảng bá 192.168.0.0/24. Để truy cập Internet, bộ định tuyến phần mềm dựa trên Linux được sử dụng, địa chỉ của nó là 192.168.0.1 ở phía mạng công ty và 1.1.1.1 ở phía Internet. Daemon OpenSSD đang hoạt động trên bộ định tuyến, có thể truy cập được qua ổ cắm 1.1.1.1:22. Bên trong mạng, một nội bộ cổng thông tin doanh nghiệp, về việc Alex cần thực hiện các thay đổi cho đến sáng mai giao diện web. Tuy nhiên, Alex không muốn đi làm muộn, anh ấy muốn truy cập cổng thông tin từ nhà của mình. máy tính ở nhà với địa chỉ 2.2.2.2.

Alex về nhà và cài đặt sau bữa tối kết nối tiếp theo với bộ định tuyến của công ty:

Chuyện gì đã xảy ra thế? Alex đã thiết lập phiên SSH giữa các địa chỉ 2.2.2.2 và 1.1.1.1, đồng thời mở một “điểm truy cập” cục bộ vào đường hầm 127.0.0.1:8080 trên máy tính ở nhà của anh ấy:

alex@Alex-PC:~$ sudo lsof -nPi | grep 8080

ssh 3153 alex 4u IPv4 9862 0t0 TCP 27.0.0.1:8080 (LẮNG NGHE)

Bất kỳ gói TCP nào đi vào ổ cắm 127.0.0.1:8080 từ máy tính của Alex sẽ được gửi qua kết nối điểm-điểm trong phiên SSH và địa chỉ đích trong tiêu đề TCP sẽ được ghi lại từ 127.0.0.1 thành 192.168.0.2, và cổng từ 8080 đến 80.

Bây giờ, để truy cập vào cổng thông tin của công ty mình, Alex chỉ cần gõ vào trình duyệt:

Họ đi bằng cách nào gói mạng bên trong một đường hầm SSH

Chúng ta hãy xem xét kỹ hơn những gì đã xảy ra với gói TCP khi nó đi qua đường hầm SSH:

1. Gói TCP có địa chỉ nguồn 127.0.0.1, địa chỉ đích và cổng 127.0.0.1:8080 được nhập vào socket 127.0.0.1:8080, mở theo quy trình ssh;

2. Quá trình ssh nhận được gói, theo quy tắc dịch, viết lại địa chỉ đích và cổng thành 192.168.0.2:80 và gửi nó trong phiên SSH tới bên từ xa 1.1.1.1;

3. Quá trình sshd trên bộ định tuyến 1.1.1.1 đã nhận gói và sau khi xem địa chỉ đích, gửi nó đến máy chủ 192.168.0.2, đồng thời ghi lại địa chỉ nguồn từ 127.0.0.1 thành địa chỉ giao diện của chính nó 192.168.0.1, để người nhận không biết gì về sự tồn tại của đường hầm SSH, đã trả lại gói tin cho bộ định tuyến và không gửi gói tin đó đến máy chủ cục bộ 127.0.0.1 của chính nó.

alex@Alex-PC:~$ ssh -L

127.0.0.1:8080:192.0.0.2:80 [email được bảo vệ]

TRONG trong ví dụ này, nếu cổng hoặc bất kỳ tài nguyên nào khác mà Alex cần truy cập nằm trên chính bộ định tuyến (ví dụ: tại 192.168.0.1:80), thì lệnh sẽ có dạng như sau:

Nếu dịch vụ có sẵn tại localhost (ví dụ: máy chủ SQL cục bộ), thì bạn có thể truy cập dịch vụ đó:

alex@Alex-PC:~$ ssh -L

127.0.0.1:13306:127.0.0.1:3306 [email được bảo vệ]

Các công trình như -L 127.0.0.1:80:127.0.0.1:80 thoạt nhìn có thể trông khá lạ. Nhưng chúng không có gì phức tạp nếu bạn nhớ rằng quyết định định tuyến gói được thực hiện ở phía xa của đường hầm. Bạn cần nhớ quy tắc cơ bản: cặp thứ hai<адрес>:<порт>được xử lý bởi phía xa của đường hầm.

Do đó, gói có địa chỉ đích là 127.0.0.1 trong quy tắc dịch sẽ được xử lý bởi phía thứ hai của phiên SSH và không có gì khác.

Như bạn có thể đã đoán, điểm vào đường hầm có thể được tạo không chỉ trên giao diện loopback. Nếu đường hầm cần được tạo khả năng tiếp cận không chỉ cho localhost, mà còn đối với những người tham gia mạng khác, thì bạn có thể chỉ định làm địa chỉ ổ cắm địa chỉ thực giao diện.

alex@Alex-PC:~$ ssh -L

10.0.0.5:8080:192.0.0.2:80 [email được bảo vệ]

Máy tính Alex-PC của Alex có hai giao diện mạng với địa chỉ 2.2.2.2 và 10.0.0.5. Trong quá trình thiết lập phiên, ssh sẽ mở socket 10.0.0.5:8080 trên máy tính Alex-PC. Bây giờ Alex có thể truy cập cổng 192.168.0.2:80 từ máy tính xách tay của mình với địa chỉ 10.0.0.4 và tất cả mạng trong nhà 10.0.0.0/24.

Đường hầm SSH đảo ngược - hiển thị tài nguyên của bạn với Internet

Như tôi đã nói, điểm vào đường hầm có thể được mở không chỉ từ phía người khởi tạo phiên ssh mà còn từ phía từ xa, tức là từ điểm mà chúng ta đang thiết lập phiên ssh. Để thực hiện việc này, hãy sử dụng tùy chọn -R thay vì tùy chọn -L. Nó dùng để làm gì?

Ví dụ, để có thể xuất bản dịch vụ địa phươngđể truy cập từ xa.

Web đang chạy trên máy tính xách tay của Alex máy chủ apache có sẵn tại 127.0.0.1 với bản sao thử nghiệm của cổng thông tin công ty. Alex cần được cấp quyền truy cập vào máy chủ webđể đồng nghiệp của bạn kiểm tra giao diện. Nói chung, với những mục đích như vậy, sẽ tốt hơn nếu Alex triển khai một giải pháp đáng tin cậy hơn hộp cát thử nghiệm. Nhưng vì Alex của chúng ta không gì khác hơn là một nhân vật ảo trong bài viết này nên anh ấy chỉ để minh họa SSH hoạt độngđường hầm thiết lập một phiên giữa máy tính xách tay của anh ấy và bộ định tuyến Linux. Và sử dụng tham số -R sẽ mở cổng 8080 trên giao diện nội bộ bộ định tuyến có địa chỉ 192.168.0.1, trỏ đến ổ cắm 127.0.0.1:80 của máy chủ Web thử nghiệm của nó.

Như bạn có thể thấy, trên bộ định tuyến, quá trình sshd đã mở ổ cắm cục bộ 8080

alex@Bộ định tuyến:~$

sudo lsof -nPi | grep 8080

sshd

17233 alex 9u IPv4

95930 0t0 TCP 192.168.0.1:8080 (Nghe)

Hãy xem điều gì xảy ra với gói TCP được gửi từ máy tính 192.168.0.200 tới cổng thử nghiệm được xuất bản trên 192.168.0.1:8080:

1. Gói TCP có địa chỉ nguồn là 192.168.0.200, địa chỉ đích và cổng là 192.168.0.1:8080 sẽ kết thúc trên socket 192.168.0.1:8080, được mở bằng quy trình sshd;

2. Quá trình sshd sau khi nhận được gói, theo quy tắc dịch thuật, sẽ ghi lại địa chỉ đích và cổng từ 192.168.0.1:8080 thành 127.0.0.1:80 và gửi nó trong phiên SSH tới bên khởi tạo 2.2. 2.2;

3. Quá trình ssh trên máy tính xách tay của Alex, sau khi nhận được gói và xem địa chỉ đích của nó, sẽ ghi lại địa chỉ người gửi từ 192.168.0.200 vào địa chỉ loopback của nó và gửi nó đến socket cục bộ 127.0.0.1:80, được mở bởi apache quá trình.

Như bạn có thể thấy, các quy tắc phát sóng rất đơn giản. Máy chủ mở ổ cắm cho đường hầm sẽ dịch địa chỉ đích và cổng theo quy tắc dịch thuật. Máy chủ ở phía đối diện của đường hầm thay đổi địa chỉ nguồn và cổng theo bảng định tuyến của nó. Trước hết cần có bảng định tuyến để gửi gói tin tới bên phải và thứ hai, để thay thế địa chỉ nguồn bằng địa chỉ của giao diện mà gói sẽ được gửi từ đó.

Một lưu ý quan trọng mà tôi để lại ở cuối bài viết.

Nếu khi mở một điểm vào đường hầm, localhost được sử dụng thay vì địa chỉ của giao diện thực thì có thể bỏ qua địa chỉ này, do đó rút ngắn lệnh bằng

alex@Alex-PC:~$ ssh -L 127.0.0.1:8080:192.0.0.1:80 [email được bảo vệ]

trước

alex@Alex-PC:~ssh -L

8080:192.0.0.1:80 [email được bảo vệ]

Cái này tính năng quan trọng cú pháp sẽ hữu ích cho chúng ta trong ví dụ sau.

Đường hầm đôi

Chúng ta hãy nhìn vào một chút nữa ví dụ phức tạp. Người dùng SQL-Tester nằm phía sau NAT cần truy cập cơ sở dữ liệu trên máy chủ SQL, cũng đứng sau NAT. SQL-Tester không thể thiết lập kết nối trực tiếp đến máy chủ vì không có bản dịch tương ứng trong mạng máy chủ NAT. Tuy nhiên, từ cả hai máy chủ, bạn có thể thiết lập phiên SSH với máy chủ trung gian 3.3.3.3.

Từ máy chủ SQL, chúng tôi thiết lập kết nối SSH đến máy chủ 3.3.3.3 và mở cổng 13306 trên giao diện loopback của máy chủ 3.3.3.3, cổng này đề cập đến dịch vụ SQL cục bộ chạy trên ổ cắm cục bộ 127.0.0.1:3306 của máy chủ SQL :

dbuser@SQL-server:~$ ssh -R 13306:127.0.0.1:3306

[email được bảo vệ]

Bây giờ, từ máy chủ máy khách SQL-Tester, chúng tôi thiết lập kết nối với 3.3.3.3 và mở cổng 3306 trên giao diện loopback máy khách, do đó, tham chiếu đến 127.0.0.1:13306 trên máy chủ 3.3.3.3,... đề cập đến 127.0.0.1:3306 trên máy chủ SQL. Nó đơn giản.

thử nghiệm@SQL-Tester:~$ ssh -L

3306:127.0.0.1:13306 [email được bảo vệ]

Đường hầm động - SSH làm proxy vớ

Không giống như các đường hầm có chỉ dẫn rõ ràng về quy tắc dịch thuật, đường hầm động hoạt động theo nguyên tắc hoàn toàn khác. Thay vì chỉ định ánh xạ cổng: địa chỉ một-một cho từng địa chỉ đích và cổng, bạn mở một ổ cắm ở phía cục bộ của phiên SSH, biến máy chủ của bạn thành máy chủ proxy SOCKS4/SOCKS5. Chúng ta hãy xem

Ví dụ:

Tạo ổ cắm đường hầm động 127.0.0.1:5555 trên máy chủ máy khách bên trong phiên SSH tới máy chủ 2.2.2.2

user@client:~$ ssh -D 5555 [email được bảo vệ]

Kiểm tra xem cổng có mở không

user@client:~$ sudo lsof -nPi | grep 5555

7284 người dùng 7u

IPv4 0x74fcb9e03a5ef5b1 0t0 TCP 127.0.0.1:5555 (LẮNG NGHE)

Và chúng tôi đăng ký proxy trong cài đặt của trình duyệt hoặc bất kỳ phần mềm nào khác hỗ trợ proxy SOCKS.

Bây giờ tất cả lưu lượng truy cập trình duyệt sẽ đi qua proxy SOCKS bên trong kết nối SSH được mã hóa giữa máy chủ 1.1.1.1 và 2.2.2.2.

Cách sử dụng SSH trong Microsoft Windows?

Sau khi đọc bài viết, bạn có thể quyết định rằng tất cả những lợi ích Đường hầm SSH chỉ có sẵn cho người dùng hệ thống giống Unix. Tuy nhiên, không phải vậy. Hầu như tất cả các máy khách đầu cuối dành cho Windows chạy trên giao thức SSH đều có hỗ trợ đường hầm.

Hiện tại, người ta có thể sử dụng Windows không chỉ như Máy khách SSH. Có thể cài đặt máy chủ SSH trên Windows.

Khi nào nên sử dụng đường hầm SSH?

Tất nhiên, để tạo đường hầm vĩnh viễn trên máy chủ chiến đấu, bạn cần sử dụng một công cụ đặc biệt. phần mềm. Nếu không có giải pháp nhanh chóng nhiệm vụ chuyển tiếp cổng, khắc phục sự cố, truy cập từ xa nhanh chóng và các giải pháp nói chung nhiệm vụ cụ thể“ở đây và bây giờ” việc sử dụng đường hầm SSH thường là một trợ giúp hữu ích.

Với sự trợ giúp của họ, bạn có thể xây dựng toàn bộ mạng, đường hầm bên trong đường hầm và kết hợp các loại đường hầm. Điều này có thể cho phép bạn nhanh chóng có được quyền truy cập vào những nơi mà dường như không thể đến được.

SSH-tunneling có thể giúp ích không chỉ trong những vấn đề cần truyền lưu lượng không được mã hóa qua kết nối được mã hóa mà còn khi bạn không có quyền truy cập vào tài nguyên trên mạng nhưng cần có quyền truy cập.

Hãy xem xét việc tạo và thiết lập một số tùy chọn.

Và như vậy, chúng ta có một máy chủ, hãy gọi nó là máy chủ-1. Đối với anh ấy chúng tôi có toàn quyền truy cập chỉ bởi SSH- nhưng chúng ta cần mở tomcat, hoạt động trên cổng 8082 - cổng mà họ không thể cho chúng tôi đi qua.

Chúng tôi sẽ xem xét tùy chọn với cài đặt các cửa sổ Và bột bả.

Khai mạc SSH-kết nối đến đến máy chủ mong muốn, hãy đăng nhập.

Chúng tôi chỉ định các tham số sau:

Cổng nguồn: bất kỳ cổng nào chưa được sử dụng trên hệ thống của bạn;
Cổng đích: 127.0.0.1:8082

Nhấp chuột Thêm vào, Sau đó Áp dụng.

Chuyển đến cài đặt trình duyệt và đặt tham số proxy:

Bây giờ tất cả những gì còn lại là mở trang http://localhost:3002 trong trình duyệt - và chúng ta sẽ đến trang tomcat trên máy chủ máy chủ-1.

Nếu đường hầm không hoạt động, hãy kiểm tra trên máy chủ xem tính năng chuyển tiếp gói có được bật hay không. Trong tệp /etc/ssh/sshd_config, tìm và bỏ ghi chú dòng:

AllowTcpForwarding có

Và khởi động lại SSHd:

# service sshd restart Đang dừng sshd: [ OK ] Đang khởi động sshd: [ OK ]

Một ví dụ khác - chúng ta có cùng một ví dụ máy chủ bên ngoài, từ đó có quyền truy cập bình thường vào bất kỳ tài nguyên nào trên Internet. Nhưng từ nơi làm việc, chúng tôi có quyền truy cập và bị đóng cửa.

Chúng tôi thực hiện các hành động tương tự, nhưng có một chút khác biệt. Cài đặt trong bột bả:

Cổng nguồn - giữ nguyên nhưng thay vào đó Địa phương- chọn Năng động. Nhấp chuột Thêm vào, Áp dụng.

Hãy đi tới cài đặt trình duyệt:

Xin lưu ý rằng loại proxy ở đây không phải là HTTP mà là SOCKS.

Tận hưởng quyền truy cập vào các trang web yêu thích của bạn.

Và một trường hợp thú vị hơn.

Chúng tôi có cùng một thứ máy chủ-1. Ngoài ra còn có server thứ 2, tạm gọi là vậy máy chủ-2. Ngoài ra chúng tôi còn có máy các cửa sổ, cần được cấp quyền truy cập vào tài nguyên ĐộiThành Phố trên máy chủ máy chủ-1 trên cổng 8111. Trong trường hợp này, truy cập từ các cửa sổ-chúng tôi chỉ có máy cho máy chủ máy chủ-2 và chỉ trên cổng 22.

Để bắt đầu, chúng tôi nâng cao đường hầm giữa máy chủ-1 Và máy chủ-2. Chúng tôi thực hiện trên máy chủ-1:

$ ssh -f -N -R Host-2:8082:localhost:8111 tên người dùng@host-2

Vì vậy, chúng tôi mở một đường hầm cục bộ (trên máy chủ-1) nhìn vào cổng 8111, còn bên kia là máy máy chủ-2, trên cổng 8082 mở và chờ kết nối đến. Khi nhận các gói trên cổng 8082 (và chỉ qua giao diện lo0! điều này rất quan trọng) - nó sẽ chuyển hướng chúng đến máy máy chủ-1 cổng 8111.

Về giao diện lo0. Khi cài đặt SSH-tunnel, ngay cả khi chỉ định IP bên ngoài của máy - kết nối chỉ được nâng lên từ localhost, tức là. 127.0.0.1 .

Chúng ta hãy nhìn vào máy chủ-2:

$ netstat -anp | grep 8082 tcp 0 0 127.0.0.1:8082 0.0.0.0:* NGHE -

Để thay đổi điều này, bạn cần chỉnh sửa tệp cấu hình daemon sshd - /etc/ssh/sshd_config và thay đổi tham số:

#GatewayPorts không

Nhưng chúng ta sẽ không làm điều đó bây giờ, đây chỉ là một ghi chú.

Tiếp tục đi. Hãy chuyển sang thiết lập bột bả Trên của chúng tôi các cửa sổ-xe hơi. Ở đây mọi thứ đều đơn giản - chúng tôi sử dụng ví dụ 1 từ bài viết này, chỉ cần thay đổi cổng thành cổng mong muốn (nhân tiện, nó ở đó trong ảnh chụp màn hình). Hãy kết nối bột bảđến chủ nhà máy chủ-2, cài đặt đường hầm. Thay đổi cài đặt trong trình duyệt Ủy quyền- và chúng tôi nhận được những gì chúng tôi cần, chỉ định địa chỉ http://localhost:3002:

SSH khá nhạy cảm với việc mất gói, do đó các đường hầm có thể bị loại bỏ thường xuyên.

Để tránh điều này, bạn có thể thử các tham số trong tệp cài đặt sshd - /etc/ssh/sshd_config:

#TCPKeepAlive vâng #ServerAliveInterval #ServerAliveCountMax

Hoặc sử dụng tiện ích autossh.

Bất kỳ quản trị viên hệ thống nào cũng phải liên tục làm việc từ xa, nhưng có những trường hợp bạn cần kết nối gấp với các nút mạng nội bộ, quyền truy cập được đóng lại từ bên ngoài. Thật tốt nếu có quyền truy cập vào các nút khác của một mạng nhất định, nhưng điều đó xảy ra là quyền truy cập từ mạng lưới toàn cầu hoàn toàn không, trong những trường hợp này, họ thường sử dụng TeamViewer hoặc phần mềm tương tự, nhưng nếu có thể kết nối với mạng đó thông qua SSH hoặc thiết lập kết nối với máy chủ SSH trung gian, thì bạn có thể nhanh chóng và dễ dàng tổ chức quyền truy cập mà không cần đến người thứ ba- phần mềm tiệc tùng

Rất thường xuyên, khi nói đến quyền truy cập từ xa vào các mạng có mức độ bảo mật thấp, điều đầu tiên bạn nghĩ đến là VPN, tuy nhiên, vì mục đích kết nối quản trị, không phải lúc nào cũng nên cài đặt VPN, đặc biệt nếu Chúng ta đang nói về về gia công phần mềm hoặc "quản trị viên sắp tới". Ngoài ra, điều kiện liên lạc không phải lúc nào cũng cho phép kết nối VPN ổn định, đặc biệt nếu bạn phải sử dụng mạng di động.

Hơn nữa, ở hầu hết mọi mạng, bạn đều có thể tìm thấy một thiết bị hoặc máy chủ có thể truy cập qua SSH hoặc có một máy chủ trung gian như vậy, chẳng hạn như VPS trên mạng toàn cầu. Trong trường hợp này, một giải pháp tuyệt vời sẽ là đường hầm SSH, cho phép bạn dễ dàng tổ chức các kênh liên lạc an toàn, bao gồm cả thông qua các nút trung gian, giúp loại bỏ vấn đề có địa chỉ IP chuyên dụng.

Nói đúng ra, đường hầm SSH không phải là đường hầm chính thức và cái tên này nên được coi là một cái tên ổn định đã phát triển trong môi trường chuyên nghiệp. Tên chính thức của công nghệ này là Chuyển tiếp cổng SSH là một tính năng tùy chọn của giao thức SSH cho phép bạn chuyển gói TCP từ một bên của kết nối SSH sang bên kia và trong quá trình chuyển, hãy dịch tiêu đề IP theo quy tắc định trước.

Ngoài ra, không giống như các đường hầm VPN, cho phép mọi lưu lượng truy cập được truyền theo bất kỳ hướng nào, đường hầm SSH có một điểm vào và chỉ có thể hoạt động với các gói TCP. Trên thực tế, điều này tương tự như chuyển tiếp cổng nhất (đó là điều tên chính thức), chỉ qua giao thức SSH.

Hãy xem xét hoạt động của đường hầm SSH chi tiết hơn. Ví dụ: hãy lấy trường hợp cổ điển về việc cung cấp quyền truy cập vào một số máy chủ từ xa thông qua giao thức RDP.

Giả sử có một máy chủ mục tiêu có địa chỉ 192.168.0.105 trên mạng từ xa, nhưng không có quyền truy cập vào nó từ mạng bên ngoài, thiết bị duy nhất mà chúng ta có thể kết nối là bộ định tuyến có địa chỉ 192.168.0.1. chúng ta có thể thiết lập kết nối SSH.

Chúng ta hãy tập trung vào rất tâm điểm: đặt tất cả các tham số đường hầm SSH người khởi xướng kết nối, hay còn gọi là Máy khách SSH, đầu thứ hai của đường hầm luôn là máy chủ mà chúng tôi kết nối, hay còn gọi là máy chủ SSH. TRONG trong ngữ cảnh này Máy khách và máy chủ nên được hiểu thuần túy là các mặt của kết nối, ví dụ: máy chủ VPS có thể hoạt động như một máy khách SSH và máy tính xách tay của quản trị viên có thể hoạt động như một máy chủ SSH.

Điểm vào có thể được đặt tại dù sao kết nối, một ổ cắm TCP được mở ở đó với thông số quy định, sẽ chấp nhận các kết nối đến. Điểm thoát không thể chấp nhận kết nối mà chỉ định tuyến các gói theo quy tắc dịch.

Chúng ta hãy nhìn vào sơ đồ trên. Chúng tôi đã thiết lập một đường hầm SSH từ máy cục bộ đến bộ định tuyến từ xa, chỉ định cục bộ điểm vào 127.0.0.1:3389 Và quy tắc phát sóng 192.168.0.105:3389. Một lần nữa, chúng tôi thu hút sự chú ý của bạn đến thực tế là quy tắc dịch thuật không chỉ ra điểm thoát mà xác định nút mà các gói sẽ được gửi đến khi thoát khỏi đường hầm. Nếu bạn chỉ định Địa chỉ không hợp lệ, hoặc nút sẽ không chấp nhận kết nối, đường hầm SSH sẽ được thiết lập nhưng sẽ không có quyền truy cập vào nút đích.

Theo điểm vào được chỉ định, dịch vụ SSH sẽ tạo một ổ cắm TCP cục bộ sẽ lắng nghe các kết nối trên cổng 3389. Do đó, trong cửa sổ kết nối RDP, chúng tôi chỉ định là đích localhost hoặc 127.0.0.1 , Máy khách RDP mở một cổng động và gửi một gói có địa chỉ đích 127.0.0.1:3389 và địa chỉ nguồn 127.0.0.1:61256 , anh ta không biết gì về đích thực sự của người nhận gói.

Từ điểm vào Gói hiện tại sẽ được gửi sang phía bên kia của đường hầm SSH và địa chỉ đích theo quy tắc dịch sẽ được thay đổi thành 192.168.0.105:3389 , và máy chủ SSH sẽ đưa ra quyết định tiếp theo theo bảng định tuyến của chính nó, thay thế địa chỉ nguồn bằng địa chỉ của chính nó, nếu không máy chủ mục tiêu sẽ cố gắng gửi gói phản hồi đến địa chỉ cục bộ.

Do đó, máy khách RDP hoạt động với một ổ cắm cục bộ và các gói RDP không vượt ra ngoài nút này bên trong đường hầm, chúng được truyền qua giao thức SSH ở dạng được mã hóa, nhưng kết nối RDP thông thường được thiết lập giữa máy chủ SSH và máy chủ RDP trên đó. mạng 192.168.0.0 , V biểu mẫu mở. Điều này cần được tính đến khi sử dụng giao thức không an toàn, hãy nhớ chắc chắn rằng nếu một quy tắc dịch trỏ ra ngoài một nút có điểm thoát, thì kết nối đó (giữa điểm thoát và nút đích) không tự vệ thông qua SSH.

Đã hiểu một cách khái quát về cách thức hoạt động của các đường hầm SSH, hãy chuyển sang các tùy chọn thực tế để sử dụng chúng. Chúng tôi sẽ coi các hệ thống Linux thuộc dòng Debian/Ubuntu là một nền tảng, nhưng mọi thứ được nêu dưới đây, với những sửa đổi nhỏ, sẽ hợp lệ cho mọi UNIX. - hệ thống giống như

Đường hầm SSH với điểm vào cục bộ

Đường hầm Điểm vào cục bộ được sử dụng để có quyền truy cập vào các máy chủ trên mạng từ xa với khả năng thiết lập kết nối SSH đến một trong các máy chủ của nó, giả định rằng mạng từ xa có địa chỉ IP chuyên dụng.

Chúng tôi sẽ xem xét tùy chọn tương tự, kết nối RDP đến máy chủ từ xa, đường chấm màu cam trong sơ đồ biểu thị kết nối SSH an toàn và mũi tên màu xanh biểu thị kết nối TCP thông thường.

Trong phiên bản đơn giản nhất, chúng tôi chỉ cần thiết lập kết nối từ PC khách đến bộ định tuyến trên mạng từ xa, chỉ định nút đích trong quy tắc dịch:

Ssh -L 127.0.0.1:3389:192.168.0.105:3389 [email được bảo vệ]

Chìa khóa -L cho biết điểm vào được đặt cục bộ, sau đó dấu hai chấm cho biết địa chỉ và cổng của điểm vào và địa chỉ, cổng của quy tắc dịch. Điểm thoát là nút mà chúng tôi kết nối, tức là. rt.example.com.

Nếu mạng của bạn cũng có bộ định tuyến (hoặc máy chủ Linux khác), thì bạn có thể đặt nó làm điểm vào, điều này sẽ cho phép bất kỳ máy khách RDP nào từ mạng nội bộ. Về lý thuyết, để làm được điều này, bạn nên nâng một đường hầm như thế này:

Ssh -L 192.168.31.100:3389:192.168.0.105:3389 [email được bảo vệ]

Trong trường hợp này, dịch vụ SSH sẽ phải mở ổ cắm TCP trên giao diện 192.168.31.100, nhưng trên thực tế điều này sẽ không xảy ra. Điều này là do các tính năng triển khai của OpenSSH, vốn là tiêu chuẩn cho phần lớn các hệ thống giống UNIX.

Theo mặc định, OpenSSH mở một điểm vào chỉ trên giao diện cục bộ . Thật dễ dàng để xác minh điều này:

Để cung cấp quyền truy cập vào ổ cắm TCP từ các giao diện bên ngoài, bạn nên sử dụng phím -g, hoặc thêm vào tập tin cấu hình /etc/ssh/sshd_config lựa chọn:

Cổng cổng có

Tuy nhiên, sau đó socket sẽ chấp nhận các kết nối từ bất kì giao diện mạng khởi tạo:

Điều này có nghĩa là cổng 3389 sẽ được mở cho tất cả giao diện mạng, vì vậy nếu điểm vào là thiết bị biên thì bạn nên hạn chế quyền truy cập vào ổ cắm, chẳng hạn như sử dụng iptables. Ví dụ: hãy chặn truy cập từ mạng bên ngoài (giao diện eth0):

Iptables -A INPUT -i eth0 -p tcp --dport 3389 -j DROP

Vì vậy, đường hầm làm việc nên được nâng lên bằng lệnh:

Ssh -L -g 3389:192.168.0.105:3389 [email được bảo vệ]

Xin lưu ý thêm một điều: nếu điểm vào khớp với giao diện cục bộ và đối với OpenSSH thì điều này luôn như vậy thì có thể bỏ qua nó bằng cách bắt đầu lệnh ngay từ cổng điểm vào.

Chúng tôi cũng khuyên bạn nên sử dụng chìa khóa nếu có thể -g thay vì thêm tùy chọn vào tệp cấu hình, vì trong trường hợp sau Nếu quên cài đặt này, bạn có nguy cơ để lộ các dịch vụ mạng từ xa không được bảo vệ ra thế giới bên ngoài.

Đường hầm SSH với điểm vào từ xa

Ngược lại, một đường hầm có điểm vào từ xa cho phép xuất bản bất kỳ dịch vụ địa phương trên mạng từ xa, một trong những cách sử dụng phổ biến nhất là truy cập mạng mà không cần địa chỉ IP chuyên dụng, tuy nhiên, điều này yêu cầu IP "trắng" từ phía mạng của quản trị viên.

Trong tùy chọn đầu tiên, máy chủ từ xa sẽ tự thiết lập kết nối với bộ định tuyến mạng cục bộ. Điều này có thể được thực hiện bằng một lệnh đơn giản:

Ssh -R 3389:127.0.0.1:3389 [email được bảo vệ]

Phím -R chỉ định mở điểm truy cập từ phía xa của đường hầm, sau đó chúng tôi chỉ định cổng cho ổ cắm TCP và bản dịch, vì các gói đến điểm thoát phải được xử lý cục bộ nên chúng tôi cũng chỉ định giao diện cục bộ.

Người đọc chú ý sẽ nhận thấy rằng chúng ta chưa chỉ định khóa -g, Vâng, đúng vậy. Thực tế là đối với các đường hầm có điểm vào từ xa chìa khóa đã cho không áp dụng và nên sử dụng tùy chọn

Cổng cổng có

về phía máy chủ SSH.

Vì lý do an toàn, chúng tôi khuyên bạn nên sử dụng cài đặt này với chính sách mặc định DROP cho chuỗi INPUT, điều này sẽ tránh việc vô tình xuất bản trên giao diện bên ngoài dịch vụ nội bộ và tài nguyên. Trong cấu hình tối thiểu, bạn nên thêm bốn quy tắc vào đầu chuỗi INPUT:

Iptables -P ĐẦU VÀO THẢ
iptables -A INPUT -i eth0 -m trạng thái --state THÀNH LẬP, LIÊN QUAN -j CHẤP NHẬN
iptables -A INPUT -i eth1 -j CHẤP NHẬN
iptables -A INPUT -i eth0 -p tcp --dport 22 -j CHẤP NHẬN

Cái đầu tiên trong số này đặt chính sách từ chối mặc định cho các gói đến, cái thứ hai cho phép các gói đến do chính máy chủ khởi tạo (phản hồi các gói gửi đi) và cái thứ ba cho phép tất cả các kết nối từ mạng cục bộ. Cuối cùng, quy tắc thứ tư mở cổng 22 cho các kết nối SSH đến theo cách tương tự, bạn có thể mở bất kỳ cổng nào khác cho các kết nối bên ngoài.

Tùy chọn thứ hai được trình bày trong sơ đồ cung cấp rằng đường hầm SSH được nâng lên bởi các bộ định tuyến mạng, trong trường hợp này, lệnh sẽ giống như sau:

Ssh -R 3389:192.168.0.105:3389 [email được bảo vệ]

Hãy để chúng tôi một lần nữa thu hút sự chú ý của bạn đến thực tế là điểm vào của chúng tôi nằm ở phía đối diện của đường hầm, do đó, chương trình phát sóng được chỉ định cho phía của người khởi tạo đường hầm, tức là. V. trong trường hợp này Máy khách SSH thiết lập hai kết nối: một SSH với rt.example.com và RDP thứ hai với 192.168.0.105, trong khi với một đường hầm có điểm vào cục bộ, trình khởi tạo sẽ thiết lập một kết nối duy nhất với máy chủ SSH.

Đường hầm SSH đôi

Rất thường xuyên xảy ra tình huống khi bạn cần kết nối hai nút không có địa chỉ IP chuyên dụng. Trong trường hợp này, TeamViewer hoặc phần mềm tương tự của bên thứ ba thường được sử dụng, nhưng nếu bạn có máy chủ có sẵn bằng một địa chỉ IP chuyên dụng thì bạn có thể thực hiện việc đó dễ dàng hơn.

Chúng ta hãy chú ý đến sơ đồ trên. SSH cho phép bạn xây dựng toàn bộ chuỗi đường hầm, kết nối điểm vào của đường hầm tiếp theo với điểm thoát của đường hầm trước đó. Do đó, để có được một đường hầm từ PC quản trị đến máy chủ RDP, với cả hai nút có địa chỉ IP màu xám, chúng ta cần tạo hai đường hầm với một nút trung gian.

Đường hầm có điểm vào cục bộ trên PC quản trị:

Ssh -L 3389:127.0.0.1:3390 [email được bảo vệ]

Và một đường hầm có điểm vào từ xa trên máy chủ RDP:

Ssh -R 3390:127.0.0.1:3389 [email được bảo vệ]

Chúng tôi đã chỉ định cụ thể một cổng không chuẩn trên máy chủ từ xa để rõ ràng hơn và bây giờ hãy xem tất cả hoạt động như thế nào. Hãy bắt đầu với máy chủ RDP; nó tạo một đường hầm với một điểm vào từ xa, mở một ổ cắm TCP trên máy chủ trung gian sẽ chấp nhận các kết nối trên cổng 3390, chúng tôi sẽ chỉ định chính máy chủ RDP là một chương trình phát sóng - 127.0.0.1:3389, I E. tất cả các gói đến lối vào đường hầm này sẽ được gửi đến cổng địa phương 3389.

Một đường hầm có điểm vào cục bộ trên PC của quản trị viên sẽ mở một ổ cắm cục bộ trên cổng 3389, nơi máy khách RDP sẽ kết nối; dưới dạng phát sóng, chúng tôi chỉ định điểm vào của đường hầm thứ hai - 127.0.0.1:3390.

Như chúng tôi đã nói, không có hạn chế nào về số lượng đường hầm trong chuỗi, nhưng trên thực tế, nhu cầu về các đường hầm có nhiều hơn một nút trung gian khá hiếm khi xảy ra. Cần nhớ rằng với mỗi nút trung gian mới, độ tin cậy của toàn bộ mạch sẽ giảm và tốc độ cuối cùng sẽ bị giới hạn ở tốc độ của đoạn chậm nhất trên đường dẫn.

Đường hầm SSH động

Không giống như những gì đã thảo luận ở trên, đường hầm động hoạt động khác; nó mở một ổ cắm TCP cục bộ trên máy chủ, ổ cắm này có thể được sử dụng làm proxy SOCKS4/SOCKS5 để truy cập Internet thông qua máy chủ SSH từ xa. Điều này có thể hữu ích để bỏ qua một số hạn chế khi không cần cài đặt VPN chính thức ở khu vực tài phán khác và bạn không thể sử dụng proxy hoặc VPN công cộng vì lý do bảo mật.

Loại đường hầm này đặc biệt thuận tiện nếu bạn cần truy cập Internet một lần từ một nút khác. Một ví dụ đơn giản: một người bạn tốt của tôi đã mang hai chiếc iPhone hợp đồng của nhà mạng từ Hoa Kỳ đến và yêu cầu mở khóa chúng. Nỗi khó khăn hoạt động này không che giấu, nếu các điều khoản của hợp đồng không bị vi phạm thì chỉ cần truy cập trang web của nhà điều hành và điền vào đơn đăng ký để mở khóa là đủ. Nhưng vấn đề hóa ra lại là nhà điều hành T-Mobile Truy cập vào phần này Chỉ cư dân Hoa Kỳ mới có thể truy cập trang web này và các kết nối từ proxy công cộng và VPN đã bị từ chối vì không an toàn.

Đường hầm SSH động giúp giải quyết nhanh chóng vấn đề này bằng cách sử dụng VPS ở Hoa Kỳ. Để tạo một đường hầm như vậy, hãy nhập lệnh:

Ssh-D 1080 [email được bảo vệ]

Trong đó 1080 là cổng mà proxy SOCKS của chúng tôi sẽ khả dụng. Tất cả những gì còn lại là cấu hình trình duyệt để sử dụng máy chủ proxy cục bộ.

Một điểm cộng nữa phương pháp tương tự là máy chủ proxy chỉ tồn tại cục bộ trên máy chủ của bạn, không có cổng bổ sung nào trong mạng bên ngoài không cần phải mở nó và chỉ có kết nối SSH giữa máy khách và máy chủ.

Điều này cho phép bạn che giấu bản chất hoạt động Internet của mình với những người quan sát bên ngoài, điều này có thể hữu ích trên các mạng công cộng nơi có lý do chính đáng để tin rằng lưu lượng truy cập có thể bị các bên thứ ba chặn và phân tích. Trong trường hợp này, đường hầm SSH cung cấp khả năng mã hóa mạnh mẽ cho dữ liệu được truyền qua mạng không an toàn, nhưng nó yêu cầu hoàn toàn tự tinđến máy chủ mà qua đó bạn truy cập Internet.

Một vài lời về an toàn

Mặc dù điều này nằm ngoài phạm vi của bài viết nhưng chúng tôi không thể đề cập đến một tính năng có thể mang lại khá nhiều lợi ích. những bất ngờ khó chịu. Bằng cách nâng cao đường hầm SSH bằng một trong các lệnh trên, ngoài đường hầm, bạn cũng sẽ nhận được: mở bảng điều khiển trên máy chủ bạn đang kết nối. Hãy nhìn kỹ vào dòng lời mời trong ảnh chụp màn hình bên dưới.

Ở trên cùng, chúng tôi thấy lời mời từ máy chủ cục bộ và ở phía dưới, sau khi nâng đường hầm, chúng tôi thấy lời mời từ máy chủ từ xa. Điều này thuận tiện nếu bạn cần kiểm tra kênh liên lạc hoặc thực hiện cài đặt nhất định từ phía xa, nhưng trong cuộc sống hàng ngày, điều này có thể dẫn đến rắc rối nghiêm trọng nếu bạn quên hoặc không chú ý đến máy chủ mà bảng điều khiển được kết nối và thực thi các lệnh trên máy chủ từ xa dành cho nút cục bộ, đặc biệt nếu bạn kết nối với superuser quyền.

Do đó, sau khi kiểm tra chức năng của đường hầm, bạn nên khởi động nó bằng khóa chuyển -N, điều này cấm thực thi các lệnh trên máy chủ từ xa, ví dụ:

Ssh -N -L -g 3389:192.168.0.105:3389 [email được bảo vệ]

Và tất nhiên, bạn không nên sử dụng tài khoản superuser để kết nối với máy chủ; tốt nhất bạn nên tạo một tài khoản thông thường cho những mục đích này.

Đường hầm SSH trên Windows

Trong suốt bài viết, chúng tôi đã xem xét các đường hầm SSH bằng ví dụ về hệ thống Linux và Người dùng Windows người ta có thể có ấn tượng rằng những cơ hội này không dành cho họ. Nhưng điều này không đúng; có nhiều máy khách SSH dành cho Windows hỗ trợ tạo đường hầm. Chúng tôi sẽ xem xét phổ biến nhất trong số đó - PuTTY. Bạn cũng có thể chạy máy chủ SSH trong Windows, nhưng điều này đòi hỏi những trình độ nhất định và không phải lúc nào cũng có thể đạt được. hoạt động ổn định, vì vậy chúng tôi sẽ không xem xét tùy chọn này.

Hãy mở PuTTY và ở phía bên trái của cây đi tới Kết nối - SSH - Đường hầm:

Cửa sổ sau sẽ mở ra trước mắt chúng ta, các cài đặt chính của đường hầm được tập trung ở phía dưới và chúng tôi đã đánh dấu chúng bằng khung màu đỏ. Cổng nguồn- nhằm mục đích chỉ ra cổng của điểm vào, cổng này luôn nằm trên giao diện cục bộ (127.0.0.1). Điểm đến- phát sóng, tức là nơi các gói sẽ được gửi từ điểm thoát. Công tắc vô tuyến Cục bộ - Từ xa - Độngđặt loại đường hầm và tương tự như các khóa -L,-R Và -D.

Sau khi bạn đã điền vào tất cả các trường bắt buộc, bạn có thể thêm đường hầm bằng nút Thêm vào. Để cho phép các máy chủ bên ngoài truy cập vào ổ cắm điểm vào cục bộ, hãy chọn hộp Cổng cục bộ chấp nhận kết nối từ các máy chủ khác. Trong trường hợp này, bạn cũng nên hạn chế quyền truy cập vào mở cổng có nghĩa Tường lửa Windows hoặc thiết bị chống sét lan truyền của bên thứ ba.

Máy chủ mà chúng tôi kết nối được chỉ định trong một phần khác - Phiên họp, quen thuộc với bất kỳ ai đã từng sử dụng PuTTY, nơi bạn có thể lưu các tham số phiên để sử dụng sau này.

Như bạn có thể thấy, SSH mang lại cho quản trị viên sự linh hoạt và công cụ đắc lựcđể truy cập từ xa an toàn mà không cần mở cổng hoặc tạo kênh VPN. Chúng tôi hy vọng rằng vật liệu này sẽ hữu ích cho bạn và sẽ cho phép bạn thành thạo các khả năng mới của các công cụ tưởng chừng như quen thuộc.

• thẻ:

“Nếu chúng ta nhìn thấy ánh sáng ở cuối đường hầm thì đó là ánh sáng của một đoàn tàu đang đến gần” (Robert Lowell)

Vâng, một câu trích dẫn hay nữa. Bài viết này nói về các đường hầm SSH, hay như tôi thích gọi chúng là "VPN của người nghèo". Trái ngược với niềm tin phổ biến của các quản trị viên hệ thống, những đường hầm này có thể rất hữu ích cho cả chuyên gia kỹ thuật và người dùng thông thường. Tôi nói "trái với niềm tin phổ biến" bởi vì các đường hầm đảo ngược và đường hầm có lưu lượng HTTP bên trong có thể vượt qua tường lửa và bộ lọc nội dung. Nhưng bài viết này không nói về cách vi phạm chính sách sử dụng Internet của công ty mà là về cách làm cho cuộc sống của bạn dễ dàng hơn một chút bằng cách sử dụng đường hầm SSH.

Vậy tại sao lại sử dụng đường hầm SSH thay vì VPN? Trên thực tế, tôi sử dụng cả hai ở nhà. Nếu bạn đã đọc các bài viết của tôi trên jaysonbroughton.com thì bạn biết rằng tôi sử dụng OpenVPN với xác thực ba bước (đăng nhập, chứng chỉ và mật khẩu một lần). Nhưng điều gì sẽ xảy ra nếu tôi muốn kiểm tra một trong các máy chủ của mình ở nhà bằng thiết bị Android hoặc máy tính mà tôi không có quyền quản trị viên (ứng dụng khách OpenVPN của tôi cần những quyền đó) hoặc kết nối qua VNC với máy tính xách tay của vợ tôi để giải quyết vấn đề của cô ấy? trong trường hợp này tôi thay thế sử dụng VPN trên SSH.

Ở đây tôi sẽ chỉ cung cấp cho bạn những kiến ​​thức cơ bản: Tôi sẽ cho bạn biết cách tạo đường hầm, giải thích cú pháp lệnh, đưa ra ví dụ về đường hầm ngược và lý do sử dụng từng đường hầm. Tôi sẽ chạm nhanh vào tệp ssh_config; nó sẽ được thảo luận chi tiết hơn trong tương lai.

Vậy chúng ta sẽ làm việc với cái gì? Tôi đang sử dụng Debian trong môi trường ảo nên trải nghiệm của bạn có thể khác với trải nghiệm của tôi. Trong trường hợp này, tôi đã sử dụng OpenSSH_5.3p1 làm máy chủ và nhiều ứng dụng khách OpenSSH phiên bản 5. Trước khi đi sâu vào các đường hầm, tôi muốn nói điều này: nếu bạn muốn sử dụng đường hầm SSH để mã hóa HTTP hoặc đảo ngược đường hầm SSH để vượt qua tường lửa của công ty, hãy đảm bảo rằng bạn không vi phạm bất kỳ chính sách nào của công ty bạn. Không cần phải nói, quản trị viên hệ thống của bạn sẽ bắt đầu săn lùng bạn ngay khi họ phát hiện ra những thủ đoạn như vậy; Bản thân là một quản trị viên hệ thống, tôi cảm thấy vui mừng khôn tả khi bắt được những cá nhân như vậy. Qua ít nhất, cảnh báo họ để họ không bị bất ngờ. LinuxJournal.com và tôi không chịu bất kỳ trách nhiệm nào về việc bạn vi phạm chính sách công ty của mình :-) Bây giờ chúng ta hãy bắt tay vào công việc.

Tạo một đường hầm SSH khá đơn giản. Nhưng quyết định phải làm gì với nó có thể khó khăn hơn một chút. Vì vậy, tôi sẽ đưa ra một vài ví dụ trước khi đi vào chi tiết. Tôi đã từng đi du lịch một chút - đây là nơi tôi làm việc trước đây và trước khi tôi có con. Trong chuyến du lịch của mình, tôi đã ở trong một số khách sạn kỳ lạ nhất (tôi chắc chắn rằng bạn quen thuộc với chúng) có những điểm phát sóng không dây thậm chí còn kỳ lạ hơn. Bạn có muốn kết nối với điểm truy cập trong khách sạn có SSID sai chính tả không? Hoặc tại sân bay, nơi bạn tìm thấy nhiều điểm mở cùng một lúc? Nếu tôi không ở nhà, tôi sẽ tạo đường hầm lưu lượng HTTP giữa thiết bị Android (đã root) và máy chủ tại nhà của mình. Nếu tôi đang làm việc trên máy tính xách tay, tôi sẽ mở một đường hầm SSH và gửi lưu lượng HTTP qua Socks5 để tất cả đều được mã hóa bằng SSH. tôi không tin điểm mở truy cập nhiều nhất có thể. Tôi nên thêm gì nữa? Tôi đã phải "bọc" lưu lượng SMTP vào các đường hầm khi tôi đến những nơi mà các gói SMTP gửi đi bị chặn. Tôi đã phải làm điều tương tự với POP3, gần đây tôi đã chuyển sang IMAPS. Các ví dụ khác về đường hầm SSH bao gồm chuyển tiếp ứng dụng X11 và phiên VNC. Tôi cũng đã đề cập đến đường hầm quay trở lại trước đó. Chúng là... à, bạn hiểu đấy - những đường hầm nhằm vào mặt trái. Trong trường hợp này, bạn đang kết nối từ một nơi không có máy chủ SSH, đến máy chủ SSH bên ngoài. Sau đó, bằng cách đăng ký trên máy chủ này, bao gồm cả cục bộ, bạn có thể khôi phục kết nối này. Bạn nói cái này có ích gì? Ví dụ: máy chủ VPN của công ty bạn đã gặp sự cố hoặc chỉ hoạt động với các máy khách VPN trên Windows, nhưng bạn hoàn toàn không muốn mang máy tính xách tay của mình về nhà để kiểm tra xem quy trình này hay quy trình kia có hoạt động hay không. Khi về đến nhà, bạn có thể lắp đặt đường hầm quay lại. Trong trường hợp này, bạn nên kết nối từ máy chủ "X" với xe nhà. Về đến nhà, bạn khôi phục kết nối đến máy chủ X, nhờ đó vượt qua tường lửa hoặc VPN và kiểm tra hoạt động của quy trình mà không cần kết nối qua VPN. Tôi rất hiếm khi làm điều này, bởi vì, theo ý kiến ​​​​của tôi, việc kết nối với máy chủ vượt qua tường lửa hoặc VPN là “kung fu tồi” và chỉ nên được sử dụng như là phương sách cuối cùng.

Như vậy, bạn đã có một vài ví dụ về đường hầm SSH, bây giờ hãy xem nó được thực hiện như thế nào.

Trước khi đi sâu vào máy khách, hãy chỉnh sửa tệp sshd_config trên máy chủ một chút. Tôi thường thực hiện một số thay đổi trong /etc/ssh/sshd_config. Nhưng đừng quên làm điều đó trước khi bạn bắt đầu chỉnh sửa bản sao lưu trong trường hợp có sự cố xảy ra.

Cp /etc/ssh/sshd_config /etc/ssh/sshd_config.orig # Sử dụng giao thức SSH phiên bản 2 Giao thức 2 # Kích hoạt chế độ Phân tách đặc quyền để bảo mật cao hơn UsePrivilegeSeparation có # Cấm đăng nhập bằng root PermitRootLogin không # Cấm mật khẩu trống PermitEmptyPasswords không # Kích hoạt chuyển hướng X11 X11Chuyển tiếp có X11DisplayOffset 10 # Tôi không thể chịu được tin nhắn Motd PrintMotd không # Nó sống động nhất! TCPKeepAlive vâng

Đừng quên rằng nếu bạn thực hiện bất kỳ thay đổi nào đối với sshd_config, bạn sẽ cần khởi động lại dịch vụ sshd để những thay đổi đó có hiệu lực.

Bây giờ chúng ta hãy chuyển sang các phím. Không, không, không phải những chiếc chìa khóa mà bố bạn đã lấy đi khi bạn đâm xe của mẹ bạn, mà là những chiếc chìa khóa dòng lệnh SSH.

Một đường hầm SSH điển hình không có chuyển hướng X trông giống như thế này:

Suỵt -N -p 22 [email được bảo vệ]-L 2110:localhost:110

Ở đây các phím có ý nghĩa như sau:

N - không thực thi lệnh trên máy từ xa
-p 22 - kết nối với cổng ngoài 22. Tôi thường sử dụng một cổng bên ngoài khác để loại bỏ các cuộc tấn công của hacker trên máy chủ SSH của mình
[email được bảo vệ]- tên người dùng@servername (hoặc địa chỉ IP)
-L 2110:localhost:110 - thông tin về liên kết cổng. Có nghĩa như sau: client_port:server_name:server_port. Trong ví dụ này, chúng tôi chuyển hướng cổng máy chủ 110 sang cổng 2110 trên máy của bạn

Muốn có thêm một số ví dụ?

Chuyển tiếp POP3 và SMTP qua SSH:

Ssh -N -p 2022 [email được bảo vệ]-L 2110:localhost:110 -L 2025:localhost:25

Chuyển tiếp Google Talk thông qua SSH (công tắc -g cho phép các máy từ xa kết nối với các cổng cục bộ được chuyển tiếp):

Ssh -g -p 2022 -N [email được bảo vệ] 5223:talk.google.com:5223

Hầu hết mọi thứ được truyền đi dưới dạng văn bản thô, có thể được bảo mật bằng đường hầm SSH

Mã hóa lưu lượng HTTP

Một điều nữa rõ ràng mà không cần những từ không cần thiết. Nhưng nếu công ty của bạn có bất kỳ chính sách CNTT nào, hãy kiểm tra xem bạn có vi phạm chúng không. Tôi cho phép lưu lượng HTTP qua SSH trong trường hợp tôi không tin cậy điểm truy cập. Trên Android tôi sử dụng ứng dụng SSHTunnel và trên máy tính xách tay tôi sử dụng lệnh này:

Ssh-D 5222 [email được bảo vệ]-N

Sau khi kết nối, hãy định cấu hình trình duyệt của bạn hoặc chương trình khác có thể sử dụng proxy cho localhost:5222. Bằng cách này, chuyển tiếp cổng động sẽ được tạo và tất cả lưu lượng truy cập sẽ đi qua máy chủ SSH, đồng thời được mã hóa và bỏ qua việc lọc nội dung

Chuyển hướng phiên X và VNC

Ssh -X -p 2022 [email được bảo vệ]

Bạn đã đoán được rồi, -X chuyển tiếp X. Nhưng lưu ý rằng điều này chỉ hoạt động trên các máy khách Linux. Nếu bạn đột nhiên thấy mình đang làm việc trên Microsoft Windows và cần một đường hầm SSH, chỉ cần cài đặt gói Cygwin/X (http://x.cygwin.com/). Cá nhân tôi chưa thử nó, nhưng theo tôi hiểu, nó cung cấp khả năng chạy ứng dụng X từ xa khi ở trong Windows.

Hãy cẩn thận khi chuyển tiếp các phiên VNC. Nếu máy khách mà bạn đang kết nối đường hầm đang chạy máy chủ VNC trên cổng 5900, hãy đảm bảo rằng bạn không chỉ định cổng này là cổng chuyển tiếp, nếu không bạn sẽ kết nối với chính mình. Nhìn chung, VNC được chuyển tiếp giống như bất kỳ dịch vụ nào khác:

Ssh -p 2022 [email được bảo vệ]-L 5900:localhost:5900

Trong ví dụ này, bạn kết nối qua SSH với cổng ngoài 2022 của máy chủ mylinuxserver.com với tư cách là người dùng bob. Cảng địa phương 5900 được chuyển tiếp tới cổng 5900 trên máy chủ. Sau khi kết nối được thiết lập, bạn có thể mở ứng dụng khách VNC của mình và trỏ nó tới localhost:0 để kết nối với máy từ xa. Nếu bạn đã chuyển tiếp cổng 5901, hãy chỉ định "localhost:1", v.v.

Đảo ngược đường hầm SSH

Chà, bây giờ là lúc dành cho nhiều đường hầm SSH yêu thích của tôi. Tất nhiên, việc truy cập bất kỳ dịch vụ nào qua SSH là điều tuyệt vời và việc thúc đẩy lưu lượng truy cập web thông qua các đường hầm SSH được mã hóa cũng là điều tuyệt vời, nhưng điều ngạc nhiên thú vị nhất có thể được trải nghiệm từ các đường hầm ngược. Như tôi đã nói trước đó, bạn phải sử dụng chúng trong trường hợp bạn có máy không có máy chủ SSH và bạn cảm thấy cần truy cập vào nó sau (trong vài phút, vài giờ hoặc vài ngày), nhưng không muốn hoặc không thể sử dụng một VPN. Bạn nên kết nối với máy chủ SSH từ máy này rồi thiết lập đường hầm SSH ngược bằng cách kết nối với kết nối đó. Tại sao tôi sử dụng cái này? Thỉnh thoảng - để làm việc với máy chủ từ xa hoặc chỉ để giúp đỡ bạn bè và gia đình qua VNC thông qua SSH. Trong trường hợp sau, họ khởi chạy PuTTY với cài đặt phiên được lưu và kết nối với máy chủ SSH của tôi với tư cách là người dùng không có quyền. Sau khi tạo đường hầm, tôi có thể truy cập vào máy của họ thông qua VNC. Và thế là xong, họ không cần phải thiết lập tường lửa hay xử lý LogMeIn hoặc các trang tương tự khác.

Vì vậy, để tạo đường hầm SSH ngược, bạn cần làm như sau:

Trên máy khách:

Ssh -R remoteport:localhost:22 tên người dùng@tên máy chủ

Về phía máy chủ:

Ssh -p 2048 máy chủ cục bộ

Và đây là đường hầm trở về! Thì đấy!

Đối với những người thích trực quan hóa, người dùng Daddoo và nerdboy4200 từ kênh #linuxjournal đã chuẩn bị sơ đồ trình tự thông báo bằng gói mscgen (http://www.mcternan.me.uk/mscgen/). Có, đây là gói mở mã nguồn và nó có những khả năng đáng kinh ngạc. Tôi đã cố gắng tạo dàn ý cho bài viết này, nhưng những gì ông nội và mọt sách làm trong thời gian ngắn khiến tôi xấu hổ [sự kém cỏi của anh ấy - khoảng. Dịch.].

Phần kết luận

Được, bạn đã có nó kiến thức cơ bản trong khu vực đường hầm SSH. Đừng quên rằng đây chỉ là những điều cơ bản; trên thực tế, phạm vi của những đường hầm này chỉ bị giới hạn bởi trí tưởng tượng của bạn. Sau này mình sẽ mô tả việc thiết lập file ssh_config ở phía client để lưu thông số riêng kết nối. Nhưng nhiều hơn về điều đó vào lần tới.