Điểm:0

Hai máy chủ web trên một mạng LAN, chạy apache2 và nginx tương ứng, dưới một địa chỉ IP WAN - kết nối với đúng máy chủ theo tên miền (phụ)

lá cờ in

Tôi có hai máy chủ vật lý chạy trên cùng một mạng LAN. Cả hai đều đang chạy máy chủ web; một cái chạy apache2, cái kia nginx. Mỗi người có một tên miền khác nhau, nhưng cùng một địa chỉ IP WAN bên ngoài. Giả sử bố cục mạng trông như thế này:

                mạng LAN
            20.10.30.40
      |------|----------|
      | |
   Miền 1 Miền 2
exampleABC.com (phụ.)exampleXYZ.com
      | |
      |------|----------|
                 |
            mạng LAN đơn
                 |
      |------|----------|
      | |
  Địa chỉ IP 1 Địa chỉ IP 2
192.168.0.10 192.168.0.20
      | |
      | |
  Máy chủ 1 Máy chủ 2
   apache2 nginx

Máy chủ apache2 thuộc về tôi, trong khi máy chủ nginx thì không. Cả hai máy chủ đều có miền phụ dành riêng cho từng dịch vụ mà chúng cung cấp - ví dụ: (www.)exampleABC.com cho trang web chính, cloud.exampleXYZ.com cho dịch vụ đám mây được ủy quyền ngược, media.exampleXYZ.com cho phương tiện, v.v.

Vì những lý do chưa biết, máy chủ nginx được ưu tiên khi kết nối với địa chỉ IP WAN - ban đầu, cả hai miền sẽ dẫn đến trang web chính do nginx lưu trữ, nhưng với cấu hình nginx (hiện tại) sau đây, exampleABC.com sẽ dẫn chính xác đến máy chủ apache2, trong khi exampleXYZ.com tiếp tục dẫn đến máy chủ nginx.

người phục vụ {
    nghe 80;

    # lắng nghe trên tất cả các tên miền phụ
    server_name exampleABC.com *.exampleABC.com;
    
    địa điểm / {
        # proxy trong suốt đến máy chủ khác (cổng 443)
        proxy_pass http://192.168.0.10:80;

        # đặt tiêu đề "Máy chủ" được chuyển đến máy chủ khác thành FQDN do máy khách yêu cầu để máy chủ khác biết tên miền phụ nào đang được yêu cầu
        proxy_set_header Máy chủ $http_host;
    }
}

người phục vụ {
    nghe 443 ssl;

    server_name exampleABC.com *.exampleABC.com;
    
    địa điểm / {
        proxy_pass https://192.168.0.10:443;
        proxy_set_header Máy chủ $http_host;
    }
}

Tuy nhiên, các tên miền phụ được lưu trữ bởi máy chủ apache2 (docs.exampleABC.com, v.v.) tiếp tục kết nối với nginx. (Các tên miền phụ nginx hoạt động tốt.)

Đây là một trong những cấu hình tên miền phụ mà tôi đã thiết lập qua apache2:

<Máy chủ ảo *:80>
    ServerName ft.exampleABC.com
    Chuyển hướng vĩnh viễn / https://ft.exampleABC.com/
    RewriteEngine bật
    RewriteCond %{SERVER_NAME} =ft.exampleABC.com
    RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R= Permanent]
</Máy chủ ảo>

