Nginx ບໍ່ຕອບສະ ໜອງ ຈາກພາຍນອກກ່ອງຫ່າງໄກສອກຫຼີກ

ເວັບໄຊທ໌ຂອງຂ້ອຍ (Django / nginx / gunicorn / mysql) ທີ່ຖືກຈັດຢູ່ໃນປ່ອງຫ່າງໄກສອກຫຼີກແມ່ນເຮັດວຽກໄດ້ດີ, ຈົນກວ່າຂ້ອຍຈະຕັດສິນໃຈເລີ່ມກ່ອງຫ່າງໄກສອກຫຼີກດ້ວຍເຫດຜົນບາງຢ່າງ . ດັ່ງນັ້ນຫຼັງຈາກການເລີ່ມຕົ້ນ ໃໝ່, ຢູ່ໃນປ່ອງຫ່າງໄກສອກຫຼີກເມື່ອຂ້ອຍເວົ້າ curl -IL -H -GET my.web.address ມັນເຮັດວຽກໄດ້ດີ. ເຖິງຢ່າງໃດກໍ່ຕາມ, ເມື່ອຂ້ອຍພະຍາຍາມໃຊ້ ຄຳ ສັ່ງດຽວກັນຈາກພາຍນອກ, ມັນລາຍງານ curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL ໃນການເຊື່ອມຕໍ່ກັບ 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

Firewall (ເບິ່ງຜົນໄດ້ຮັບ 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: ພິການ

ຜົນໄດ້ຮັບຂອງ nmap ເພື່ອກວດເບິ່ງສະຖານະທີ່ Port

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;
}

server server ຂອງຂ້ອຍ 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

}

ຂ້ອຍໄດ້ກວດເບິ່ງສິດທິຂອງເອກະສານ sock ຂອງຂ້ອຍ, ພວກເຂົາ ກຳ ລັງປົ່ງຂຶ້ນ ຖືກຕ້ອງໂດຍຜູ້ໃຊ້ທີ່ກ່ຽວຂ້ອງ. ການອະນຸຍາດເອກະສານຖືກ ກຳ ນົດຢ່າງຖືກຕ້ອງ.

ເນື້ອໃນຂອງເອກະສານ 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

ໃນຂະນະດຽວກັນ, ເພື່ອຮັບປະກັນວ່າບັນຫາຂອງຂ້ອຍບໍ່ກ່ຽວຂ້ອງກັບສາມາດເຮັດໃຫ້ໃບຢັ້ງຢືນການເຂົ້າລະຫັດຂອງເຄື່ອງແມ່ຂ່າຍ, ຂ້ອຍໄດ້ປ່ຽນແປງໃນ 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) ການຕອບກັບເປົ່າຈາກເຊີບເວີ ເປັນ ຄຳ ຕອບທີ່ມີທັງຊື່ໂດເມນ, ແລະທີ່ຢູ່ IP.

ຂ້ອຍ pinged server (ທັງໃຊ້ IP, ແລະຊື່ໂດເມນ) ຈາກ laptop ຂອງຂ້ອຍ, ແລະພວກເຂົາສົ່ງ / ຮັບເອົາແພັກເກັດ. ຊື່ໂດເມນແມ່ນຖືກວາງແຜນຢ່າງຖືກຕ້ອງກັບ IP. ຂ້ອຍຍັງໄດ້ໃຊ້ມັນໂດຍໃຊ້ nslookup

ເນື່ອງຈາກຂ້ອຍໄດ້ ທຳ ງານ HTTPS, ລຸ້ນ TLS ບໍ່ ສຳ ຄັນບໍ?

ນອກຈາກນັ້ນ, ຂ້ອຍໄດ້ປິດການ ນຳ ໃຊ້ firewall ໂດຍໃຊ້ ufw. ໄດ້, ຂ້າພະເຈົ້າເບິ່ງກົດລະບຽບກ່ຽວກັບ iptables -L . ຂ້ອຍເປັນຄົນ ໃໝ່ ໃນຂົງເຂດນີ້, ແຕ່ ສຳ ລັບຂ້ອຍມັນເບິ່ງຄືວ່າຜົນໄດ້ຮັບຂອງເຄື່ອງແມ່ຂ່າຍຫ່າງໄກສອກຫຼີກຖືກອອກແບບໃຫ້ຮັບເອົາການເຊື່ອມຕໍ່ຂາເຂົ້າໃດໆ

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
0
задан 6 March 2020 в 11:50
1 ответ

Felly mae'r broblem yn sefydlog!

Y broblem oedd, rywsut, nad oedd rheolau UFW wedi diweddaru'r cofnod iptables i ganiatáu porthladdoedd 80/443.

Fe wnes i ei addasu â llaw gyda'r gorchmynion isod.

iptables -I INPUT -p tcp -m state --state NEW --dport 80 -j ACCEPT

iptables -I INPUT -p tcp -m state --state NEW --dport 443 -j ACCEPT

0
ответ дан 30 March 2020 в 01:31

Теги

Похожие вопросы