Socat üzerinden ev sunucusuna bağlantı için SSL sertifikası

Nextcloud'u evde bir Ahududu Pi ile çalıştırıyorum. IPv6 adresini, DynDNS sağlayıcısı spDYN.de'deki bir ana bilgisayar adında günceller. Ancak, sağlayıcım yalnızca IPv6 bağlantıları sunduğundan (IPv4 için DS-Lite kullanarak), yalnızca ana bilgisayar adına diğer IPv6 bağlantılarından doğrudan erişebiliyorum ve IPv4 ağlarından bağlanmak için IPv4-IPv6 posta haritasını kullanmam gerekiyor.

Web sitem hem IPv6 hem de IPv4 bağlantısı olan bir sunucuda barındırıldığından, bu büyük bir sorun değil, bu öğretici web sitemi barındıran sunucuda bir portmacı oluşturmak, web sitemin etki alanından belirli bir bağlantı noktasını dinamik DNS ana bilgisayar adı üzerindeki 443 numaralı bağlantı noktasına yönlendirmek. Bu mükemmel çalışıyor, ancak SSL sertifikalarında sorun yaratıyor:

RasPi'de, mükemmel çalışan ve bağlantının güvenli olduğu gösterilmiş olan dinamik DNS ana bilgisayar adı için "Şifreleyelim" sertifikası oluşturmak için certbot kullandım. Ayrıca, web sunucumda, kendi içinde çalışan portmapper için kullandığım etki alanı için benzer bir sertifika oluşturdum. Ancak, RasPi'ye erişmek için belirli, iletilmiş bağlantı noktası olan etki alanına eriştiğimde, tarayıcı etki alanımı içeren URL'yi göstermeye devam ediyor, ancak sertifikayı dinamik DNS ana bilgisayar adı için verilen RasPi'den alıyor. Sonuç olarak, kuşkusuz, "yanlış" etki alanı için sertifika verildiğinde güvenlik denetimi başarısız olur. Etki alanım için RasPi'mde bir sertifika vermeyi denedim, ancak bana "yetkisiz" olduğumu söyleyemiyor.

Bu sorunu nasıl çözebilirim? Hangi tür bir sertifikayı nerede ayarlamalıyım?

Sertifika hatalarını önlemek için, pi'nin kullanılan etki alanı ile eşleşen bir sertifika göndermesi gerekir. Buna iki yaklaşım var:

1. Her iki etki alanı için de, hem pi hem de ana sunucuya yüklenmiş bir sertifika kullanın. İstemcinin sorgusunda hangi etki alanı kullandığı önemli değildir, sertifika eşleşir.
2. Müşterinin beklediği bir sertifika seçin ve gönderin.

Seçenek 1 daha kolay ve yaygın bir uygulamadır. Google.com için sertifikaya bakın! Hem pi hem de ana sunucu yüklü aynı sertifikaya (her iki etki alanı için) sahip olacaktır. Let's Encrypt'tan böyle bir sertifika almak için, pi'nin dinamik alanı için bir web sitesi çalıştırmak ve kullanmak için ana sunucuya ihtiyacınız olacak. bir Bir kerede her iki alanın kontrolünü doğrulamak için certbot komutu. Ana sunucunun dyndns adı için olan sitenin pi'deki içeriği barındırmasına gerek yoktur - sadece orada olduğundan Let's Encrypt bu siteyi kontrol ettiğinizi doğrulayabilir (bu siteyi yenilemeler arasında bile kapatabilirsiniz).

Bunun için örnek Certbot komutu (ana web sunucusunda çalıştır)

letsencrypt certonly --webroot --csr request.csr -w /http/pisite/www -d mypi.spdyn.de -w /http/mainwebsite/www -d maindomain.de

Nerede request.csr her iki etki alanını da CN olarak kullanır ve SAN alanında iki etki alanına da sahiptir, /http/pisite/www pi'nin dinamik adına bağlı mevcut sunucuda başka bir web sitesi için oluşturacağınız yerel bir dizini ve /http/mainwebsite/www ana web sitenizin mevcut dizinidir.

Seçenek 2 daha fazla işin içine giriyor ancak 'temizleyici' bir sonuç veriyor: müşteri yazdığı alanla eşleşen bir sertifika alıyor. Ahududu pi'de, bir TLS bağlantısı açıldığında: SNI alanını (TLS bağlantısını kabul etmeden) inceleyen ve TLS bağlantısını kabul etmeden (burada TLS bağlantısını kabul etmeden) ve orada bulunan alana göre hangi bağlantıyı iletmek istediğini seçen akış modülüyle (veya eşdeğeri) nginx çalıştırın bağlantı Bu, ahududu pi'ye iletilen harici bağlantı noktasındaki ana etki alanından gelen istekleri nasıl işlemek istediğinizi seçmenizi sağlar. Onları ana web sunucusuna doğru bağlantı noktasında yapıldığı gibi gönderebilir, pi'deki başka bir bağlantı noktasına (yani Nextcloud veya başka bir şey) gönderebilirsiniz, aynı nginx örneğiyle bunları sonlandırabilirsiniz ve hangi sayfayı beğenirseniz gösterin veya bağlantıyı kapatın. Seçim senin.

İşte bu yöntem için örnek bir yapılandırma:

stream/sni-switch.conf

# Listen on 443, and on new connection:
#   if the SNI is mapped herein, handle it on this Nginx
#   else, forward the whole session to 192.168.1.80:443 (TCP passthrough, no decryption)

upstream mainwebserver {
    server 192.168.1.80:443;
}

upstream local_https {
    server 127.0.0.1:1443;
}

map $ssl_preread_server_name $name {
    default mainwebserver;

    pisite.spdyn.de     local_https;
}

server {
    listen 443;

    ssl_preread on;
    proxy_pass $name;
}

Ve nginx.conf

load_module /usr/lib/nginx/modules/ngx_stream_module.so;

stream {
    include /etc/nginx/stream/sni-switch.conf;
}

...

Bunu Apache ile yapmak için, bkz. bu . Şuna benzer bir örnek yapılandırma:

<VirtualHost *:*>
    ProxyPreserveHost On
    ProxyPass        "/" "http://192.168.1.80/"
    ProxyPassReverse "/" "http://192.168.1.80/"
    ServerName maindomain.de
</VirtualHost>