Newsgroup: it.tlc.gestori.fastweb
Titolo: nuovo ip fastweb: nat gestito male

Come aveva preannunciato MACS, oggi mi sono ritrovato con un nuovo ip
rilasciato dall'HAG, sulla rete 10.x
La cosa che non mi aspettavo, è che verso altre reti Fastweb vengo visto
con ip 93.x.
E ora la cosa divertente: dalla mia macchina chiamo un server su rete
fastweb. Vengo appunto visto come 93.x e tutto funziona a meraviglia.
Dal server provo a fare traffico verso l'ip pubblico con il quale mi
presento, e ovviamente non funziona nulla.
Dal server provo a fare traffico verso il mio ip privato (10.x) e non
funziona nulla. Ma... sorpresa! Sul mio pc vedo comunque il traffico, al
quale rispondo correttamente. Quindi Fastweb non gestisce correttamente
il "related" delle connessioni. Volutamente o no, non lo so, però mi
sembra un po' una pastrocchiata, soprattutto perché prima da rete
Fastweb ero in grado di chiamare la MAN, ora non posso più...

 Fastweb ero in grado di chiamare la MAN, ora non posso pi�... 

 se tento di connettermi sempre dall'esterno al mio IP "pubblico" 93.
Nada, niente da fare:
13:04:32.080570 89.96.xx.xx.2918 > 10.187.xx.xx.22: S
3813575045:3813575045(0) win 16384 <mss 1460,nop,nop,sackOK,nop,wscale
0,nop,nop,timestamp 
2495053183
 0> (DF) [tos 0x10]
13:04:32.092727 93.36.xx.xx.22 > 89.96.xx.xx.2918: S
463962324:463962324(0) ack 3813575046 win 5792 <mss
1460,sackOK,timestamp 2104062 
2495053183
,nop,wscale 7> (DF)
Come dicevo, nat gestito a pene di segugio.

 al quale rispondo correttamente.
Come hai potuto vedere, il traffico autonomo o di risposta in uscita
dalla tua linea  viene nat-tato di base sull'IP DPPU = solo in alcuni
casi sono applicate routemap policy diverse in funzione della tipologia
di traffico (e.g. per connessioni alla MyFastPage & ad alcuni range IP
pubblici FW e rete KAdu), per cui non vi e' tale NAT e la connessione
risulta provenire dall'IP privato LAN RFC-1918 .
A meno di instaurare il tunnel SSH direttamente dal client MAN, puoi
procedere impostando un ip/port redirect sul tuo endpoint con IP 
Pubblico FW = redirezione IP_DPPU:22->IP_LAN:22 .
Usando ad esempio RINETD 
http://www.boutell.com/rinetd/
 con un file di
configurazione semplice (93.36.*.* 22 10.187.*.* 22), puoi avviare SSH
direttamente verso l'IP DPPU.
In questo modo non risulta piu' il mismatch tra indirizzo destinazione
& indirizzo sorgente ACK, che causa ovviamente il KO con SSH.
-- 
|� \/� | /�\ /�__/�__|<|> *FAX/Mail Server  : 
+39 - 02700426582
 <|
|�|\/|�|/�_�\|(__\__ \<|> *Casella Vocale   : 
+39 - 0230312251
  <|
|_|  |_/_/ \_\___|___/<|> *FAQ ITGF 
http://plany.fasthosting.it
 <|
|>- RST - Plany/MACS -<|> *FAQ GCN  
http://faq.news.nic.it/
 ____<|


Speriamo sia una situzione temporanea ...
Sempre piu' difficile gestire clienti fastweb in remoto . Gi� devo 
tenere su un tunnel apposito , adesso pure i "mismatch" degli ip 
suorce><destination

 ha scritto nel messaggio 
news:4C18C2FB...@despammed.com...


 No-Ip per raggiungere la mia LAN da rete esterna non Fastweb.
Tali servizi servono solo ad effettuare l'associazione dinamica di
record DNS / nomi-host ad indirizzi IP -> la risposta e' quindi negativa
dato che permane il mancato inoltro sull'indirizzo IP privato delle
connessioni autonome in ingresso sull'IP Pubblico DPPU associato
dinamicamente, indipententemente dall'IP sorgente di provenienza della
connessione.
Semmai, se il tuo intento e' quello di far accedere solo tu (o comunque
un numero limitato di utenti) privatamente ai tuoi computer dietro
connessione FW base su IPv4, devi utilizzare altre soluzioni, e.g.:
==
- VPN decentralizzate tipo Hamachi / Wippien
- Avvio di tunnel SSH o SSL (e.g. OpenVPN o CSpace) dai computer su FW
- Relayed tunnel stile LogmeIn / Teamviewer
Se invece volessi pubblicare servizi in esecuzione su tuoi computer su
rete FW (e.g. server HTTP o FTP), potresti optare 
p.es
. per l'uso di
IPv6 (ved. gogoNET/freenet6) in abbinamento ad un servizio di Dynamic
DNS con supporto record A e AAAA (e.g. FreeDNS) & ad un gateway IPv4 to
IPv6 (e.g. SixXS IPv4Gate).
In ogni caso, dato che esistono altri sistemi/workaround, sarebbe utile
che indicassi le tue esigenze correlate a tale accesso dall'esterno
(cioe' ti serve effettuare un controllo da remoto, trasferire dei file,
etc.) -> in questo modo e' possibile verificare quali siano le piu'
adeguate alle tue esigenze.
-- 
|Ż \/Ż | /Ż\ /Ż__/Ż__|<|> *FAX/Mail Server  : 
+39 - 02700426582
 <|
|Ż|\/|Ż|/Ż_Ż\|(__\__ \<|> *Casella Vocale   : 
+39 - 0230312251
  <|


Ciao Macs e grazie per la dettagliata risposta.
Nel dettaglio, fondamentalmente mi farebbe comodo poter accedere 
dall'esterno (tramite port forward da configurare sul router Asus
WL-500W con firmware Oleg) all'interfaccia web di una NAS nella rete
locale di casa, a tutti gli effetti una pagina web su porta 80.
Al momento funziona tutto se mi connetto dall'ufficio (sempre FW)
utilizzando il nuovo IP 10.x.x.x, ma dall'esterno FW nulla da fare
utilizzando il 93.x.x.x.
Tieni presente che non intendo lasciare PC accesi a casa, e tutto
quello di cui dispongo e' appunto il WL-500W linux embedded.
Missione impossibile ?
Grazie
Max
Il 20/06/10 13:09, Macs ha scritto:


 Missione impossibile ?
Impossibile no, semmai complessa - sempre qualora non siano applicabili
al tuo caso ulteriori soluzioni piu' semplici in virtu' di diverse
condizioni di scenario, intervenendo cioe' solo a livello del NAS o
disponendo di un proprio host-ponte per il relay del traffico.
Disponendo di tutte le info (ved. specifiche NAS), e' comunque possibile
non solo individuare le soluzioni applicabili, ma soprattutto valutarle
in un'ottica di confronto/convenienza tra la loro implementazione con
mantenimento di FW come fornitore di connettivita' ed il passaggio ad
altro fornitore/operatore.
