BorderManager 3.6 e 3.7


Prestazioni

Se si utilizza un server proxy BorderManager® per ridirigere le richieste al server iFolder, le operazioni di caricamento sul server iFolder sono piuttosto lente.

Per risolvere questo problema, immettere il comando seguente dalla console del server BorderManager:

set tcp delayed ack=off


Connessione di iFolder anche con impostazioni del server proxy autenticato non corrette

Se le impostazioni proxy del client iFolder non sono corrette, il client iFolder tenta di eseguire la connessione direttamente (senza utilizzare il proxy).

Se è abilitato l'inoltro dell'indirizzo IP, quando si utilizza il proxy autenticato gli utenti interni (privati) possono comunque ottenere l'accesso senza fornire le credenziali di autenticazione. Per evitare che ciò si verifichi, è sufficiente accertarsi che l'inoltro dell'indirizzo IP sia disabilitato sul server proxy.


Conflitto delle porte

Quando l'autenticazione proxy è abilitata, la porta di ascolto di default è 443. Se iFolder 2.1 e BorderManager sono in esecuzione sullo stesso server e l'autenticazione proxy è abilitata, iFolder o BorderManager devono utilizzare una porta diversa.


Loopback in NAT

Se iFolder viene eseguito su un segmento di rete privato e l'accesso pubblico è consentito tramite NAT, un indirizzo di accesso pubblico viene specificato nella configurazione del server iFolder. Tutte le richieste indirizzate all'indirizzo privato vengono inoltrate a questo indirizzo pubblico. Quando si tenta di accedere a iFolder dal segmento privato si verifica il problema dell'effetto loopback in NAT e la connessione non viene effettuata.

La soluzione è rappresentata dall'uso di un nome DNS come indirizzo di accesso dell'utente nella configurazione del server iFolder e dalla risoluzione di tale nome nell'indirizzo pubblico per gli utenti esterni e nell'indirizzo privato per gli utenti interni.