Configura più istanze di RestFrontage dietro IIS ARR

• Tipo non definito

Questa guida descrive come configurare IIS ARR per distribuire le richieste tra più istanze di RestFrontage e passare loro l'HTTPS originale. L'esempio utilizza due istanze su una singola macchina; il principio si estende a più istanze, ospitate su una o più macchine. Ogni istanza deve consentire l'indirizzo proxy come lo vede

Questa documentazione è destinata a integratori e amministratori che implementano Immersive RestFrontage dietro un reverse proxy. Descrive come riconoscere il protocollo HTTPS originale, come configurare proxy affidabili e quali controlli devono essere effettuati prima del provisioning.

Nomi portail.example.com, application-noeud-1 e application-noeud-2, e gli indirizzi e le porte negli esempi sono illustrativi. Sostituiscili con i valori della tua installazione.

1. Comprendere il ruolo del proxy inverso

Un proxy inverso riceve le richieste dagli utenti e poi le inoltra a RestFrontage. Questo include input HTTPS, instradamento verso applicazioni e distribuzione delle richieste su più istanze.

Quando il proxy riceve una richiesta tramite HTTPS e la inoltra a RestFrontage tramite HTTP, l'applicazione deve conoscere il protocollo utilizzato dal visitatore. Altrimenti, può reindirizzare indietro su HTTPS, produrre un indirizzo contenente la porta interna di un'istanza o causare un ciclo di reindirizzamento.

flowchart TB
    U["Utilisateur"]
    P["Reverse proxy"]
    A["Immersive RestFrontage"]

    U -->|"HTTPS : connexion publique chiffrée"| P
    P -->|"HTTP : liaison interne autorisée<br/>X-Forwarded-Proto: https"| A

Il supporto per proxy inversi configurabili consente a RestFrontage di riconoscere queste informazioni quando provengono da un proxy esplicitamente autorizzato.

2. Ambito e comportamento predefiniti

La funzionalità è disabilitato di default. Senza sezione ReverseProxy, o con Enabled à false, non viene aggiunta alcuna elaborazione aggiuntiva alla pipeline di query. L'integrazione IIS già presente mantiene il suo comportamento.

Quando attivata, la funzione legge solo X-Forwarded-Proto per determinare se la richiesta originale utilizza HTTP o HTTPS. Questa elaborazione avviene prima di HSTS, reindirizzamento HTTPS e autenticazione.

Preserva le altre informazioni presenti nella richiesta: nome host, indirizzo del chiamante, percorso e identità utente. Intestazioni X-Forwarded-For, X-Forwarded-Host e X-Forwarded-Prefix non sono abilitati da questa configurazione.

3. Configura proxy affidabili

3.1 Prerequisiti

• Avere una versione aggiornata di RestFrontage per il ReverseProxy.
• Identificare l'indirizzo IP sotto cui ogni proxy immediato è visualizzato dall'applicazione.
• Avere i diritti necessari per modificare la configurazione di RestFrontage e del proxy.
• Programma il riavvio di ogni istanza interessata dopo la modifica.

3.2 Impostazioni disponibili

Aggiungi la sezione successiva alla radice del file appsettings.json dell'installazione, mantenendo le altre sezioni:

{
  "ReverseProxy": {
    "Enabled": false,
    "KnownProxies": []
  }
}

Parametro	Predefinito	Descrizione
ReverseProxy:Enabled	false	Consente il riconoscimento del protocollo di origine trasmesso da proxy dichiarati.
ReverseProxy:KnownProxies	Lista vuota	Indirizzi IP esatti dei proxy immediati autorizzati a trasmettere queste informazioni.

Quando Enabled vale true, la lista deve contenere almeno un indirizzo valido IPv4 o IPv6. Nomi DNS, intervalli CIDR, wildcard e ascoltatori generici come 0.0.0.0 e :: non sono accettati.

Gli indirizzi dei loop locali non sono implicitamente fidati: aggiungi esplicitamente 127.0.0.1 oppure ::1 se usato. Le rappresentazioni IPv4 mappate su IPv6 sono riconosciute anche.

Una configurazione abilitata con un'impostazione sconosciuta, una lista vuota o un indirizzo invalido impedisce l'avvio con un errore di configurazione. Non esiste un fallback che consenta tutti i proxy. Quando la funzione è disabilitata, le impostazioni inutilizzate in questa sezione non vengono convalidate.

3.3 Proxy installato sulla stessa macchina

Per un proxy che contatta RestFrontage tramite il loop locale:

{
  "ReverseProxy": {
    "Enabled": true,
    "KnownProxies": [ "127.0.0.1", "::1" ]
  }
}

