IP remoti con HAProxy


19

Sto testando una nuova configurazione del server Web che presenta un paio di problemi. In sostanza, abbiamo un server Web, in cui il codice utilizza l'IP remoto per alcune cose interessanti, e anche alcune directory apache protette fino ad alcuni IP (il nostro ufficio ecc.).

Tuttavia, l'abbiamo appena nascosto dietro ha_proxy in modo da poter considerare l'aggiunta di alcuni altri server di app, ma ora l'IP remoto arriva sempre come IP proxy, non come il vero utente remoto. Ciò significa che non possiamo raggiungere alcune località e la nostra app si sta comportando in modo un po 'strano laddove l'IP dell'utente è importante.

La nostra configurazione è la seguente:

global
      maxconn 4096
      pidfile /var/run/haproxy.pid
      daemon

defaults
      mode http
      retries 3
      option redispatch
      maxconn 2000
      contimeout 5000
      clitimeout 50000
      srvtimeout 50000

listen farm xxx.xxx.xxx.xxx:80
      mode http
      cookie GALAXY insert
      balance roundrobin
      option httpclose
      option forwardfor
      stats enable
      stats auth username:userpass

      server app1 xxx.xxx.xxx.xxx:80 maxconn 1 check

Risposte:


31

Citato dal documento HAProxy su haproxy.1wt.eu .

- se l'applicazione deve registrare l'IP del client originale, utilizzare il
  "forwardfor" opzione che aggiungerà un'intestazione "X-Forwarded-For" con il
  indirizzo IP del client originale. È inoltre necessario utilizzare "httpclose" per garantire
  che riscriverete ogni richiesta e non solo la prima di ciascuna
  sessione:
        opzione httpclose
        opzione forwardfor

Si afferma che l'applicazione deve trattare l'intestazione HTTP X-Forwarded-For per conoscere l'indirizzo IP del client. Sembra l'unico modo per andare nel tuo caso.

Aggiornato per HAProxy 1.4

Haproxy 1.4 ha introdotto una nuova modalità con "opzione http-server-close". Ha comunque chiuso la connessione al server ma mantiene attivo nei confronti del client, se possibile e utilizzato. Nella maggior parte delle configurazioni, probabilmente si desidera utilizzarlo poiché aiuta con la latenza nella singola parte ad alta latenza della connessione (tra Haproxy e il client).

   option http-server-close
   option forwardfor

2
Migliore utilizzo option forwardfor header X-Real-IPe reqidel ^X-Real-IP:, questo smette di falsificare gli IP nei tuoi registri. Cordiali saluti: X-Real-IPè l'intestazione predefinita per NginXl'opzione ' set_real_ip_from.
Tino,

La domanda non menziona nginx. X-Real-IP non funzionerebbe.
Rick Fletcher,

1. queste due opzioni devono essere impostate nella sezione di configurazione frontend o backend? (Perché non sembrano funzionare qui) 2. È necessario un tipo di configurazione anche a livello di Tomcat?
yglodt,

6

Esiste un modo per ricompilare HAproxy per includere Tproxy che consentirà l'inoltro dell'indirizzo di origine.

C'è un post sul blog qui a riguardo: http://blog.loadbalancer.org/configure-haproxy-with-tproxy-kernel-for-full-transparent-proxy/

Alcune note:

L'ultimo kernel Linux (2.6.28-11-server) include il supporto per TProxy, quindi non è necessario ricompilare il kernel.

Assicurarsi di configurare i server nella Web farm con un indirizzo gateway predefinito che punti al server HAProxy.



1

Si noti che sembra che sia possibile sovrascrivere ciò che l'applicazione vede sta cambiando le intestazioni di Apache:

SetEnvIf X-Forwarded-For (.*) REMOTE_ADDR=$1
SetEnvIf X-Forwarded-For (.*) REMOTE_IP=$1

Tuttavia, questo non funziona per l'accesso di Apache tramite "Consenti da" ecc.


Ciò potrebbe causare risultati imprevedibili se il client invia X-Forwarded-Forun'intestazione esistente quando il nuovo indirizzo IP viene aggiunto alla fine dell'elenco esistente, separato da una virgola e uno spazio. Cambia (.*)in ([^ ]*)$per afferrare solo l'ultimo IP ... o usa mod_rpafo mod_remoteipper Apache 2.4 o successivo.
Ladadadada,

1

HAProxy, in base alla progettazione, non può inoltrare l'indirizzo IP originale al server reale, praticamente come qualsiasi altro proxy.

Una soluzione potrebbe essere, se l'unico problema riguarda un server Web, di esaminare l'intestazione HTTP X-forwarded-for, che dovrebbe contenere l'indirizzo del client. Ora, questo è praticamente specifico per l'applicazione / la lingua, ma dai un'occhiata a questo esempio in php:

$headers = apache_request_headers();

$real_client_ip = $headers["X-Forwarded-For"];

Se si desidera anche registrare l'indirizzo originale, è possibile modificare LogFormat in httpd.conf per assomigliare a questo:

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{X-Forwarded-For}i\"" common


sbagliato, è possibile con l'opzione "forwardfor"
wittwerch

Sì, e questa opzione è attiva per impostazione predefinita, ma ciò che fa è impostare l'intestazione HTTP X-Forwarded-For. Quello che stavo dicendo, e mi sembra che sia proprio quello che stava chiedendo il richiedente, riguardava l'indirizzo reale del pacchetto IP
Thiagodrv,

0

Bene, sembra che X-Forwarded-for non funzioni bene per la tua configurazione. Quindi, c'è qualche motivo speciale per cui ti attieni al problema del haproxy? Sembra che IPVS sia più appropriato per le tue esigenze (in realtà uso ldirector che a sua volta utilizza ipvs).

Dare un'occhiata a:

http://kb.linuxvirtualserver.org/wiki/IPVS

e

http://www.vergenet.net/linux/ldirectord/

L'uso dell'IPVS in modalità 'IP Tunneling' o 'Direct Routing' conserva l'indirizzo del client.


0

Prova mod_extract_forwarded da http://www.openinfo.co.uk/apache/

LoadModule extract_forwarded_module modules/mod_extract_forwarded.so
MEFOrder refuse,accept
MEFRefuse all
MEFAccept xxx.xxx.xxx.xxx

-1

Modo semplice con haproxy in modalità tcp e nginx:

aggiungi proxy di invio come opzione server:

haproxy.conf:

.

.

ascolta ssl 0.0.0.0:443

modalità tcp

balance minimumconn

opzione httpchk GET / ping

opzioni log-integrità-controlli

server w1 192.168.1.1:443 controllo send-proxy check-ssl verifica nessuno

server w2 192.168.1.1:443 controllo send-proxy check-ssl verifica nessuno

.

.

Nginx necessita del supporto del protocollo proxy

nginx.conf:

.

.

ascolta 192.168.1.1:443 ssl proxy_protocol;

.

.

set_real_ip_da 192.168.1.0/24;

real_ip_header proxy_protocol;

.

.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.