[erledigt] KVM client nicht erreichbar

[letzter3]

Hallo zusammen.

Ich habe eine ehemalige VBox Installation (Odoo auf Debian8) umgewandelt und auf einem Debian 8 KVM-Wirt eingespielt.
Der Host sitzt hinter einer Fritzbox, dort sind die Ports 8069 (Odoo) und 4443 (nginx als https proxy) weitergeleitet auf die IP des KVM-Clients.
Die Zertifikate hatte ich in der VBox erstellt.
Der Zugriff in meinem lokalen Netz auf die VBox-Odoo-Installation funktionierte.

Nun bekomme ich beim WEB-Zugriff auf den entfernten KVM-Client unter https://INTERNETADRESSE.myfritz.net:8069/ einen ssl-Fehler.

Diese Website kann keine sichere Verbindung bereitstellen

INTERNETADRESSE.myfritz.net hat eine ungültige Antwort gesendet.
ERR_SSL_PROTOCOL_ERROR

Der Test mittels ssl-Client ergibt Fehler:

Code: Alles auswählen

letzter@linux-z4iw:~> openssl s_client -connect INTERNETADRESSE.myfritz.net:8069
CONNECTED(00000003)
140311260968592:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:794:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 293 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1495395315
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
letzter@linux-z4iw:~>

Teste ich auf den nginx auf 4443, erhalte ich eine gültige Antwort:

Code: Alles auswählen

