Apache Proxy
Se devi gestire più frontend web in infrastrutture complesse, la soluzione più pratica è creare e configurare un Reverse Proxy. Ad esempio, puoi indirizzare alcuni siti su un server di produzione e altri in un ambiente di test o creare una extranet per i dipendenti e una per i clienti. Esistono diverse soluzioni tra cui scegliere, ma per la nostra esperienza useremo Apache per la sua comodità e flessibilità.
Dopo aver installato Apache su un server fisico, è necessario configurarlo per agire come Reverse Proxy. Se hai già familiarità con moduli, porte, virtualhost, ecc., la procedura sarà semplice.
Per attivare correttamente il Reverse Proxy, è necessario abilitare i seguenti moduli:
- proxy
- proxy-http
- proxy-http2
- rewrite
- ssl
- headers
- http2
- vhost_alias
Puoi verificare se un modulo è installato utilizzando il comando sudo a2query -m <nome_modulo>. Per abilitare un modulo, utilizza il comando sudo a2enmod <nome_modulo>.
File http2.conf
Devi poi configurare i virtual host per ogni dominio che vuoi proxyare. Puoi creare un nuovo file di configurazione virtual host utilizzando il comando sudo nano /etc/apache2/sites-available/<nome_dominio>.conf. In questo file, devi specificare le seguenti direttive, nel file del/dei vhosts
Questa configurazione dice ad Apache di proxyare tutte le richieste a <nome_dominio> a <indirizzo_ip_server_backend>. La direttiva ProxyPass specifica il server backend a cui la richiesta deve essere inoltrata, mentre la direttiva ProxyPassReverse riscrive gli header di risposta per sostituire l’indirizzo IP del server backend con il nome di dominio originale.
Se vuoi abilitare SSL per il tuo virtual host, dovrai creare un file di configurazione separato con le seguenti direttive:
Questa configurazione abilita SSL per il tuo virtual host e specifica la posizione dei tuoi file di certificato SSL e chiave privata.
Testa la tua configurazione
Una volta che hai creato i tuoi file di configurazione virtual host, devi testare la tua configurazione eseguendo il comando sudo apachectl configtest. Questo comando verificherà i tuoi file di configurazione per eventuali errori di sintassi e segnalerà eventuali problemi.
Se i tuoi file di configurazione sono privi di errori, puoi ricaricare Apache per applicare le modifiche utilizzando il comando sudo systemctl reload apache2.
Una volta configurato il Reverse Proxy, ogni richiesta per il sito www.your-domain.com verrà intercettata dal Reverse Proxy che ha un IP pubblico e uno privato. Grazie alla direttiva del vhost, il Reverse Proxy reindirizzerà la richiesta al server corrispondente a www.your-domain.com. In caso di redirect o link incompleti, Apache trasformerà la risposta usando l’indirizzo corretto.
Teoria del redirect
Ma come fa il server interno a girare la richiesta al server giusto? Tramite un DNS. Quando apri il sito www.your-domain.com, il tuo PC interroga il proprio DNS per sapere a quale IP mandare la richiesta. Il DNS risponde che www.your-domain.com corrisponde a un determinato IP, quindi il tuo PC manda la richiesta a quell’IP.
Il server con il Reverse Proxy riceve la richiesta e la gira al server interno giusto, che a sua volta si occuperà della generazione della risposta HTTP(S). Infine, il server con il Reverse Proxy riceve la risposta dal server interno e la gira al tuo PC, che la visualizza in Chrome.
Per una configurazione ottimale del Reverse Proxy, è importante attivare la negoziazione HTTP/2 tramite TLS per la sicurezza e utilizzare la direttiva H2Push per aumentare la velocità di risposta. È anche importante configurare correttamente le intestazioni Location, Content-Location e URI delle risposte di reindirizzamento HTTP.
Ulteriori dettagli sulle varie direttive relative alle funzioni H2 e alle funzionalità di Proxy di Apache sono disponibili sul sito ufficiale di Apache. Con questa configurazione, il tuo Reverse Proxy sarà in grado di gestire efficacemente molteplici frontend web in modo efficiente e sicuro.
Analizziamo alcuni parametri per una migliore comprensione.
Alla riga 3 del file http2.conf troviamo l’istruzione che consente la negoziazione HTTP/2 (h2) tramite TLS per sicuro. Consente l’aggiornamento della negoziazione in chiaro HTTP/2 (h2c) da una connessione HTTP/1.1 iniziale o tramite il controllo del preambolo HTTP/2.
Alla riga 7 troviamo la direttiva H2Push che è estremamente utile per una sorta di “concorrenzialità” nella risposta.
Direttamente dalla documentazione di Apache:
Il protocollo HTTP/2 consente al server di inviare altre risorse a un client quando ne richiede una particolare. Ciò è utile se tali risorse sono connesse in qualche modo e ci si può aspettare che il client lo chieda comunque. La spinta quindi fa risparmiare il tempo necessario al cliente per richiedere le risorse stesse. D’altra parte, spingere le risorse di cui il cliente non ha mai bisogno o che già possiede è uno spreco di larghezza di banda.
I push del server vengono rilevati ispezionando le intestazioni Link delle risposte (vedere https://tools.ietf.org/html/rfc5988 per le specifiche). Quando un collegamento così specificato ha l’attributo rel=preload, viene trattato come una risorsa da inviare.
Ulteriori dettagli sulle varie direttive relative alle funzioni H2 le trovi sul sito di Apache: https://httpd.apache.org/docs/2.4/mod/mod_http2.html
Le righe 4 e 7 dei virtualhost, che hanno la stessa funzione, sono quelle più “oscure” e, per evitare fraintendimenti, anche qui riporto esattamente ciò che ci dice la documentazione ufficiale di Apache:
Questa direttiva consente ad Apache httpd di regolare l’URL nelle intestazioni Location, Content-Location e URI nelle risposte di reindirizzamento HTTP. Ciò è essenziale quando Apache httpd viene utilizzato come proxy inverso (o gateway) per evitare di bypassare il proxy inverso a causa dei reindirizzamenti HTTP sui server back-end che rimangono dietro il proxy inverso.
Verranno riscritte solo le intestazioni di risposta HTTP specificamente menzionate sopra. Apache httpd non riscriverà altre intestazioni di risposta, né per impostazione predefinita riscriverà i riferimenti URL all’interno delle pagine HTML. Ciò significa che se il contenuto proxy contiene riferimenti URL assoluti, ignoreranno il proxy. Per riscrivere il contenuto HTML in modo che corrisponda al proxy, devi caricare e abilitare mod_proxy_html.
path è il nome di un percorso virtuale locale; url è un URL parziale per il server remoto. Questi parametri vengono utilizzati allo stesso modo della direttiva ProxyPass.
Ad esempio, supponiamo che il server locale abbia l’indirizzo http://example.com/; Poi
ProxyPass “/mirror/foo/” “http://backend.example.com/”
ProxyPassReverse “/mirror/foo/” “http://backend.example.com/”
ProxyPassReverseCookieDomain “backend.example.com” “public.example.com”
ProxyPassReverseCookiePath “/” “/mirror/foo/”
non solo causerà la conversione interna di una richiesta locale per http://example.com/mirror/foo/bar in una richiesta proxy a http://backend.example.com/bar (la funzionalità che ProxyPass fornisce qui) . Si occupa anche dei reindirizzamenti che il server backend.example.com invia quando reindirizza http://backend.example.com/bar a http://backend.example.com/quux . Apache httpd lo adatta a http://example.com/mirror/foo/quux prima di inoltrare la risposta di reindirizzamento HTTP al client. Si noti che il nome host utilizzato per costruire l’URL viene scelto rispetto all’impostazione della direttiva UseCanonicalName.
Anche in questo caso, ulteriori dettagli su queste e altre opzioni relative alle funzionalità di Proxy di Apache sono reperibili sul sito: https://httpd.apache.org/docs/2.4/mod/mod_proxy.html