3.4 Proxy installato su un'altra macchina

Per un proxy il cui indirizzo sorgente è visto dall'applicazione è, ad esempio, 10.20.0.10 :

{
  "ReverseProxy": {
    "Enabled": true,
    "KnownProxies": [ "10.20.0.10" ]
  }
}

Se ci sono più proxy che possono contattare direttamente l'applicazione, dichiara i loro indirizzi nello stesso elenco. Non includere gli indirizzi degli utenti o l'indirizzo pubblico del portale a meno che l'indirizzo pubblico del portale non sia effettivamente l'indirizzo di origine del proxy, come visto da RestFrontage.

3.5 Far rispettare i cambiamenti

La configurazione viene letta all'avvio. Sotto IIS, ricicla il pool di applicazioni di ogni istanza interessata dopo la modifica. Per una modalità host diversa, riavvia il servizio che ospita RestFrontage.

Le variabili ambientali possono anche fornire questi valori:

Variabile	Valore di esempio
ReverseProxy__Enabled	true
ReverseProxy__KnownProxies__0	127.0.0.1
ReverseProxy__KnownProxies__1	::1

4. Prepara il routing proxy

Il proxy deve passare il nome host pubblico nell'intestazione Host, perché questa funzione non si recupera X-Forwarded-Host.

Per una richiesta ricevuta tramite HTTPS, deve impostare X-Forwarded-Proto à https. Per una richiesta pubblica ricevuta tramite HTTP, deve o reindirizzare il visitatore a HTTPS o superare il protocollo effettivo.

Limitare l'accesso ai binding interni di RestFrontage ai componenti previsti dall'architettura. Quando un host condivide il server con il proxy, i suoi processi locali possono anche effettuare richieste dal ciclo locale, così il server fa parte del perimetro affidabile.

4.1 Molteplici relè o integrazione IIS esistente

RestFrontage considera solo il valore più a destra di X-Forwarded-Proto, corrispondente alle informazioni trasmesse dal proxy immediato. Questo meccanismo non ricostruisce l'intero percorso attraverso più proxy né modifica le opzioni di inoltro dell'intestazione già usate da IIS

Con IIS ospitato fuori dal processo, alcune header potrebbero essere già state elaborate prima di raggiungere la pipeline RestFrontage. Con più relay, verifica le informazioni effettivamente ricevute dall'applicazione prima di definire gli indirizzi consentiti. Un elenco di proxy consentiti multipli non rappresenta, da solo, la descrizione di una catena di relay.

5. Esempio con IIS ARR e due istanze locali

Questo esempio mostra due applicazioni RestFrontage su una singola macchina Windows. Ogni applicazione utilizza il proprio pool IIS. Il sito di ingresso ARR riceve gli utenti su un indirizzo HTTPS comune.

Elemento	Valore illustrativo
Parlare pubblico	https://portail.example.com
Binding di Sito ARR	Porta HTTPS 443, certificato valido per il nome pubblico
Istanza 1	HTTP, 127.0.0.1:18081
Istanza 2	HTTP, 127.0.0.1:18082
Alias locale dell'istanza 1	application-noeud-1
Alias locale dell'istanza 2	application-noeud-2

5.1 Prepara rivendicazioni e alias

1. Verifica che le porte 18081 e 18082 sono disponibili.
2. Aggiungi un binding HTTP 127.0.0.1:18081 al primo sito IIS, con un nome host vuoto.
3. Aggiungi un binding HTTP 127.0.0.1:18082 al secondo sito IIS, con un nome host vuoto.
4. Conserva eventuali link HTTPS usati per l'accesso diretto.
5. Aggiungi entrambi gli alias al C:\Windows\System32\drivers\etc\hosts, da un editor che funziona come amministratore.

127.0.0.1 application-noeud-1
127.0.0.1 application-noeud-2

ARR utilizza i nomi delle destinazioni per distinguere i membri della farm. Due alias sono usati per rappresentare due applicazioni sullo stesso server su porte diverse.

5.2 Configura le istanze e farma

1. Attiva ReverseProxy in entrambe le istanze con gli indirizzi locali dei loop necessari.
2. Ricicla entrambi i pool di applicazioni.
3. In ARR, aggiungi application-noeud-1 sulla fattoria con la porta HTTP 18081.
4. Aggiungi al carrello application-noeud-2 con porta HTTP 18082.
5. Configura il sito di ingresso HTTPS per mantenere il nome host pubblico e il passaggio X-Forwarded-Proto: https alle destinazioni HTTP.
6. Limita la regola di instradamento al sito di ingresso previsto per questa applicazione.

