Newsgroup: it.tlc.gestori.fastweb
Titolo: Problema RPC

Vorrei sapere se qualcuno ha avuto problemi come client RPC, non riesco più
a sincronizzare outlook con il server exchange. Ho paura che col
blaster.worm e hanno chiuso la porta 135. Qualcuno ha lo stesso problema?

 stesso problema?
I tuoi timori sono fondati = come e' avvenuto in passato (ved. Nimda) FW
ha messo dei filtri nella rete sulla porta RPC 135 usata da OS Windows
come portmapper per i servizi RPC e le applicazioni DCOM.
I filtri sono cmq a livello degli apparati direttamente connessi alla
rete FastWeb = in caso di utenze con CPE/HAG e' sufficiente collocare
switch/router per separare la LAN e utilizzare al suo interno i servizi
RPC.
Se il server Exchange invece fosse esterno alla tua utenza (ed interno
alla rete FastWeb) potresti operare sul registro di client/server per
modificare la porta usata come portmapper = operazione non user-friendly
comunque e valida solo per i client modificati che accedano al server.
-- 
|Ż \/Ż | /Ż\ /Ż__/Ż__|-<|> 
http://planynet.hypermart.net/fastweb
 <|
|Ż|\/|Ż|/Ż_Ż\|(__\__ \-<|> * FAQ 1.4 ITGF it.tlc.gestori.fastweb <|
|_|  |_/_/ \_\___|___/-<|> * SITO: 
http://planynet.hypermart.net
 <|
|>Togli/Remove .INVALID<|> * NEWS: free.it.ingegneria.meccanica _<|


Si la porta e' filtrata

Grazie intanto per la tua risposta, ma avrei due quesiti da porti: pensi che
quando l'emergenza blaster.worm sarŕ finita toglieranno questi filtri?
Da quando ho fastweb che per cercare di lavorare con il server exchange del
mio ufficio, avevo risolto con una brillante vpn/l2tp noipsec e andavo
tranquillo in vpn.
Dopo un mese segata.... ora non va piů o va a tratti
Allora pubblico con isaserver il mio exchange in modo da collegarmici
sull'ip pubblico. e per i file usavo tranquillamente ftp.
Torno dalle ferie niente piů RPC, niente piů ftp se non PASV, ma dico, (e
qui la seconda domanda) pensi che tra poco per le porte diverse da 80
bisognera pagarle a consumo?!
P.S. modificare il portmapper RPC sul server usato da 400 persone,  risulta
pericoloso per la mia incolumitŕ... ;-)
Ciao e grazie anticipatamente.
"Macs" <maxs...@despammed.com.INVALID> ha scritto nel messaggio
news:3F54DF04...@despammed.com.INVALID...


 pericoloso per la mia incolumitŕ... ;-)
In effetti non e' un'impresa facile, visto che richiede modifiche 
(peraltro sconsigliate dalla stessa Microsoft) sia sul server che sui
client -> Microsoft (in architetture di NAT/Firewall) suggerisce di non
modificare il port-mapper ma solo le porte richiamate, oppure di usare
una VPN.


 pericoloso per la mia incolumitŕ... ;-)
Potresti forse, dico forse, modificare le porte di ascolto e redirigere 
quelle vecchie su quelle nuove con delle regole di firewall. In tal 
guisa non sarebbe necessario modificare i client.
-- 
jagui

 redirigere quelle vecchie su quelle nuove con delle regole di firewall
I client sono impostati di default per cercare il portmapper sulla porta
135 del server -> e' possibile fissare staticamente da registro del
server le porte richiamate dal portmapper. Per quanto riguarda RPCSS
invece MS stessa sconsiglia di cambiarne la porta (anche se si puo' fare
a proprio rischio/pericolo).
Un sistema alternativo e' pertanto, come hai visto anche tu, un sistema
di port-redirect -> tuttavia non e' sufficiente lato server ma andrebbe
messo lato client prima della CPE/router FastWeb, e cmq non connesso
direttamente ai dispositivi FastWeb. E' una soluzione semplice se hai
i client in un'unica sede... ma 400 dislocati iniziano a rendere le cose
abbastanza difficili ;).


 messo lato client prima della CPE/router FastWeb
Perche' non e' sufficiente lato server? Cos'e' che mi sfugge? Non sono i 
client che si connettono al server e non viceversa?
-- 
jagui

 Perche' non e' sufficiente lato server? Cos'e' che mi sfugge? 
I client (salvo modifiche) continuano a cercare il RPC Portmapper sulla
porta 135 remota -> visto che i filtri anti-Blaster sono proprio su tale
porta sia in local che in remote per i computer connessi alla rete FW,
una redirezione solo lato server non e' sufficiente.


 porta 135 remota
Devo dormire di piu'...
-- 
jagui

Ciao Macs, l'unico dubbio che mi rimane sul discorso del nat traversal sta
nel fatto che credo sia comunque necessario aggiornare Win2000 a 2003,(lato
server intendo)  almeno per quello che ho letto ieri su una faq microsoft.
Diceva che infatti la patch per il nat t era solo lato client... (premetto
che non ho ancora guardato le nuove faq) quindi non sň se li lo hai
spiegato. Stasera cmq la guarderň.
Hai un idea del perchč la mia vpn l2tp noipsec una volta va e una volta no?
Vorrei tanto una spiegazione, perchč davvero non sono riuscito a darmela!!
Grazie anticipatamente.
"Macs" <maxs...@despammed.com.INVALID> ha scritto nel messaggio
news:3F57D9B6...@despammed.com.INVALID...


P.S.  Sentiti ringraziamenti per il tuo ringraziamento sulle faq!!
Federico M.  PCS
"Macs" <maxs...@despammed.com.INVALID> ha scritto nel messaggio
news:3F57D9B6...@despammed.com.INVALID...


 volta no?
In questo momento penso a problemi di load-balancing e/o timeout sulle
porte = e' stato riscontrato che a volte occorre creare del "traffico
spazzatura" per mantenere attivo il canale (il TCP KeepAlive non serve).
Inoltre c'era il discorso del cambio porta UDP da una sessione ad
un'altra successiva per cui a volte andava e altre no.


 Vorrei tanto una spiegazione, perchè davvero non sono riuscito a darmela!!
Allora il problema si verifica quando c'è carenza di banda. Anche se i 
ping sono buoni (non bisogna superare mai i 100ms tra i due endpoint) se 
,come in questi giorni il flusso va a scatti , la vpn funziona malissimo.
Quando c'è banda in maniera stabile il problema non sussiste.
Anche stamattina la banda va e viene in maniera repentina, se fai dei 
test di continuo vedi come che nel giro di 5 minuti si va da un minimo 
di 45Kb/s a 450-500Kb/s nell'arco di frazioni di minuto.
Hanno proprio dei problemi