letzter@linux-z4iw:~> openssl s_client -connect INTERNETADRESSE.myfritz.net:4443
CONNECTED(00000003)
depth=0 C = DE, ST = Mecklenburg-Vorpommern, L = Ludwigslust, O = Braumanufaktur, CN = webmaster@example.org, emailAddress = webmaster@example.org
verify error:num=18:self signed certificate
verify return:1
depth=0 C = DE, ST = Mecklenburg-Vorpommern, L = Ludwigslust, O = Braumanufaktur, CN = webmaster@example.org, emailAddress = webmaster@example.org
verify return:1
---
Certificate chain
 0 s:/C=DE/ST=Mecklenburg-Vorpommern/L=Ludwigslust/O=Braumanufaktur/CN=webmaster@example.org/emailAddress=webmaster@example.org
   i:/C=DE/ST=Mecklenburg-Vorpommern/L=Ludwigslust/O=Braumanufaktur/CN=webmaster@example.org/emailAddress=webmaster@example.org
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDxDCCAqwCCQCGvOiuCkOo1DANBgkqhkiG9w0BAQsFADCBozELMAkGA1UEBhMC
REUxHzAdBgNVBAgMFk1lY2tsZW5idXJnLVZvcnBvbW1lcm4xFDASBgNVBAcMC0x1
ZHdpZ3NsdXN0MRcwFQYDVQQKDA5CcmF1bWFudWZha3R1cjEeMBwGA1UEAwwVd2Vi
bWFzdGVyQGV4YW1wbGUub3JnMSQwIgYJKoZIhvcNAQkBFhV3ZWJtYXN0ZXJAZXhh
bXBsZS5vcmcwHhcNMTcwMzIzMjExMjIxWhcNMTkwMzIzMjExMjIxWjCBozELMAkG
A1UEBhMCREUxHzAdBgNVBAgMFk1lY2tsZW5idXJnLVZvcnBvbW1lcm4xFDASBgNV
BAcMC0x1ZHdpZ3NsdXN0MRcwFQYDVQQKDA5CcmF1bWFudWZha3R1cjEeMBwGA1UE
AwwVd2VibWFzdGVyQGV4YW1wbGUub3JnMSQwIgYJKoZIhvcNAQkBFhV3ZWJtYXN0
ZXJAZXhhbXBsZS5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
SDPFXnrbWhDiPuT66xYP8PaQ/EeUCHh8eFfqTI3hZOoeZ9Heg0UyoAxlP9OP3ZfV
wQcJzKUAjrn+LrmD6+ohAYLHhItppvkUcExcA2nVRTT5ETvnUgduq1X4ayxEYYNf
K2TxhphQpJ8N5lH/1e8g5Yrygfy5dkQtFnlBQT7AkeIp6JWtOsQ1FNm+CasOpqVw
pTghKBIU6pQ+jnoX8Wd6aIbLOm6yuvnPeX9O+BOKheixpim3fOuZtyjb54lKGir5
zv4XWGCDoTTwbbiPXX0+gezQZFfMoFILyU/tFxXm7mhb5tIKhOEmhWWnmnkKvW8Z
yZdarK/a7gaHignqsqa1AgMBAAEwDQYJKoZIhvcNAQELBQADggEBAKf+3CwCJWyy
/Nfp3IJSaOV5nj3dv/0Re47Xdh+1MiM7Pt/mkX8D/mNXYcEjXnrf21HkurWWk5Ys
Zm0UHJGczkTbkELR3y/a2/iXnnaAPtOXbOkZpK1t+BN4wjhSH3nm6GU8ICXMdPwk
ctDVzQnnt4J1KcuBWArA+dEALXqnQHZqeH1waQfQQCXOwJqrSr5jcNKwyueGtY+P
GRh+q6o7hwbdyflZiFgx67F1ROp4lo4zlSBr0qyNU7NhtxBaTz/V0tBfe2r99D+H
1cGHloakZhSicNLn9GfBwt6ZvGdTG2nDzprFFCvOB1hlBr+zWtXFVJx498t5xKMu
I3bPXdJ7/EA=
-----END CERTIFICATE-----
subject=/C=DE/ST=Mecklenburg-Vorpommern/L=Ludwigslust/O=Braumanufaktur/CN=webmaster@example.org/emailAddress=webmaster@example.org
issuer=/C=DE/ST=Mecklenburg-Vorpommern/L=Ludwigslust/O=Braumanufaktur/CN=webmaster@example.org/emailAddress=webmaster@example.org
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 1643 bytes and written 419 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: E880C1233F4F72D5B7ACBAFD0DEFBB8825F34214484209008AF6E7EB62E759DA
    Session-ID-ctx: 
    Master-Key: 6FC2F6D1F26319BC630366CD145B3B83A5B044803BE3C7724EFA743C474BD08DE7029D1BC5351E8A655BDA8D58E8830B
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - c4 c3 58 c2 af a0 11 cc-de c8 ba 30 60 8e c0 06   ..X........0`...
    0010 - cd cb 2d 33 37 ae af 41-11 af 8a 37 a0 a7 b4 ec   ..-37..A...7....
    0020 - d7 ac 53 74 cf 28 2a d8-5f 22 f9 b7 2f 10 3b be   ..St.(*._"../.;.
    0030 - bc 6a 64 9d b8 02 b7 cd-e8 83 7d 6e c3 52 25 a3   .jd.......}n.R%.
    0040 - f5 b3 75 ef 2a b6 32 c2-79 4a a3 f1 55 32 a4 21   ..u.*.2.yJ..U2.!
    0050 - 22 4c 73 bc 05 cf ef d2-76 c1 a1 fc 67 b4 02 07   "Ls.....v...g...
    0060 - 75 70 b5 a6 6c cc d0 53-b5 90 83 f9 45 d4 b8 d9   up..l..S....E...
    0070 - bb 14 f0 9e 60 74 8a a6-7e 19 cb 25 12 18 02 1c   ....`t..~..%....
    0080 - 38 3e 2d 53 c3 f8 fc d5-68 cb 83 13 39 14 f4 b1   8>-S....h...9...
    0090 - 7b 1b 9d 6a 21 45 2a 53-bb 92 cd f2 5d 71 89 6c   {..j!E*S....]q.l
    00a0 - 31 7f e9 c4 e9 9c 62 2e-86 57 21 2d ad 05 4e 16   1.....b..W!-..N.

    Start Time: 1495396102
    Timeout   : 300 (sec)
    Verify return code: 18 (self signed certificate)
---
closed
letzter@linux-z4iw:~> 

Ich habe sicherlich in irgendeinem config-File nochwas vergessen, aber ich komme nicht drauf, was es sein kann.

Code: Alles auswählen

root@debian:/etc/nginx/sites-enabled# cat odoo.conf
## https://www.odoo.com/fr_FR/forum/help-1/question/nginx-reverse-proxy-on-80-443-32052

