yo @Falco, il real_ip (fornito da cf come header CF-Connecting-IP) ti arriva nei log di nginx? A me no. Vedo solo l’IP di cloudflared.
Penso che una o entrambe queste cose debbano essere fatte (farò seguito dopo le indagini):
aggiungere una riga di configurazione set_real_ip_from a nginx per l’IP di cloudflared. Se questo si rivela essere il problema, allora immagino che nessuna delle altre righe set_real_ip_from (fornite da templates/cloudflare.template.yml) sia necessaria per gli utenti di argotunnel. E in questo caso, forse un template argotunnel separato dovrebbe essere aggiunto al repository docker che estrae il tuo IP cloudflared da una variabile d’ambiente o qualcosa del genere nel tuo app.yml principale.
correggere il log_format. Penso che probabilmente non sia questo il problema, però. confermato non necessario
modifica:
ecco cosa sto facendo per farlo funzionare:
non usare il template cloudflare. non ha senso.
invece, unisci questo nel tuo app.yml:
hooks:
after_web_config:
- file:
path: /etc/nginx/conf.d/cloudflare_tunnel_real_ip.conf
contents: |
# ripristina gli IP originali dei visitatori (ngx_http_realip_module)
set_real_ip_from 10.100.20.200/32; # il tuo intervallo IP cloudflared/argotunnel
real_ip_header CF-Connecting-IP;
questo finisce automaticamente nel contesto http di nginx, che è appropriato.
PS: secondo me, per pulizia, il template cloudflare dovrebbe anche generare la sua configurazione nginx in un file separato invece di usare sed -i per aggiungerla a /etc/nginx/conf.d/discourse.conf.
sì @shyguy seguo il passo sig @Falco
sì sono in tunnel, prima avevo una protezione ddos da cloudflare, il ddos faceva andare il mio server in alto sulla cpu, nei log di accesso 20mb e vedevo solo il mio ip docker, ho sfidato il visitatore sul percorso url / per proteggere il server ma la cache scaduta ha dato errore di disconnessione
nel caso non fosse chiaro, il mio post riguardava solo la correzione del logging di nginx.
se non lo correggi, tutte le richieste nei tuoi log di nginx sembreranno provenire da un unico ip (il tuo cloudflared) invece di avere gli ip effettivi dei client.
quell’ip (o intervallo di ip) è da dove il tuo cloudflared si connette a discourse, quindi dipende dalla tua configurazione. un modo per esserne sicuri è guardare nel file di log di nginx e prendere l’ip da lì. e poi aggiungere un /32 dopo.
se stai seguendo la sua guida esattamente, immagino che sia 127.0.0.1/32
nah, quello era solo un suggerimento per il template cloudflare.template.yml – che non dovresti usare in questa configurazione.
segui semplicemente la sua guida nel primo post ma ignora il passaggio di aggiunta di quel template alla tua configurazione. invece, aggiungi l’hook che ho fornito.
Peccato. Mi sembra corretto, quindi non sono sicuro di cosa ci sia di sbagliato.
Ecco come dovrebbe funzionare:
Il proxy di Cloudflare aggiunge un’intestazione CF-Connecting-IP contenente l’IP del client
Nginx in Discourse è stato compilato con ngx_http_realip_module – un software che legge questa intestazione e corregge i log, ecc. per mostrare l’IP effettivo del client
set_real_ip_from abilita questa funzionalità per le connessioni dagli intervalli IP passati ad essa. Questi sarebbero normalmente gli intervalli IP di Cloudflare (forniti dal modello di convenienza cloudflare.template.yml), ma poiché stai usando Argotunnel, useresti semplicemente l’IP di Argotunnel.
Prova a disabilitare il mio hook. Vedi lo stesso IP nei tuoi log nginx prima/dopo?
Probabilmente l’unica differenza nelle nostre configurazioni è che sto eseguendo Argotunnel (cloudflared) in Docker.
Se vuoi provare…
Ho creato una rete solo per cloudflared:
services:
cloudflared:
image: cloudflare/cloudflared:latest
container_name: cloudflared
command: tunnel run
restart: unless-stopped
networks:
wan:
cf_tunnel:
# per ngx_http_realip_module
# impostato su un IP elevato in modo che, si spera, Docker non assegni tramite DHCP
# un altro container a quell'IP se si avvia prima di cloudflared
ipv4_address: 10.200.10.200 # questo è l'IP per `set_real_ip_from` in nginx
volumes:
# dovrebbe essere di proprietà di uid:gid 65532:65532
- ./conf:/home/nonroot/.cloudflared
networks:
cf_tunnel:
external: true # significa solo una rete non gestita da compose
# per le prestazioni:
# https://github.com/quic-go/quic-go/wiki/UDP-Receive-Buffer-Size
# sudo nano /etc/sysctl.conf
# aggiungi questa riga:
# net.core.rmem_max=2500000
# (il mio vecchio valore era 212992 – controllalo con: sudo sysctl net.core.rmem_max)
Puoi trasferire la tua configurazione/certificato in quella directory conf (ricorda di eseguire chown come dice la nota nel file compose) o semplicemente ripetere la procedura di configurazione. Puoi eseguire comandi cloudflared per accedere o altro in questo modo:
docker run -it --rm -v /path/to/conf:/home/nonroot/.cloudflared cloudflare/cloudflared:latest YOUR_CMD_HERE
E poi devi unire il tuo container Discourse alla rete. Puoi farlo aggiungendo questo in fondo al tuo file yml del container:
docker_args:
- '--network=cf_tunnel' # opzionalmente, potresti anche impostare un IP statico qui
Qualcuno ha avuto successo nell’ottenere il container del server di posta in arrivo di Discourse funzionante tramite il tunnel Cloudflare?
Ho avuto problemi nell’impostare un altro server di posta dietro il tunnel Cloudflare in passato, ma riesco a far funzionare le app sul mio Pi che utilizzano le porte 80 e 443 senza problemi.
Ho impostato Discourse sui server più volte e per ora non sono troppo preoccupato per il container principale di Discourse.
Penso che questo sia correlato, ma per favore crea un nuovo post dalla mia risposta se ritieni che sia fuori tema.
Ho utilizzato il servizio argo. Ho rinunciato quando ho pagato 28 euro per il primo mese. C’era in realtà almeno una differenza di 200 ms. Tuttavia, l’ho annullato perché non potevo permettermi di pagare 28 euro ogni mese per 200 ms. Siti più grandi avranno più fatture, tieni presente.
Il sito ha 800-1000 utenti unici. Puoi calcolare di conseguenza.
Inoltre, da quando ho iniziato a usare tunnel, caricare media è stato un problema o quasi impossibile
Il caricamento avviene normalmente, poi ricevo questo errore
Questa è la cosa lol è a 64 bit. Ma ho risolto. Ho eseguito apt get upgrade e riavviato il servizio Cloudflare e ha caricato. Sai anche se Cloudflare limita il caricamento di video con tunnel? Sto avendo problemi a caricare un video di circa 20 MB e prima non li avevo.
Tuttavia, durante l’installazione appare sempre l’errore che Discourse non riesce a raggiungere il dominio.
Ho scritto DISCOURSE_FORCE_HTTPS: true in App.yml.
Tuttavia, non ho annullato l’installazione, ma è stata annullata automaticamente prima che potessi modificare App.yml. Potrebbe essere questo l’errore?
