Apache mod_substitute sulle richieste HTTP all'host inverso

Ho il seguente setup:

  • Printer # 1 in LAN
  • Stampante # 2 in LAN
  • Internet che affronta il server web di Debian Apache 2.2 a server-external-ip che voglio utilizzare come gateway IPP alle due printingnti

Le due printingnti sono raggiungibili (da LAN e dal server Apache) ai seguenti URL IPP:

  • Perché i miei avvisi DNS sono così lunghi (300 + ms) quando accedono al mio sito web?
  • Apache mod_rewrite abilitato ma non funzionante?
  • PHP fopen non riesce sempre con il permesso negato
  • mod_rewrite REQUEST_FILENAME non contiene path assoluto
  • Calcolo del carico vetroglass v4.0 CLUSTER con server apache HTTP: posizione di apache
  • Apache no-cache su file specifici
    • http://printer-1-local-ip/printer
    • http://printer-2-local-ip/printer

    (Le printingnti non sono fisicamente collegate al server web.)

    Voglio che siano raggiungibili da Internet nei seguenti URL:

    1. http://server-external-ip/prn1
    2. http://server-external-ip/prn2

    IPP funziona esclusivamente tramite richieste HTTP all'indirizzo della printingnte (cioè tutto il process di printing avviene tramite richieste POST all'indirizzo http: // printer-X-local-ip / printingnte ), per cui ho solo bisogno di redirect (cioè, con Apache) gli URL 1 e 2 sopra.

    Apache sta servendo altri contenuti, quindi non posso sostituirlo con un programma personalizzato (ad esempio, netcat o netsed). Inoltre, non posso eseguire un programma personalizzato in una port diversa poiché i client della printingnte potranno solo raggiungere il server nella port 80.

    Quindi ho provato la seguente configuration Apache:

     RewriteRule ^/prn1$ http://printer-1-local-ip:80/printer [P] ProxyPassReverse /prn1 http://printer-1-local-ip 

    Collegando un client Windows all'URL http: // server-esterno-ip / prn1 , il proxy inverso funziona. Ma il protocollo IPP invia anche alla printingnte (all'interno dei dati POST-ed) l'URL completo del dispositivo.

    Ciò significa che la printingnte riceve una richiesta IPP esplicita per una printingnte http: // server-external-ip / prn1 e non per il suo indirizzo corretto ( http: // printer-1-local-ip / printer ). Così rifiuta la connessione.

    Ho aggiunto questa voce nel file HOST al client Windows:

     server-external-ip printer-dns-name 

    Ma ancora non funziona poiché la printingnte riceve una richiesta IPP per http: // printer-dns-name / prn1 che ha ancora il nome di servizio sbagliato (ad esempio, prn1 invece della printingnte ).

    Non posso modificare l'url del proxy inverso da http: // server-esterno-ip / prn1 a http: // server-esterno-ip / printingnte poiché devo fornire l'accesso a entrambe le printingnti (e non posso cambiare il servizio della printingnte nome nella configuration della printingnte).

    Quello che voglio fare è quello di bloccare i dati IPP POST-ed HTTP alla printingnte per sostituire http: // server-esterno-ip / prnX con http: // printer-X-local-ip / printingnte (non ci sono checksums nel protocollo IPP e dai pacchetti che ho catturato questo dovrebbe funzionare).

    Il problema è che tutti i moduli Apache che posso fare per Google non ti aiuteranno a bloccare gli organi di richiesta HTTP inviati alla printingnte inversa. mod_rewrite funziona solo nelle intestazioni, mod_substitute funziona su corpi di risposta, mod_headers funziona su richiesta e le intestazioni di risposta, mod_replace funziona su tutto, ma su organi di richiesta ecc.

    Con mod_substitute ho provato con i seguenti:

     <Location /> AddOutputFilterByType SUBSTITUTE application/ipp Substitute "s|server-external-ip/prn1|printer-1-local-ip/printer|" </Location> 

    Ma, come previsto, funziona perfettamente sui corpi di risposta, ma non su richieste proxy (ho controllato proxy a un altro server). Notare anche che le richieste IPP sono del tipo di applicazione / ipp MIME, quindi il filtraggio non (significativamente) influisce sul traffico normale.

    Qualche idea su come risolvere questo disordine? Mi sento come dovrebbe essere una soluzione facile e non sto guardando le cose nel modo giusto. Ecco perché sto chiedendo questa comunità sempre impressionante (non ho ancora post, ma sono un fan di lunga data).

    Vorrei rimanere su questo "approccio di reindirizzamento", quindi soluzioni alternative saranno utili solo se non esiste una soluzione diretta. E sì, potrei modificare un module Apache allo scopo, ma non mi sento veramente … 🙂

    Nel frattempo provo una certa magia netsed … 🙂

  • Come diagnosticare la RAM?
  • L'authentication di Kerberos di Apache a Active Directory non accade. (È correlato KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN?)
  • Conflitto di dipendenza durante l'aggiornamento di Yum in CentOS 7
  • Puppet 2.7.x - variabile globale - Append
  • Cosa significa i fratelli in / proc / cpuinfo?
  • ssh accetta l'authentication della password anche se è stata configurata per l'authentication solo pubblica-chiave (che funziona!)
  • 2 Solutions collect form web for “Apache mod_substitute sulle richieste HTTP all'host inverso”

    Perché non fare quanto segue: Definire due nomi DNS per la printingnte esterna, ad esempio.

     printer-1-external.mydomain.com CNAME external-server.mydomain.com printer-2-external.mydomain.com CNAME external-server.mydomain.com 

    Potresti anche usare gli stessi nomi che usi internamente. Avere il DNS interno risolvere i nomi della printingnte direttamente sulla printingnte e il DNS esterno al tuo IP esterno …

    Aggiungere due host virtuali basati sul nome sul server:

     <VirtualHost *:80> ServerName printer-1-external.mydomain.com ProxyPass / http://printer-1-local-ip/ </VirtualHost> <VirtualHost *:80> ServerName printer-2-external.mydomain.com ProxyPass / http://printer-2-local-ip/ </VirtualHost> 

    In questo modo la tua richiesta IPP per http://printer-2-external.mydomain.com/printer avrà il nome del servizio corretto nei suoi parametri post.

    Spiacenti non posso aggiungere commenti, tuttavia, se non l'hai già fatto, controlla per verificare se:

     ProxyPreserveHost On 

    è configurato nel file conf.

    L'approccio con la riscrittura è buono per la radice del context, ma per il problema di hostname suona come se si desidera controllare ProxyPreserveHost.

    http://httpd.apache.org/docs/2.2/vhosts/examples.html

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.