Terve
Tässä juuri yritän luoda irkkiympäristöäni uudellen, käytössä gloving bear ja weechat. Pystytän gloving bearin käyttämällä nginxiä webbiserverinä ja homma toimiikin hienosti frontendiin yhdistämiseen asti, kun syötän gloving bearin kirjautumissivulle osoitteen missä irkki pyörii sekä portin ja salasanan ja yritän kirjautua sisään mitään ei tapahdu, vaikuttaa siltä että glovin bear ei saisi yhteyttä weechatin relayhyn, mutta myöskään selainkäyttöliittymä ei anna minkäänlaista virheilmoitusta tästä. Missäköhän ongelma voisi olla, palomuurin ei pitäisi blokata yhteyksiä. Tätä ohjetta käytin nginx:n säätämiseen
Tuossa blogipostauksessa jolla olen itse saanut tuon toimimaan:
Koodi:
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
# Make sure this upstream matches your configuration in weechat!
upstream weechat {
server [::1]:9001;
}
server {
listen 443;
server_name irc.example.com;
# certs sent to the client in SERVER HELLO are concatenated in ssl_certificate
ssl_certificate /path/to/signed_cert_plus_intermediates;
ssl_certificate_key /path/to/private_key;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
# Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits
ssl_dhparam /path/to/dhparam.pem;
# Mozilla modern TLS configuration. tweak to your needs.
ssl_protocols TLSv1.1 TLSv1.2;
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK';
ssl_prefer_server_ciphers on;
# HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
add_header Strict-Transport-Security max-age=15768000;
# OCSP Stapling ---
# fetch OCSP records from URL in ssl_certificate and cache them
ssl_stapling on;
ssl_stapling_verify on;
## verify chain of trust of OCSP response using Root CA and Intermediate certs
ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;
resolver <IP DNS resolver>;
location /weechat {
proxy_pass https://weechat;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_ssl_trusted_certificate /path/to/copy/of/relay.pem;
proxy_ssl_verify off;
proxy_read_timeout 4h;
}
location / {
root /var/www/glowing-bear;
}
}
Kuten näkyy, niin jälkimmäisessä on käytetty tuota nginxin http upstream ominaisuutta.
Veikkaan, että tuon Linux wikin ohjeen ongelma voi olla se, että tuossa ohjataan liikenne tuohon weechat relay:n salaamattomana. Tuo taitaa toimia ainoastaan silloin, kun käytössä on HTTP. Kun ottaa HTTPS:n käyttöön Letsencryptin avulla kuten tuolla neuvotaan, niin se lakkaa toimimasta. Salattua HTTPS yhteyttä kun ei kai voi "upgreidata" salaamattomaksi HTTP:ksi.
Otitko HTTPS:n käyttöön kuten tuolla neuvotaan? Jos et, niin sitten tuo ylempi mutuilu ei varmaan koske sinua.
Tuossa blogipostauksessa jolla olen itse saanut tuon toimimaan:
Koodi:
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
# Make sure this upstream matches your configuration in weechat!
upstream weechat {
server [::1]:9001;
}
server {
listen 443;
server_name irc.example.com;
# certs sent to the client in SERVER HELLO are concatenated in ssl_certificate
ssl_certificate /path/to/signed_cert_plus_intermediates;
ssl_certificate_key /path/to/private_key;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
# Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits
ssl_dhparam /path/to/dhparam.pem;
# Mozilla modern TLS configuration. tweak to your needs.
ssl_protocols TLSv1.1 TLSv1.2;
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK';
ssl_prefer_server_ciphers on;
# HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
add_header Strict-Transport-Security max-age=15768000;
# OCSP Stapling ---
# fetch OCSP records from URL in ssl_certificate and cache them
ssl_stapling on;
ssl_stapling_verify on;
## verify chain of trust of OCSP response using Root CA and Intermediate certs
ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;
resolver <IP DNS resolver>;
location /weechat {
proxy_pass https://weechat;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_ssl_trusted_certificate /path/to/copy/of/relay.pem;
proxy_ssl_verify off;
proxy_read_timeout 4h;
}
location / {
root /var/www/glowing-bear;
}
}
Kuten näkyy, niin jälkimmäisessä on käytetty tuota nginxin http upstream ominaisuutta.
Veikkaan, että tuon Linux wikin ohjeen ongelma voi olla se, että tuossa ohjataan liikenne tuohon weechat relay:n salaamattomana. Tuo taitaa toimia ainoastaan silloin, kun käytössä on HTTP. Kun ottaa HTTPS:n käyttöön Letsencryptin avulla kuten tuolla neuvotaan, niin se lakkaa toimimasta. Salattua HTTPS yhteyttä kun ei kai voi "upgreidata" salaamattomaksi HTTP:ksi.
Otitko HTTPS:n käyttöön kuten tuolla neuvotaan? Jos et, niin sitten tuo ylempi mutuilu ei varmaan koske sinua.
Juu. No en nyt kyllä osaa sitten sanoa muuta, kuin että kokeile tuota ohjetta jonka laitoin. Sen avulla minulla toimii sekä glowing bear että weechat android. En nyt kyllä ihan hoksaa, että miksi tuo Linux wikin ohje ei muka toimisi.
hmmmm, tutkiskelin tcpdumpilla ja portissa 9001 jossa weechatin relay pyörii ei näy minkäänlaista liikennettä. Alkaa tuntua siltä kuin nginx ei osaisi forwardoidakkaan portin 80 liikennettä porttiin 9001?. Toisaalta sama lopputulos on havaittavissa jos yritän yhdistää suoraan porttiin 9001