Làm cách nào để định cấu hình NGINX làm proxy ngược cho các số cổng khác nhau?


15
I have NGINX configured like this as a reverse proxy for http requests:

server {
    listen 80;
    server_name 203.0.113.2;

    proxy_set_header X-Real-IP  $remote_addr; # pass on real client IP

    location / {
        proxy_pass http://203.0.113.1:3000;
    }
}

Tôi cũng muốn proxy ssh (Cổng 22). Tôi có thể thêm một khối máy chủ khác như thế này vào cùng một tệp cấu hình không:

server {
    listen 22;
    server_name 203.0.113.2;

    proxy_set_header X-Real-IP  $remote_addr; # pass on real client IP

    location / {
        proxy_pass http://203.0.113.1:22;
    }
}

Như vậy kết quả cuối cùng là thế này:

server {
    listen 80;
    server_name 203.0.113.2;

    proxy_set_header X-Real-IP  $remote_addr; # pass on real client IP

    location / {
        proxy_pass http://203.0.113.1:3000;
    }
}
server {
    listen 22;
    server_name 203.0.113.2;

    proxy_set_header X-Real-IP  $remote_addr; # pass on real client IP

    location / {
        proxy_pass http://203.0.113.1:22;
    }
}

TIA,
Ole


2
nginxđang hoạt động như một httpproxy. Nếu bạn đặt nó thành cổng proxy ngược 22, nó sẽ không cho phép bạn chuyển lưu lượng SSH - chỉ httplưu lượng truy cập đến máy chủ SSH, điều này rõ ràng sẽ thất bại.
garethTheRed

Đi kiểm tra HAProxy .

Câu trả lời:


12

Các giao thức ssh không dựa trên HTTP, và, như vậy, không thể ủy quyền thông qua việc thường xuyên proxy_passcủangx_http_proxy_module

Tuy nhiên, gần đây, bắt đầu với nginx 1.9.0 (được phát hành ổn định với 1.10.0 vào ngày 2016-04-26), nginx đã nhận được hỗ trợ để thực hiện ủy quyền luồng TCP , điều đó có nghĩa là nếu bạn có phiên bản nginx đủ gần đây, trên thực tế, bạn có thể kết nối ssh proxy với nó (tuy nhiên, lưu ý rằng bạn sẽ không thể thêm bất cứ thứ gì như X-Real-IPkết nối được ủy quyền, vì điều này không dựa trên HTTP).

Để biết thêm thông tin và ví dụ, hãy xem:


8

Vì Nginx Phiên bản 1.9.0, NGINX hỗ trợ mô đun ngx_stream_core_module, nên nó được bật với --with-stream. Khi mô-đun truyền phát được bật, họ có thể ssh giao thức tcp proxy

stream {
    upstream ssh {
        server 192.168.1.12:22;
    }
        server {
        listen        12345;
        proxy_pass    ssh;

    }

}

https://www.nginx.com/resource/admin-guide/tcp-load-balANCE/


Đó là tất cả các tính năng tuyệt vời của nginx - nhưng IMHO thật vô dụng khi bạn muốn có proxy ngược thực sự như nginx thực hiện công việc hoàn hảo cho HTTP. Vấn đề là cách tiếp cận luồng là NAT đơn giản - vì vậy tôi muốn thực hiện nhiệm vụ đó trên bộ định tuyến biên. Những gì tôi muốn / muốn có ở đây - chính xác là tính năng được đặt làm proxy ngược HTTP. Nói cách khác, tôi chỉ có một địa chỉ IP công cộng - do đó, cổng 22 chỉ có sẵn cho một máy - nhưng nếu có một cách để phân biệt các yêu cầu trong một biểu mẫu ssh me@srv1.my.netssh me@srv2.my.net- nó sẽ rất tuyệt. Đó là giới hạn giao thức (SSH sẽ không cung cấp cho khách hàng sử dụng tên DNS)
stamster

@stamster, bạn đã có thể thực hiện gần như điều tương tự, bằng cách sử dụng các số cổng khác nhau (ví dụ: 122 cho srv1và 222 cho srv2) hoặc bằng cách sử dụng các phiên ssh lồng nhau, nơi bạn lần đầu tiên ssh vào máy chủ / IP công cộng và từ đó, ssh vào lá; ví dụ ssh user@example.org 'ssh user@192.168.5.1'.
cnst

1
Không, yêu cầu / ý tưởng là sử dụng cổng mặc định (22 hoặc bất kỳ dịch vụ nào khác ..) làm cổng đích và sau đó định tuyến lưu lượng tùy thuộc vào tên DNS hoặc hơn. Giống như tất cả chúng ta đều sử dụng nginx làm máy chủ proxy http web ngược, vì vậy mỗi tên miền nhắm mục tiêu các cổng mặc định 80, 443 và sau đó nginx định tuyến lưu lượng truy cập tùy thuộc vào quy tắc proxy. Tất nhiên, máy khách có HOSTtiêu đề để dễ dàng phân biệt trang web nào nó nhắm mục tiêu ... Các phiên SSH lồng nhau là một loại giải pháp nhưng là một mớ hỗn độn - mặc dù nó hoạt động. Tôi đã kết thúc với các cổng khác nhau trên mạng cạnh của chúng tôi - NAT cũ là giải pháp KISS và đáng tin cậy nhất.
stamster
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.