## Based on: http://www.schenkels.nl/2013/01/reverse-ssl-proxy-using-nginx-with-openerp-v7/

## OpenERP backend ##
upstream odoo {
    server 127.0.0.1:8069 weight=1 fail_timeout=0;
#    server 192.168.0.128:8069 weight=1 fail_timeout=0;
}

#upstream odoo-im {
#    server 127.0.0.1:8072 weight=1 fail_timeout=0;
#}

## https site##
server {
    listen      4443 ssl;
    server_name INTERNETADRESSE.myfritz.net;
#    root        /usr/share/nginx/html;
    index       index.html index.htm;
    ssl_certificate /etc/nginx/ssl/odootest.crt;
    ssl_certificate_key /etc/nginx/ssl/odootest.key;
        allow all;

        # log files
        access_log  /var/log/nginx/192.168.0.128.access.log;                                                                                   
        error_log   /var/log/nginx/192.168.0.128.error.log;                                                                                    
                                                                                                                                               
        # SSL-Protokolle definieren                                                                                                            
        ssl_protocols TLSv1.2 TLSv1.1 TLSv1;                                                                                                   
                                                                                                                                               
        # cipher einschränken                                                                                                                  
        ssl_ciphers     HIGH:!ADH!MD5;
#       ssl_prefer_server_ciphers on;

        # proxy buffers
        proxy_buffers 16 64k;
        proxy_buffer_size 128k;

        ## default location ##
        location / {
            proxy_pass  http://odoo;
#           proxy_pass  http://webserver;
#           proxy_pass  http://192.168.0.128;
            # force timeouts if the backend dies
            proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
            proxy_redirect off;
            proxy_read_timeout 300000;

            # set headers
            proxy_set_header    Host            $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 https;
        }

        # cache some static data in memory for 60mins
        location ~* /web/static/ {
            proxy_cache_valid 200 60m;
            proxy_buffering on;
            expires 864000;
#           proxy_pass http://odoo;
            proxy_pass  http://192.168.0.128;
        }

#       location /longpolling {
#           proxy_pass http://odoo-im;
#       }
    }

## http redirects to https ##
server {
    listen      80;
    server_name 192.168.0.128;

    # Strict Transport Security
    add_header Strict-Transport-Security max-age=2592000;
#    rewrite ^/.*$ https://$host$request_uri? permanent;
    return 301 https://$host$request_uri;
}
root@debian:/etc/nginx/sites-enabled#

Über Denkanstöße wäre ich dankbar.
Fertige Lösungen nehme ich aber auch
Sollten configs fehlen oder weiterer Output gewünscht sein, reiche ich diese gerne nach.

Nachtrag: Der Client läuft und ist per VMM administrierbar.

[rendegast]

Der Zugriff in meinem lokalen Netz auf die VBox-Odoo-Installation funktionierte.
upstream odoo {
server 127.0.0.1:8069 weight=1 fail_timeout=0;
# server 192.168.0.128:8069 weight=1 fail_timeout=0;
}

Ist nur localhost freigegeben

Wäre das denn überhaupt https:// ?
Eventuell brauchst Du einen ssh-Tunnel o.ä.

[letzter3]

Ist nur localhost freigegeben

M.E. nein.

nginx als Reverse-Proxy
Der nginx Webserver ist auch recht beliebt zum Einsatz als "Reverse Proxy". Dabei nimmt der Server die Anfrage aus dem Internet an, leitet diese an einen lokal laufenden Applikationsserver weiter und liefert anschließend dessen Antwort wird aus. So ist z.B. im Python Umfeld der Einsatz von nginx als Reverse Proxy in Kombination mit den (lokal laufenden) WSGI Applikationsserver gunicorn oder uwsgi eine durchaus beliebte Lösung.

Im einfachsten Fall benötigt man in der Konfiguration von nginx nur die folgenden beiden Zeilen:

Code: Alles auswählen

location / {
                proxy_pass http://127.0.0.1:8000;
}

Damit werden alle Anfragen an diese location - im obigen Beispiel als das Root-Verzeichnis der Domäne - an http://127.0.0.1:8000 weitergeleitet, wo dann ein Applikationsserver läuft.