<IfModule mod_ssl.c>
    <Máy chủ ảo _default_:443>
        # Lệnh ServerName đặt lược đồ yêu cầu, tên máy chủ và cổng
        # máy chủ sử dụng để nhận dạng chính nó. Điều này được sử dụng khi tạo
        # URL chuyển hướng. Trong bối cảnh máy chủ ảo, ServerName
        # chỉ định tên máy chủ nào phải xuất hiện trong tiêu đề Host: của yêu cầu tới
        # phù hợp với máy chủ ảo này. Đối với máy chủ ảo mặc định (tệp này)
        # giá trị không mang tính quyết định vì nó được sử dụng làm máy chủ lưu trữ cuối cùng bất kể.
        # Tuy nhiên, bạn phải đặt nó cho bất kỳ máy chủ ảo nào khác một cách rõ ràng.

        ServerName ft.exampleABC.com
        #ServerAlias ​​*.exampleABC.com

        Quản trị viên web ServerAdmin@localhost
        DocumentRoot /mnt/bên ngoài/máy chủ web/ft

        # Các mức nhật ký có sẵn: theo dõi8, ..., theo dõi1, gỡ lỗi, thông tin, thông báo, cảnh báo,
        # lỗi, chí mạng, cảnh báo, nổi lên.
        # Cũng có thể cấu hình loglevel cho cụ thể
        # mô-đun, ví dụ:
        #LogLevel thông tin ssl:cảnh báo

        Nhật ký lỗi ${APACHE_LOG_DIR}/error.log
        Nhật ký tùy chỉnh ${APACHE_LOG_DIR}/access.log kết hợp

        # Đối với hầu hết các tệp cấu hình từ conf-available/, đó là
        # được bật hoặc tắt ở cấp độ toàn cầu, có thể
        # bao gồm một dòng cho chỉ một máy chủ ảo cụ thể. ví dụ như
        # dòng sau chỉ bật cấu hình CGI cho máy chủ này
        # sau khi nó đã bị vô hiệu hóa trên toàn cầu với "a2disconf".
        #Bao gồm conf-có sẵn/phục vụ-cgi-bin.conf
        
        <Thư mục /mnt/external/webserver/ft>
            Tùy chọn Chỉ mục FollowSymLinks
            AllowOverride Không có
            Yêu cầu tất cả cấp
        </Thư mục>

        # Chuyển đổi công cụ SSL:
        # Bật/Tắt SSL cho máy chủ ảo này.
        Công cụ SSL bật

        < snipped: dòng được thêm bởi certbot >

    </Máy chủ ảo>
</IfModule>

# vim: cú pháp=apache ts=4 sw=4 sts=4 sr noet

Tôi muốn làm cho nó sao cho khi kết nối với exampleABC.com, ft.exampleABC.com, v.v., máy khách được kết nối chính xác với máy chủ apache2. tất nhiên, exampleXYZ.com và các tên miền phụ của nó vẫn phải kết nối với máy chủ nginx.

Thông tin khác:

Ban đầu, ứng dụng khách (ví dụ: trình duyệt web) không thể xác minh tính xác thực của chứng chỉ TLS của exampleABC.com.(Lưu ý rằng tôi đã thiết lập đúng chứng chỉ TLS trong apache2.) Điều này đã được giải quyết bằng cách thêm các miền apache2 của tôi vào chứng chỉ của máy chủ nginx. Mặc dù vậy, tôi không tin rằng điều này là cần thiết - chứng chỉ của tôi (trong apache2) phải được chuyển qua proxy ngược, phải không?