5.3 Particolarità del test multi-istanza

Per testare le cache di memoria, usa due pool IIS separati per ottenere due processi indipendenti. Vai anche direttamente a ogni istanza per sapere con precisione quale riceve la lettura o la modifica.

Quando lo scenario richiede di passare da un'istanza all'altra dietro ARR, disabilita l'affinità client durante i test. Disabilita anche la cache ARR per osservare la cache dell'applicazione. Queste impostazioni di test non definiscono automaticamente la configurazione da mantenere in produzione.

La condivisione dell'autenticazione, delle chiavi di protezione dati, delle sessioni e di qualsiasi cache distribuita fa parte della configurazione multi-istanze dell'applicazione. Il ReverseProxy non effettua questa condivisione. Due istanze su una singola macchina rimangono indisponibili simultaneamente se quella macchina si spegne.

6. Controllo funzionamento

I seguenti comandi sono per PowerShell sulla macchina che ospita il campione on-local. Visualizzano le intestazioni di risposta senza seguire i redirect.

6.1 Controlla l'accesso diretto HTTP

curl.exe -sS -D - -o NUL http://application-noeud-1:18081/

Questa richiesta non dichiara un HTTPS originale. Se il reindirizzamento HTTPS e la porta di destinazione sono configurati sull'istanza, il reindirizzamento deve rimanere attivo. Abilitazione ReverseProxy non dovrebbe, da solo, trasformare questo accesso HTTP in HTTPS.

6.2 Verifica il riconoscimento del protocollo originale

curl.exe -sS -D - -o NUL -H "X-Forwarded-Proto: https" -H "Host: portail.example.com" http://application-noeud-1:18081/
curl.exe -sS -D - -o NUL -H "X-Forwarded-Proto: https" -H "Host: portail.example.com" http://application-noeud-2:18082/

Queste richieste provengono dal loop locale esplicitamente consentito. Devono raggiungere l'applicazione senza un redirect HTTP alla porta HTTPS interna di un'istanza. Un redirect verso /Login oppure /setup può essere normale a seconda delle condizioni dell'installazione.

6.3 Valida l'accesso pubblico

• Apri l'indirizzo pubblico e verifica il suo certificato HTTPS.
• Verifica che i reindirizzamenti mantengano il nome pubblico, senza alias o porte interne.
• Accedi e sfoglia le pagine e le funzioni utilizzate dai clienti.
• Verifica i cookie e la continuità dell'autenticazione in base alla configurazione multi-istanze scelta.
• Controlla nei log o negli strumenti di monitoraggio quali istanze ricevono le richieste.
• Per i test di cache, modifica un oggetto attraverso un'istanza e poi riproduscilo nell'altra e osserva la propagazione attesa.

7. Diagnosi di una configurazione errata

Sintomo	Audit
L'app non si avvia più dopo l'attivazione	Controlla la validità del JSON, i nomi dei parametri e la presenza di almeno un indirizzo IP valido in KnownProxies.
Un reindirizzamento verso una porta interna persiste	Verifica la versione distribuita, l'attivazione della sezione, il riciclo del pool, l'intestazione trasmessa e l'indirizzo di sorgente proxy visti da RestFrontage.
Appare un loop di reindirizzamento	Controlla il protocollo dichiarato dal proxy e l'ambito della regola di instradamento, specialmente sui siti interni.
Un indirizzo interno appare in un redirect	Verifica che il proxy mantenga il Host pubblico. Il ReverseProxy non tratta X-Forwarded-Host.
Compare un errore di certificato	Controlla il nome coperto dal certificato del link HTTPS in questione. Il ReverseProxy non modifica la validazione del certificato.
Le sessioni si perdono quando si cambia istanze	Verifica l'autenticazione, la protezione dei dati e la configurazione dello storage della sessione.
Un cambiamento rimane invisibile in un'altra istanza	Controlla le cache delle applicazioni, l'invalidazione distribuita, la propagazione degli eventi e qualsiasi cache proxy.

8. Ritorno alla configurazione precedente

Consegna ReverseProxy:Enabled à false, e poi riciclare i pool IIS o riavviare i servizi interessati.

Se il proxy sta ancora inoltrando richieste tramite HTTP, le applicazioni possono reindirizzare alle loro porte HTTPS. Pianifica il corrispondente routing prima di disabilitare questo supporto su un'installazione attiva.

Riferimenti aggiuntivi

• ASP.NET Core dietro un proxy o un bilanciatore di carico
• Elaborazione delle intestazioni da proxy sconosciuti
• IIS ARR con più applicazioni su una sola macchina