Trotz der Weiterleitung übergibt nginx den angesteuerten Pfad (z.B. http://example.com/neu, und nicht http://127.0.0.1:8000/).

https://wiki.ubuntuusers.de/nginx/#ngin ... erse-Proxy

Wäre das denn überhaupt https:// ?
Eventuell brauchst Du einen ssh-Tunnel o.ä.

nginx funktioniert als ssh-proxy. Wird auch über https://.... aufgerufen und leitet auf den lokal laufenden Odoo-Server weiter.

Ich bin davon ausgegangen, dass ich in der odoo.conf nur meine lokale Adresse 192.168.0.128 gegen INTERNETADRESSE.myfritz.net tauschen muss.
Entweder hab ich das irgendwo übersehen, oder die Annahme ist falsch oder ich habe die Portweiterleitungen in der FritzBox nicht korrekt gesetzt.

[letzter3]

Unschöne Art des Bilderuploads, aber auf die Schnelle nichts anderes gefunden.

[letzter3]

Als Ergänzung:
Wenn ich versuche, vom client auf sich selber per https zu verbinden, kommt ein ssl-Fehler.
Details der Anfrage:

Code: Alles auswählen

Adresse: https://192.168.178.5:8069
Protokoll: https
Datum und Zeit: Montag, 22. Mai 2017 19:47
Zusätzliche Information: 192.168.178.5: SSL-Aushandlung fehlgeschlagen

Alle logs von nginx bzw. Odoo bleiben leer.

[letzter3]

Nu bin ich baff.

Ein Anfrage auf http://INTERNETADRESSE.myfritz.net:8069 (also ohne ssl) funktioniert.
Da ist also irgendwo in der nginx-config noch der Wurm drinne.
Da Odoo den Proxy-Mode per eigener Config erzwingt, baut nginx (auf Grund meiner Anweisungen :-/) Mist.
Heist:
- Die http-Weiterleitung auf https (ganz unten) funktioniert nicht.
- Die Zertifikatsauslieferung per openssl s_client -connect INTERNETADRESSE.myfritz.net:4443 funktioniert
- Der Aufruf der obigen Adresse mit https anstatt http ergibt einen Zertifkatsfehler.

Code: Alles auswählen

root@debian:/etc/nginx/sites-enabled# cat odoo.conf
## https://www.odoo.com/fr_FR/forum/help-1/question/nginx-reverse-proxy-on-80-443-32052

## Based on: http://www.schenkels.nl/2013/01/reverse-ssl-proxy-using-nginx-with-openerp-v7/

## OpenERP backend ##
upstream odoo {
    server 127.0.0.1:8069 weight=1 fail_timeout=0;
#    server 192.168.0.128:8069 weight=1 fail_timeout=0;
}

#upstream odoo-im {
#    server 127.0.0.1:8072 weight=1 fail_timeout=0;
#}

## https site##
server {
    listen      4443 ssl;
#    server_name 192.168.0.128;
    server_name INTERNETADRESSE.myfritz.net;
#    root        /usr/share/nginx/html;
    index       index.html index.htm;
    ssl_certificate /etc/nginx/ssl/odootest.crt;
    ssl_certificate_key /etc/nginx/ssl/odootest.key;
        allow all;

        # log files
        access_log  /var/log/nginx/Odoo.access.log;
        error_log   /var/log/nginx/Odoo.error.log;

        # SSL-Protokolle definieren
        ssl_protocols TLSv1.2 TLSv1.1 TLSv1;                                                                                                   
                                                                                                                                               
        # cipher einschränken                                                                                                                  
        ssl_ciphers     HIGH:!ADH!MD5;                                                                                                         
#       ssl_prefer_server_ciphers on;                                                                                                          
                                                                                                                                               
        # proxy buffers                                                                                                                        
        proxy_buffers 16 64k;
        proxy_buffer_size 128k;

        ## default location ##
        location / {
            proxy_pass  http://odoo;
#           proxy_pass  http://webserver;
#           proxy_pass  http://192.168.0.128;
            # force timeouts if the backend dies
            proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
            proxy_redirect off;
            proxy_read_timeout 300000;

            # set headers
            proxy_set_header    Host            $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 https;
        }

        # cache some static data in memory for 60mins
        location ~* /web/static/ {
            proxy_cache_valid 200 60m;
            proxy_buffering on;
            expires 864000;
#           proxy_pass http://odoo;
#           proxy_pass  http://192.168.0.128;
            proxy_pass http://INTERNETADRESSE.myfritz.net;
        }

#       location /longpolling {
#           proxy_pass http://odoo-im;
#       }
    }

## http redirects to https ##
server {
    listen      80;
#    server_name 192.168.0.128;
    server_name INTERNETADRESSE.myfritz.net;

    # Strict Transport Security
    add_header Strict-Transport-Security max-age=2592000;
#    rewrite ^/.*$ https://$host$request_uri? permanent;
    return 301 https://$host$request_uri;
}
root@debian:/etc/nginx/sites-enable

Mag mich mal irgendjemand schubsen?

[rendegast]

Du hast wohl odoo, welches auf dem Server an
localhost:8069, als http
192.168.0.128:8069, als http
lauscht.

Code: Alles auswählen

netstat -tpaun | grep 8069

Du hast ein 'server'
https://....:4443, das von localhost:8069 ("odoo") gespeist wird.

Ein zweites 'server'
localhost:80
192.168.0.128:80
schreibt um http:// -> https://
aber an :8069 lauscht dann dennoch weiterhin ein http://.

Bräuchtest Du nicht eher eine Umleitung
Anfragen an <nicht_localhost>:8069 -> :4443
?

[letzter3]

Danke für deine Mühe. Ich sitze gerade nicht an dem Rechner, reiche also die Ausgaben nach.

Du hast wohl odoo, welches auf dem Server an
localhost:8069, als http lauscht.

"Eigentlich" nein. In der Konfiguration von Odoo ist der Proxy Modus aktiviert, damit "sollte" es nicht auf localhost und auch nicht auf eine interne IP hören.

Du hast wohl odoo, welches auf dem Server an
192.168.0.128:8069, als http
lauscht.

Die 192.168.0.128:8069 ist auskommentiert, war die IP der VBox, die ich in meinem Heimnetz zu Hause hatte. Der betreffende Debian-KVM-Client (der Odoo-Server) hat die 192.168.178.5

Code: Alles auswählen

netstat -tpaun | grep 8069

liefer ich nach.

Du hast ein 'server'
https://....:4443, das von localhost:8069 ("odoo") gespeist wird.

Ich "denke" (vermute / hoffe) nicht. So wie ich das verstehe, habe (oder hätte ich gerne?) ich ein localhost:8069 ("odoo"), welches transparent von https://....:4443 bedient wird.

Ein zweites 'server'
localhost:80
192.168.0.128:80

? Ist sowas irgendwo definiert?

Nachfolgend die obige nginx-Konfiguration mit Kommentaren, aber ohne alle auskommentierten Zeilen.

Code: Alles auswählen

root@debian:/etc/nginx/sites-enabled# cat odoo.conf

upstream odoo {
    server 127.0.0.1:8069 weight=1 fail_timeout=0;
}

## https site##
server {
    listen      4443 ssl;
    server_name INTERNETADRESSE.myfritz.net;
    index       index.html index.htm;
    ssl_certificate /etc/nginx/ssl/odootest.crt;
    ssl_certificate_key /etc/nginx/ssl/odootest.key;
        allow all;

        # log files
        access_log  /var/log/nginx/Odoo.access.log;
        error_log   /var/log/nginx/Odoo.error.log;

        # SSL-Protokolle definieren
        ssl_protocols TLSv1.2 TLSv1.1 TLSv1;                                                                                                   
                                                                                                                                               
        # cipher einschränken                                                                                                                  
        ssl_ciphers     HIGH:!ADH!MD5;                                                                                                                                                                                                             
                                                                                                                                               
        # proxy buffers                                                                                                                        
        proxy_buffers 16 64k;
        proxy_buffer_size 128k;

        ## default location ##
        location / {
            proxy_pass  http://odoo;
            # force timeouts if the backend dies
            proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
            proxy_redirect off;
            proxy_read_timeout 300000;

            # set headers
            proxy_set_header    Host            $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 https;
        }

        # cache some static data in memory for 60mins
        location ~* /web/static/ {
            proxy_cache_valid 200 60m;
            proxy_buffering on;
            expires 864000;
            proxy_pass http://INTERNETADRESSE.myfritz.net;
        }

    }

## http redirects to https ##
server {
    listen      80;
    server_name INTERNETADRESSE.myfritz.net;

    # Strict Transport Security
    add_header Strict-Transport-Security max-age=2592000;
    return 301 https://$host$request_uri;
}
root@debian:/etc/nginx/sites-enable

schreibt um http:// -> https://
...

Ja. So ist es zumindest beabsichtigt.

....
aber an :8069 lauscht dann dennoch weiterhin ein http://.

Aber sowas ist doch nirgends definiert?
Allerdings erklärt es das aufgezeigte Verhalten.

Bräuchtest Du nicht eher eine Umleitung
Anfragen an <nicht_localhost>:8069 -> :4443
?

Ich glaube(!) nicht.

[letzter3]

Du hast wohl odoo, welches auf dem Server an
localhost:8069, als http
..
lauscht.

Code: Alles auswählen

netstat -tpaun | grep 8069

Damit hast du wohl Recht.

Code: Alles auswählen

root@debian:~# netstat -tpaun | grep 8069
tcp        0      0 0.0.0.0:8069            0.0.0.0:*               LISTEN      579/python      

Code: Alles auswählen

root@debian:~# cat /etc/odoo/odoo.conf
[options]
; This is the password that allows database operations:
; admin_passwd = xxxxx
db_host = False
db_port = False
db_user = xxxxx
db_password = xxxxx
addons_path = /usr/lib/python2.7/dist-packages/odoo/addons
proxy-mode = true
root@debian:~# 

Wo kommt der her?
Wird der hier definiert?

Code: Alles auswählen

upstream odoo {
    server 127.0.0.1:8069 weight=1 fail_timeout=0;
}

Muss ich den ändern auf

Code: Alles auswählen

upstream odoo {
server INTERNETADRESSE.myfritz.net:8069 weight=1 fail_timeout=0;
}

[rendegast]

# netstat -tpaun | grep 8069
tcp 0 0 0.0.0.0:8069 0.0.0.0:* LISTEN 579/python

Wo kommt der her?
Wird der hier definiert?

https://www.odoo.com/documentation/10.0 ... l-packaged
https://www.odoo.com/documentation/10.0 ... ine-config

built-in HTTP

--no-xmlrpc
do not start the HTTP or long-polling workers (may still start cron workers)

Warning
has no effect if --test-enable is set, as tests require an accessible HTTP server

--xmlrpc-interface <interface>
TCP/IP address on which the HTTP server listens, defaults to 0.0.0.0 (all addresses)

--xmlrpc-port <port>
Port on which the HTTP server listens, defaults to 8069.

--longpolling-port <port>
TCP port for long-polling connections in multiprocessing or gevent mode, defaults to 8072. Not used in default (threaded) mode.

Das Ding sollte so wohl gar nicht erreichbar sein, daher

Der Host sitzt hinter einer Fritzbox, dort sind die Ports 8069 (Odoo) und 4443 (nginx als https proxy) weitergeleitet auf die IP des KVM-Clients.

kannst Du das 8069 dort wohl abschalten,
nur durch den https-Proxy wird, auf der Maschine, auf odoo zugegriffen.


http://werkzeug.pocoo.org/docs/0.12/con ... s.ProxyFix
Aber da schalte ich jetzt ab, wsgi.
Ich weiß nicht, ob da jetzt die Teile IN odoo auf dem Server gemeint sind,
oder Client-Anwendungen.

[letzter3]

[ kannst Du das 8069 dort wohl abschalten,
nur durch den https-Proxy wird, auf der Maschine, auf odoo zugegriffen.

Das Leben kann so einfach sein.

Vielen Dank!

[AppJetty]

You have odoo on server as local host and need to redirect request on local host, You can also go through different configurations for the same.