yo @Falco, est-ce que le real_ip (fourni par cf comme en-tête CF-Connecting-IP) remonte pour toi dans les logs nginx ? Pas pour moi. Je ne vois que l’IP de cloudflared.
Je pense qu’une ou les deux choses suivantes doivent être faites (je ferai un suivi après investigation) :
ajouter une ligne de configuration set_real_ip_from à nginx pour l’IP de cloudflared. Si c’est ça le problème, alors je suppose qu’aucune des autres lignes set_real_ip_from (fournies par templates/cloudflare.template.yml) n’est nécessaire pour les utilisateurs d’argotunnel. Et dans ce cas, peut-être qu’un modèle argotunnel séparé devrait être ajouté au dépôt docker qui récupère ton IP cloudflared à partir d’une variable d’environnement ou de quelque chose dans ton app.yml principal.
corriger le log_format. Je pense que ce n’est probablement pas le problème, cependant. Confirmé inutile
edit :
voici ce que je fais pour que ça marche :
n’utilise pas le modèle cloudflare. Ça ne sert à rien.
Au lieu de cela, fusionne ceci dans ton app.yml :
hooks:
after_web_config:
- file:
path: /etc/nginx/conf.d/cloudflare_tunnel_real_ip.conf
contents: |
# restaurer les IPs originales des visiteurs (ngx_http_realip_module)
set_real_ip_from 10.100.20.200/32; # ta plage d'IP cloudflared/argotunnel
real_ip_header CF-Connecting-IP;
cela se retrouve automatiquement dans le contexte http de nginx, ce qui est approprié.
PS : à mon avis, pour plus de clarté, le modèle cloudflare devrait également générer sa configuration nginx dans un fichier séparé au lieu d’utiliser sed -i pour l’ajouter à /etc/nginx/conf.d/discourse.conf.
oui @shyguy je suis les étapes mr @Falco
oui je suis dans le tunnel, avant j’avais une protection ddos de cloudflare, le ddos faisait monter mon serveur en cpu, dans les logs d’accès 20 Mo et je ne voyais que mon ip docker, j’ai mis un défi aux visiteurs sur le chemin d’url / pour protéger le serveur mais le cache expiré a donné une erreur de discoure
pour que ce ne soit pas clair, mon message là-bas concernait uniquement la correction de la journalisation nginx.
si vous ne le corrigez pas, toutes les requêtes dans vos journaux nginx sembleront provenir d’une seule IP (votre cloudflared) au lieu d’avoir les véritables IP des clients.
cette IP (ou plage d’IP) est celle à partir de laquelle votre cloudflared se connecte à discourse, donc cela dépend de votre configuration. une façon d’être sûr est de regarder dans le fichier journal nginx et d’en extraire l’IP. puis d’ajouter un /32 après.
si vous suivez son guide exactement, je suppose que c’est 127.0.0.1/32
non, ce n’était qu’une suggestion pour le modèle cloudflare.template.yml – que vous ne devriez pas utiliser dans cette configuration.
suivez simplement son guide dans le premier message, mais ignorez l’étape d’ajout de ce modèle à votre configuration. au lieu de cela, ajoutez le hook que j’ai fourni.
dommage. cela me semble correct, donc je ne suis pas sûr de ce qui ne va pas.
voici comment cela est censé fonctionner :
le proxy cloudflare ajoute un en-tête CF-Connecting-IP contenant l’adresse IP du client
nginx dans discourse a été compilé avec ngx_http_realip_module – un logiciel qui lit cet en-tête et corrige les journaux, etc. pour afficher l’adresse IP réelle du client
set_real_ip_from active cette fonctionnalité pour les connexions provenant des plages d’adresses IP qui lui sont passées. il s’agirait normalement des plages d’adresses IP de cloudflare (fournies par le modèle pratique cloudflare.template.yml), mais comme vous utilisez argotunnel, vous utiliseriez simplement l’adresse IP d’argotunnel à la place.
essayez de désactiver mon hook. voyez-vous la même adresse IP dans vos journaux nginx avant/après ?
la seule différence dans nos configurations est probablement que j’exécute argotunnel (cloudflared) dans docker.
si vous voulez essayer cela…
j’ai créé un réseau juste pour cloudflared :
services:
cloudflared:
image: cloudflare/cloudflared:latest
container_name: cloudflared
command: tunnel run
restart: unless-stopped
networks:
wan:
cf_tunnel:
# pour ngx_http_realip_module
# défini sur une adresse IP élevée afin que docker n'attribue pas par DHCP
# une autre adresse IP à un autre conteneur s'il démarre avant cloudflared
ipv4_address: 10.200.10.200 # c'est l'adresse IP pour `set_real_ip_from` dans nginx
volumes:
# doit appartenir à uid:gid 65532:65532
- ./conf:/home/nonroot/.cloudflared
networks:
cf_tunnel:
external: true # signifie simplement un réseau non géré par compose
# pour la performance :
# https://github.com/quic-go/quic-go/wiki/UDP-Receive-Buffer-Size
# sudo nano /etc/sysctl.conf
# ajoutez cette ligne :
# net.core.rmem_max=2500000
# (ma vieille valeur était 212992 – vérifiez-la avec : sudo sysctl net.core.rmem_max)
vous pouvez y transférer votre configuration/certificat dans ce répertoire conf (n’oubliez pas de faire chown comme indiqué dans la note du fichier compose) ou simplement répéter la procédure de configuration. vous pouvez exécuter des commandes cloudflared pour vous connecter ou autre chose comme ceci :
docker run -it --rm -v /path/to/conf:/home/nonroot/.cloudflared cloudflare/cloudflared:latest VOTRE_COMMANDE_ICI
et ensuite vous devez joindre votre conteneur discourse au réseau. vous pouvez le faire en ajoutant ceci au bas de votre fichier yml de conteneur :
docker_args:
- '--network=cf_tunnel' # facultativement, vous pourriez également définir une adresse IP statique ici
Quelqu’un a-t-il réussi à faire fonctionner le conteneur du serveur de messagerie entrant Discourse via le tunnel Cloudflare ?
J’ai eu du mal à configurer un autre serveur de messagerie derrière le tunnel Cloudflare par le passé, mais je peux faire fonctionner des applications sur mon Pi qui utilisent les ports 80 et 443 sans problème.
J’ai configuré Discourse sur des serveurs à plusieurs reprises et je ne suis pas trop préoccupé par le conteneur Discourse principal pour le moment.
Je pense que cela est lié, mais veuillez créer un nouveau message à partir de ma réponse si vous estimez que cela est hors sujet.
J’ai utilisé le service argo. J’ai abandonné lorsque j’ai payé 28 euros pour le premier mois. Il y avait en fait une différence d’au moins 200 ms. Cependant, je l’ai annulé car je ne pouvais pas me permettre de payer 28 euros chaque mois pour 200 ms. Les sites plus importants auront plus de factures, gardez cela à l’esprit.
Le site a 800 à 1000 utilisateurs uniques. Vous pouvez calculer en conséquence.
De plus, depuis que j’utilise tunnel, le téléchargement de médias est devenu une corvée, voire impossible.
Les téléchargements se font normalement, puis j’obtiens cette erreur :
C’est ça lol, c’est 64 bits. Mais j’ai trouvé. J’ai fait apt get upgrade et redémarré le service cloudflare et ça s’est téléchargé. Savez-vous aussi si cloudflare limite le téléchargement de vidéos avec tunnel ? J’ai des problèmes pour télécharger une vidéo de 20 Mo et ce n’était pas le cas avant
Cependant, l’erreur indiquant que Discourse ne peut pas atteindre le domaine apparaît toujours pendant l’installation.
J’ai écrit DISCOURSE_FORCE_HTTPS: true dans App.yml.
Cependant, je n’ai pas annulé l’installation, mais elle a été automatiquement annulée avant que je puisse modifier App.yml. Cela pourrait-il être la cause de l’erreur ?