Nếu tôi cố gắng kết nối với máy chủ apache2 qua curl trong khi chỉ định thủ công tiêu đề Máy chủ (thông qua curl -vL -H "Máy chủ: ft.exampleABC.com" https://192.168.0.10), tôi sẽ được chuyển hướng đến trang web chính của máy chủ nginx. Tôi không chắc điều này có nghĩa là gì.

CHỈNH SỬA:

Đây là đầu ra của nginx -T, theo quản trị viên hệ thống của hệ thống nginx:

- cắt tỉa -

Ngoài ra, máy chủ nginx đang chạy trong một vùng chứa thông qua "SWAG" của LinuxServer.io.

CHỈNH SỬA:

SWAG của LinuxServer.io tải cấu hình nginx khác với cấu hình mặc định. Lệnh sau nhận đúng confs:

docker exec -it swag /usr/sbin/nginx -c /config/nginx/nginx.conf -T

Kết quả của lệnh đã nói có thể được tìm thấy tại dán này. (quá nhiều ký tự cho StackExchange)

lá cờ us
Vui lòng hiển thị cấu hình nginx đầy đủ như được hiển thị bởi lệnh `nginx -T`. Ngoài ra, vui lòng sử dụng `example.com` một cách nhất quán, trong đoạn mã hiện tại của bạn có `*.fennet.rentals`, điều này khiến việc kết nối mọi thứ trở nên khó khăn hơn.
unilock avatar
lá cờ in
@Tero Kilkanen Thật tệ, tôi đã cố gắng chỉnh sửa tất cả các đề cập đến tên miền của mình. Tôi sẽ sửa nó ngay bây giờ.
Zac67 avatar
lá cờ ru
Chạy nhiều máy chủ trên một địa chỉ IP và số cổng TCP yêu cầu proxy ngược - nginx có thể làm điều đó và ủy quyền cho máy chủ Apache. Chuyển hướng không *không* hoạt động.
unilock avatar
lá cờ in
@ Zac67 Bạn có thể nói rõ hơn không? Tôi nghĩ máy chủ nginx đang sử dụng proxy ngược thông qua "proxy_pass".
lá cờ us
Cấu hình nginx không có bất kỳ khối `server` nào cho `exampleABC.com`. Bạn có chắc đó là tệp cấu hình chính xác không?
unilock avatar
lá cờ in
@TeroKilkanen Tôi đã phát hiện ra rằng SWAG tải cấu hình nginx khác với cấu hình mặc định. Tôi đã chỉnh sửa câu hỏi của mình một cách thích hợp.
Điểm:0
lá cờ bd

Tôi là chủ sở hữu của ngôi nhà nơi đặt máy chủ của họ. Tôi không phải là chuyên gia; Tôi chỉ làm theo hướng dẫn khá tốt. Tôi có một tên miền DuckDNS và tôi chạy bộ chứa Docker cho Plex, Sonarr, SABnzbd, v.v. Tôi cũng chạy bộ chứa SWAG cho proxy ngược của mình.

Unilock đã đưa máy chủ của riêng họ vào. Nó có tên miền riêng và sử dụng apache2 cho tất cả các cấu hình máy chủ của nó. Máy chủ này, trước khi ở trên mạng của tôi, đã lắng nghe trên tất cả các cổng giống như của tôi (80, 443, v.v.).

Tôi được thông báo rằng, nếu Unilock có thể chạy các dịch vụ của họ trên các cổng không chuẩn, thì chúng tôi có thể thay đổi cài đặt của bộ định tuyến pfSense của tôi để chạy cả hai máy chủ. Tôi cũng được thông báo rằng tôi có thể thêm tên miền của máy chủ của họ vào biến EXTRA_DOMAINS của vùng chứa SWAG của tôi. Tôi đã làm điều đó và nó không giúp được gì.

Tôi cũng đã thêm một khối máy chủ bổ sung vào tệp mặc định SITE_CONF của mình. Khối bổ sung trông như thế này:

#khối máy chủ thứ hai
người phục vụ {
    nghe 443 ssl;
    nghe [::]:443 ssl;
    server_name <tên miền của mình>; # thay đổi tên miền này thành tên miền phụ của bạn
    #include /config/nginx/ssl.conf;
    client_max_body_size 0;
    địa điểm / {
    #include /config/nginx/proxy.conf;
    trình phân giải 127.0.0.11 hợp lệ=30 giây;
    #set $upstream_app 192.168.0.10;
    #set $upstream_port 443;
    #set $upstream_proto https;
    #proxy_pass $upstream_proto://$upstream_app:$upstream_port;
    proxy_pass https://192.168.0.10:443; 
    proxy_max_temp_file_size 2048m;
   }

Khối máy chủ chính của tôi là tệp mặc định. Nếu tôi cần đăng toàn bộ cấu hình, tôi sẽ; mặc dù có vẻ như unilock đã làm như vậy trên Pastebin.Sau khi tôi nhập thông tin trên, tôi có thể truy cập trang chính của unilock, nhưng tên miền phụ của họ vẫn chuyển hướng đến trang bắt đầu máy chủ nginx mặc định của tôi.

Điểm:0
lá cờ in

Điều đã làm việc là tạo một tệp mới /config/nginx/proxy-confs/exampleABC.subdomain.conf (tương đương với /etc/nginx/conf.d/exampleABC.subdomain.conf, với ví dụABC.tên miền phụ có thể thay thế bằng bất cứ thứ gì) với nội dung như sau:

người phục vụ {
    nghe 80;
    nghe [::]:80;

    server_name .exampleABC.com;
    
    địa điểm / {
        proxy_pass http://192.168.0.10:80;
        proxy_set_header Máy chủ $http_host;
    }
}

người phục vụ {
    nghe 443 ssl;
    nghe [::]:443 ssl;

    server_name .exampleABC.com;
    
    địa điểm / {
        proxy_pass https://192.168.0.10:443;
        proxy_set_header Máy chủ $http_host;
    }
}

Cấu hình nginx mà tôi đã nhập trong bài đăng gốc của mình lẽ ra phải hoạt động gần như giống hệt với cấu hình này, vì vậy tôi nghi ngờ vấn đề là do thiếu nghe [::]:<cổng>; để biết khả năng tương thích với IPv6 hoặc một số tệp cấu hình khác xung đột với tệp tôi đã tạo.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.