Мой веб-сайт (Django / nginx / gunicorn / mysql), который размещен на удаленной коробке, работал нормально, пока я не решил перезапустить удаленную коробку по некоторым причинам. Так что после перезагрузки в удаленном окне, когда я говорю curl -IL -H -GET my.web.address, все работает нормально. Однако, когда я пытаюсь выполнить ту же команду извне, она сообщает curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to my.web.address.
Любая помощь приветствуется. Пожалуйста, найдите ниже соответствующие вещи, которые я проверил.
Я использую систему CentOS 7. Я преимущественно использовал , этот учебник
nginx прослушивает нужные порты
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 3425/nginx: master
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 3425/nginx: master
Брандмауэр (см. Результат ufw) разрешает мои порты
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
To Action From
-- ------ ----
22/tcp (SSH) ALLOW IN Anywhere
224.0.0.251 5353/udp (mDNS) ALLOW IN Anywhere
22 ALLOW IN Anywhere
80 ALLOW IN Anywhere
443 ALLOW IN Anywhere
22/tcp (SSH (v6)) ALLOW IN Anywhere (v6)
ff02::fb 5353/udp (mDNS) ALLOW IN Anywhere (v6)
22 (v6) ALLOW IN Anywhere (v6)
80 (v6) ALLOW IN Anywhere (v6)
443 (v6) ALLOW IN Anywhere (v6)
sestatus
SELinux status: disabled
Вывод nmap для проверки состояния порта
nmap -sT my.ip.address
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
111/tcp open rpcbind
443/tcp open https
3306/tcp open mysql
Содержимое nginx.conf
user nginx;
worker_processes 1;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
#tcp_nopush on;
keepalive_timeout 65;
#gzip on;
include /etc/nginx/conf.d/*.conf;
}
серверные блоки моего nginx.conf
server {
server_name my.ip.address my.web.address;
error_log /srv/www/myweb/logs/error.log;
access_log /srv/www/myweb/logs/access.log;
charset utf-8;
location /static/{
alias /srv/www/myweb/latestRelease/mywebDB/app/src/static/;
}
location /{
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://unix:/srv/www/myweb/latestRelease/mywebDB/mywebdb.sock;
}
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/my.web.address/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/my.web.address/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
if ($host = my.ip.address) {
return 301 https://$host$request_uri;
} # managed by Certbot
if ($host = my.web.address) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80;
server_name my.ip.address my.web.address;
return 404; # managed by Certbot
}
Я проверил мои права доступа к файлу носка, они правильно отображаются соответствующим пользователем. Права доступа к файлам установлены правильно.
содержимое файла gunicorn.service
[Unit]
Description=gunicorn daemon
After=network.target
[Service]
User=user
Group=nginx
WorkingDirectory=/srv/www/myweb/latestRelease/mywebDB/app/src
ExecStart=/srv/www/myweb/latestRelease/mywebDB/app/bin/gunicorn --workers 3 --bind unix:/srv/www/myweb/latestRelease/mywebDB/mywebdb.sock app.wsgi:application
[Install]
WantedBy=multi-user.target
Между тем, просто чтобы убедиться, что мои проблемы не связаны с сертификатами сервера Lets encrypt, я внес изменения в свой nginx.conf, чтобы он работал только по HTTP ,
Ниже приведены выходные данные curl -IL -GET my.domain.name, когда я запускал его на своем удаленном компьютере:
HTTP/1.1 200 OK
Server: nginx/1.17.9
Date: Fri, 06 Mar 2020 08:26:42 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 7918
Connection: keep-alive
X-Frame-Options: SAMEORIGIN
Я получаю тот же вывод, что и выше, работая с IP-адресом.
Когда я запускаю curl со своего ноутбука, я получаю curl: (52) Empty reply from server в качестве ответа как с именем домена, так и с IP-адресом.
Я пропинговал сервер (как по IP, так и по имени домена) со своего ноутбука, и они отправляли / получали пакеты. Доменное имя правильно сопоставлено с IP. Я также проверил его, используя nslookup
Поскольку я отключил HTTPS, версии TLS не имеют значения, не так ли?
Кроме того, я отключил брандмауэр, используя ufw. Я посмотрел правила iptables -L. Я новичок ie в этой области, но мне кажется, что результаты удаленного сервера предназначены для приема любых входящих соединений.
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited