首页 > 解决方案 > 为什么即使 nginx 正在侦听并且防火墙允许 443,我也会在 ssl 上获得连接超时?

问题描述

网站https://example.org的大多数/许多访问者都会出现连接超时。一些访问者可以通过,可能是从http://example.org重定向的访问者或以前访问过该站点的访问者。

我正在尝试确定这是防火墙问题还是 nginx 配置问题。

防火墙

我使用 UFW 作为防火墙,它具有以下规则:

To                         Action      From
--                         ------      ----
SSH                        ALLOW       Anywhere                  
Nginx Full                 ALLOW       Anywhere                  
80/tcp                     ALLOW       Anywhere                  
443/tcp                    ALLOW       Anywhere                  
SSH (v6)                   ALLOW       Anywhere (v6)             
Nginx Full (v6)            ALLOW       Anywhere (v6)             
80/tcp (v6)                ALLOW       Anywhere (v6)             
443/tcp (v6)               ALLOW       Anywhere (v6) 

如果有人需要,我可以从 iptables 给出一些相关规则,但我需要一些关于寻找什么的指导。

因为sudo netstat -anop | grep LISTEN | grep ':443'我得到

tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      120907/nginx: worke  off (0.00/0/0)
tcp6       0      0 :::443                  :::*                    LISTEN      120907/nginx: worke  off (0.00/0/0)

不知道“下班”是什么意思。

nginx

它是一个服务器名称为 myservername.com 的虚拟主机,它为两个网站提供服务,example.org 和 example.com/directory。Example.org 指向一个运行 eXist-db 的 docker 容器。Example.com/directory 在 localhost:8080 上提供一个目录,该目录是从 example.com 所在的另一台服务器代理的。当我在浏览器中访问 example.com/directory 时,它在 https 上运行顺利——我认为这是因为它实际上通过 http 与 example.com 主机通信。

Example.org 和 myservername.com 都拥有由 certbot 生成的 let's encrypt 的证书。

当我从本地机器尝试 nmap 时,我得到了一些我无法解释的结果。请注意端口 80 和端口 443 之间以及 IPv4 和 IPv6 之间的差异

$ nmap -A -T4 -p443 example.org
443/tcp filtered https
$ nmap -A -T4 -p443 my.server.ip.address
443/tcp filtered https
$ nmap -A -T4 -p443 -6 my:server:ip::v6:address
443/tcp open  ssl/http nginx 1.10.3
$ nmap -A -T4 -p80 example.org
80/tcp open  http    nginx 1.10.3
$ nmap -A -T4 -p80 my.server.ip.address
80/tcp open  http    nginx 1.10.3

我的nginx.conf

user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
        worker_connections 768;
        # multi_accept on;
}

http {

        ##
        # Basic Settings
        ##

        client_max_body_size 50M;
        sendfile on;
        tcp_nopush on;
        tcp_nodelay on;
        keepalive_timeout 65;
        types_hash_max_size 2048;
        # server_tokens off;

        server_names_hash_bucket_size 64;
        # server_name_in_redirect off;

        include /etc/nginx/mime.types;
        default_type application/octet-stream;

        ##
        # SSL Settings
        ##

        ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
        ssl_prefer_server_ciphers on;

        ##
        # Logging Settings
        ##

        access_log /var/log/nginx/access.log;
        error_log /var/log/nginx/error.log;

        ##
        # Gzip Settings
        ##

        gzip on;
        gzip_disable "msie6";

        # gzip_vary on;
        # gzip_proxied any;
        # gzip_comp_level 6;
        # gzip_buffers 16 8k;
        # gzip_http_version 1.1;
        # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

        ##
        # Virtual Host Configs
        ##

        include /etc/nginx/conf.d/*.conf;
        include /etc/nginx/sites-enabled/*;
}

和我的nginx 服务器块

server {
        listen 80 default_server;
        listen [::]:80 default_server;

        server_name _ myservername.com;
        return 301 https://myservername.com$request_uri;
}

server {
        # SSL configuration
        #
        listen 443 ssl default_server;
        listen [::]:443 ssl default_server;
        
        server_name _ myservername.com;

        location / {
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_pass http://localhost:8080;
       }

        ssl_certificate /etc/letsencrypt/live/myservername.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/myservername.com/privkey.pem;
}

server {
        listen 80;
        listen [::]:80;

        server_name example.com www.example.com;

        gzip off;

        location / {
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_pass http://localhost:8080;
        }
}

server {
       listen 80;
       listen [::]:80;

       server_name example.org www.example.org;
       return 301 https://example.org$request_uri;
}

server {

        # SSL configuration
        #
        listen 443 ssl;
        listen [::]:443 ssl;
        
        server_name example.org www.example.org;

        gzip off;

        location / {
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_pass http://docker.container.ip.address:port/exist/apps/example/;
        }

        location /workshop2020/ {
                return 302 http://example.org/forum2020/;
        }


    location /exist/apps/example/ { 
            rewrite ^/exist/apps/example/(.*)$ /$1; 
    }


    ssl_certificate /etc/letsencrypt/live/example.org/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/example.org/privkey.pem; # managed by Certbot

}

非常感谢任何帮助!

标签: sslnginxiptablesexist-dbufw

解决方案


原来是防火墙,而不是 nginx。虽然我使用 ufw 作为我的防火墙,但在 iptables(但不在 ip6tables)中有一个预先存在的 INPUT DROP 规则正在捕获 https 请求。

感谢nginx 论坛上的 Francis Daly,他解释了如何识别对 443 端口的 https 请求是否到达了 nginx。

我在浏览器中禁用了 IPv6,然后尝试加载该站点。通过在尝试加载站点时查看 tcpdump,我能够看到请求发生了什么——$ sudo tcpdump -nnSX -v port 443显示了一堆带有Flags [S]. 因此,请求到达了机器,但没有握手。

将此与 nginx 访问日志进行比较,我可以看到请求根本没有到达 nginx。

所以我更仔细地检查了 iptables 并发现了违规规则。


推荐阅读