2017-06-04 4 views
0

J'utilise la plupart des matières localement à la maison dans une machine virtuelle vagabonde. Avec Port Forwarding sur mon routeur DSL, je mappe l'interface Web sur un sous-domaine sur mon vHost WAN avec IP fixe.Apache2 Websocket Proxy pour Mattermost de l'hôte dns dynamique

<VirtualHost *:80> 

    ServerName chat.domain.tld 
    ServerSignature Off 
    ProxyPreserveHost On 

    <Location /> 
    Order deny,allow 
    Allow from all 

    ProxyPassReverse http://chat.domain.tld/ 
    </Location> 

    RewriteEngine on 
    RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f 
    RewriteRule .* http://mappedsubdomain.somedyndns.tld:8090%{REQUEST_URI} [P,QSA] 

    DocumentRoot /somewhere/on/my/disk 

</VirtualHost> 

Et cela fonctionne très bien! Dans ce cas, je suis mappé Web Frontend à partir du port 8090 sur le port 80 sur le sous-domaine vHost. Et le Web-Frontend est accessible.

Mais. Matter12 utilise un autre port pour communiquer avec Web-Frontend sur Websockets. Pour cela, j'ai également transmis le port Websocket à partir de ma machine locale. Si j'accède à l'URL de l'hôte DNS dynamique: http://mappedsubdomain.somedyndns.tld:8090 le Web-Fontend fonctionne bien avec le deuxième port ouvert pour Websockets. Mattermost est utilisable sur l'URL de l'hôte DNS dynamique. Par défaut, Mattermost utilise le port 80 pour les Websockets. Mais dans mon cas, j'utilise le port 890 pour les Websockets dans Mattermost. Il fonctionne localement, à l'intérieur du LAN et sur l'hôte DNS dynamique.

Maintenant, je veux faire un ProxyReverse avec le protocole Websocket.

L'hôte WAN est un Debian avec Apache2.2 et le module mod_proxy_wstunnel chargé.

Au début, je l'ai essayé simplement de cartographier le deuxième port:

Listen 890 
<VirtualHost *:890> 
    ServerName chat.domain.tld 
    ServerSignature off 

    ProxyRequests off 
    RewriteEngine on 

    RewriteCond %{HTTP:Upgrade} =websocket [NC] 
    RewriteRule /(.*)   ws://mappedsubdomain.somedyndns.tld:890/$1 [P,L] 

    RewriteCond %{HTTP:Upgrade} !=websocket [NC] 
    RewriteRule /(.*)   http://mappedsubdomain.somedyndns.tld:890/$1 [P,L] 

    <Location /> 
    Order deny,allow 
    Allow from all 

    ProxyPassReverse http://mappedsubdomain.somedyndns.tld:890/ 
    ProxyPassReverse ws://mappedsubdomain.somedyndns.tld:890/ 
    </Location> 

    DocumentRoot /somewhere/on/my/disk 

</VirtualHost> 

Mais rien. Les Websockets ne fonctionnent pas.

Puis je l'ai essayé à partir d'un sur le NodeJS en cours d'exécution WAN vHost Websocket Tunnel:

https://www.npmjs.com/package/wstunnel 

Avec cet appel:

wstunnel -t 8091 ws://mappedsubdomain.somedyndns.tld:890/ 

et changé l'hôte virtuel Config:

RewriteRule /(.*)  ws://localhost:8091/$1 
RewriteRule /(.*)  http://localhost:8091/$1 [P,L] 
ProxyPassReverse  ws://localhost:8091/  
ProxyPassReverse  http://localhost:8091/ 

Lorsque wstunnel est en cours d'exécution, une requête http sur chat.domain.tld:890 se termine par un eout. Sans wstunnel, j'ai un 503.

Quelqu'un at-il un indice utile pour moi?

+0

au moment où j'ai une connexion, mais une erreur vient: Bad Request { "id": "api.web_socket.connect .upgrade.app_error "," message ":" Fehler beim Hochstufen der Websocket-Verbindung "," detailed_error ":" "," request_id ":" ytrcucx9jj8ymjedxtahndsaxy "," status_code ": 500} cela signifie: Échec de la mise à niveau de socket Web connexion – seekwhencer

Répondre