Am acasă un server LEMP care rulează Ubuntu 22.02 și o instanță cloud Oracle care rulează Ubuntu 20.04. Instanța cloud Oracle acționează ca un server Wireguard. Serverul LEMP de acasă acționează ca client Wireguard și este tunelat prin serverul Oracle pentru a obține o adresă IP care este diferită de adresa IP de acasă. Am configurat această configurare Wireguard Client/Server per acest tutorial Linuxbabe.com. Clientul wireguard este activ și rulează și poate trimite cu succes la serverul Oracle. Serverul LEMP (client Wireguard) se rezolvă cu succes la adresa IP publică a serverelor Oracle. De asemenea, am instalat openresolv pe clientul VPN și bind9 pe serverul VPN pentru a utiliza DNS-ul instanței Oracle de pe serverul LEMP (clientul Wireguard). Registratorul meu de domeniu indică DNS-ul său către același IP ca și serverul meu Oracle.Acum, încerc să instalez prosody pe serverul LEMP și nu pot obține certificate prin pluginul certbot nginx. Se pare că ceva blochează portul 80/443 și portul 80/443 nu este deschis. Când rulez (pe serverul meu LEMP) comanda:
sudo certbot -v --nginx --agree-tos --redirect --hsts --staple-ocsp --email example@example.com -d chat.example.com
Primesc următoarea eroare:
Se salvează jurnalul de depanare în /var/log/letsencrypt/letsencrypt.log
Pluginuri selectate: Authenticator nginx, Installer nginx
Solicitarea unui certificat pentru chat.example.com
Efectuarea următoarelor provocări:
Provocare http-01 pentru chat.example.com
Se așteaptă verificarea...
Provocarea nu a reușit pentru domeniul chat.example.com
Provocare http-01 pentru chat.example.com
Certbot nu a reușit să autentifice unele domenii (autentificator: nginx). Autoritatea de certificare a raportat aceste probleme:
Domeniu: chat.example.com
Tip: conexiune
Detaliu: 150.136.56.232: Se preiau http:
Sugestie: Autoritatea de certificare nu a reușit să verifice modificările temporare ale configurației nginx făcute de Certbot. Asigurați-vă că domeniile listate indică acest server nginx și că este accesibil de pe internet.
Curățarea provocărilor
Unele provocări au eșuat.
Solicitați ajutor sau căutați soluții la https:
Folosesc UFW ca firewall, iar starea mea UFW pe serverul LEMP (clientul VPN) este:
Stare: activ
La Acțiune De la
-- ------ ----
[ 1] 22/tcp PERMITERE ÎN my.local.lan.ip/24
[ 2] 43211/tcp ALLOW IN my.local.lan.ip/24
[ 3] 5222,5269/tcp PERMISĂ IN Oriunde
[ 4] 80.443/tcp PERMITERE PENTRU Oriunde
[ 5] 5222,5269/tcp (v6) PERMITERE Oriunde (v6)
[ 6] 80.443/tcp (v6) PERMITERE Oriunde (v6)
Starea mea UFW pe instanța Oracle Cloud este:
Stare: activ
La Acțiune De la
-- ------ ----
[ 1] Oriunde PERMITERE ÎN 10.10.10.0/24
[ 2] 22/tcp PERMITERE ÎN.my.home.public.ip
[ 3] 22/tcp PERMITERE ÎN.my.work.public.ip
[ 4] 5222,5269/tcp PERMITERE PENTRU Oriunde
[ 5] 51820/udp PERMITERE ÎN.my.home.public.ip
[ 6] 80.443/tcp PERMITERE PENTRU Oriunde
[ 7] 5222,5269/tcp (v6) PERMITERE Oriunde (v6)
[ 8] 80.443/tcp (v6) PERMITERE Oriunde (v6)
Portul 51820/udp este portul meu wireguard atât pentru instanța Oracle, cât și pentru serverul Lemp. De asemenea, am redirecționat adresa mea IP publică de pe instanța Oracle către clientul VPN, astfel încât clientul să poată trimite și primi pe același port public pe care îl folosește instanța Oracle. Mai jos este fișierul meu /etc/ufw/before.rules. Modificările de redirecționare a porturilor pe care le-am făcut sunt sub comentariile intitulate „Linuxbabe...”.
*filtru
:ufw-before-input - [0:0]
:ufw-before-output - [0:0]
:ufw-before-forward - [0:0]
:ufw-not-local - [0:0]
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-output -o lo -j ACCEPT
-A ufw-before-input -m conntrack --ctstate RELATED,STABLISHED -j ACCEPT
-A ufw-before-output -m conntrack --ctstate RELATED,STABLISHED -j ACCEPT
-A ufw-before-forward -m conntrack --ctstate RELATED,STABLISHED -j ACCEPT
-A ufw-before-input -m conntrack --ctstate INVALID -j ufw-logging-deny
-A ufw-before-input -m conntrack --ctstate INVALID -j DROP
-A ufw-before-input -p icmp --icmp-type destination-unreachable -j ACCEPT
-A ufw-before-input -p icmp --icmp-type time-depassed -j ACCEPT
-A ufw-before-input -p icmp --icmp-type parametru-problema -j ACCEPT
-A ufw-before-input -p icmp --icmp-type echo-request -j ACCEPT
-A ufw-before-forward -p icmp --icmp-type destinație-inaccesibil -j ACCEPT
-A ufw-before-forward -p icmp --icmp-type time-depășit -j ACCEPT
-A ufw-before-forward -p icmp --icmp-type parametru-problema -j ACCEPT
-A ufw-before-forward -p icmp --icmp-type echo-request -j ACCEPT
-A ufw-before-forward -s 10.10.10.0/24 -j ACCEPT
-A ufw-before-forward -d 10.10.10.0/24 -j ACCEPT
-A ufw-before-input -p udp --sport 67 --dport 68 -j ACCEPT
-A ufw-înainte de intrare -j ufw-nu-local
-A ufw-not-local -m addrtype --dst-type LOCAL -j RETURN
-A ufw-not-local -m addrtype --dst-type MULTICAST -j RETURN
-A ufw-not-local -m addrtype --dst-type BROADCAST -j RETURN
-A ufw-not-local -m limit --limit 3/min --limit-burst 10 -j ufw-logging-deny
-Un ufw-nu-local -j DROP
-A ufw-before-input -p udp -d 224.0.0.251 --dport 5353 -j ACCEPT
-A ufw-before-input -p udp -d 239.255.255.250 --dport 1900 -j ACCEPT
COMMIT
*nat
:ACCEPTAREA PRE-ROUTARE [0:0]
-A PREROUTING -i ens3 -d oracle.server.public.ip -p tcp --dport 80 -j DNAT --to-destination 10.10.10.2:80
-A PREROUTING -i ens3 -d oracle.server.public.ip -p tcp --dport 443 -j DNAT --to-destination 10.10.10.2:443
-A PREROUTING -i ens3 -d oracle.server.public.ip -p tcp --dport 5222 -j DNAT --to-destination 10.10.10.2:5222
-A PREROUTING -i ens3 -d oracle.server.public.ip -p tcp --dport 5269 -j DNAT --to-destination 10.10.10.2:5269
-A PREROUTING -i ens3 -d oracle.server.public.ip -p tcp --dport 5280 -j DNAT --to-destination 10.10.10.2:5280
-A PREROUTING -i ens3 -d oracle.server.public.ip -p tcp --dport 5281 -j DNAT --to-destination 10.10.10.2:5281
COMMIT
*nat
: POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.10.10.0/24 -o ens3 -j MASQUERADE
COMMIT
Ale mele /etc/nginx/nginx.conf fișierul de pe serverul LEMP (clientul wireguard) arată astfel:
utilizator www-date;
worker_proceses auto;
error_log /var/log/nginx/error.log notificare;
pid /var/run/nginx.pid;
evenimente {
conexiuni_muncitor 1024;
}
http {
includ /etc/nginx/mime.types;
aplicație de tip_default/octet-stream;
log_format principal „$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 principal;
sendfile activat;
#tcp_nopush on;
keepalive_timeout 65;
#gzip activat;
includ /etc/nginx/conf.d/*.conf;
}
Ale mele /etc/nginx/conf.d/prosody.conf fișierul de pe serverul LEMP (client VPN) arată astfel:
Server {
asculta 80;
asculta [::]:80;
nume_server chat.example.com;
rădăcină /var/www/prosody/;
locație ~ /.well-cunoscut/acme-challenge {
permite tuturor;
}
}
În cele din urmă, am activat redirecționarea IP pe serverul Oracle, decomentând linia net.ipv4.ip_forward = 1 în /etc/sysctl.conf.
După toate acestea, serverul meu LEMP pare să folosească cu succes tunelul serverului VPN al instanței Oracle, CU toate acestea, încă nu poate obține certificate de la cerbot folosind fișierul de configurare prosody.conf nginx. Din câte îmi pot da seama, cu toate cercetările pe care le-am făcut, această configurare (cel mai important, regulile de redirecționare VPN din before.rules), ar trebui să permită serverului meu LEMP să obțină certificate folosind adresa IP a instanței Oracle. Dar NU FACE AȘA!
Deci întrebarea mea este, ce trebuie să fac pentru a depana acest lucru, ce blochează portul 80/443 al serverelor mele LEMP și ce trebuie să fac pentru a obține cu succes certificate de certbot pentru prozodie folosind adresa IP publică a instanței mele Oracle?
