--
questo articolo e` stato inviato via web dal servizio gratuito
http://www.newsland.it/news segnala gli abusi ad ab...@newsland.it
slickfish ha scritto:
>
> ho installato una IP Camera per monitorare l'ingresso in azienda.
> Non riesco ad accedervi dal web in quanto l'HAG di Fastweb non mi
> permette di farlo, ho l'IP dinamico e non mi aprono le porte.
Sarebbe utile che fornissi le seguenti info :
==
1. Produttore/Modello della IP-Cam in questione
2. Parli di LAN aziendale, ma anche di CPE/HAG -> quindi non avresti un
contratto Business/Aziende con router Cisco o GAD Telsey, bensi' uno
SOHO/Microimprese con CPE/HAG. In tal caso i tuoi computer sono
collegati direttamente alla CPE/HAG via cavo e/o wireless (qualora tu
abbia un modello di CPE con AP WiFi integrato), oppure 'in mezzo'
c'e' un tuo router ? -> in caso affermativo, sarebbe utile conoscerne
produttore e modello.
3. Oltre all'IP-cam, che resta ovviamente accesa anche quando non c'e'
nessuno in azienda, c'e' qualche computer che resta sempre acceso ?
> Ho provato anche con DynDNs ma nisba....
Normale = DynDNS serve appunto solo come servizio di associazione
dinamica a livello DNS tra un hostname ed un indirizzo IP, non certo
ad 'aprire le porte' sull'IP pubblico DPPU FW ne' comunque ad 'aggirare'
le questioni relative al NAT Hidden/Dynamic Many-to-Many NO Overload
dell'architettura base delle connessioni FW.
> con il Notebook di mia moglie che quando lavora da casa sfrutta la mia
> LAN ma non fa parte del mio gruppo di lavoro non riesco ad accedervi
Cosa intendi con questo passaggio ? = che tua moglie puo accedere ai
servizi di rete LAN presso la tua azienda in virtu' p.es. di una
soluzione VPN peer-to-peer/NAT-Traversal, oppure altro ?
--
|� \/� | /�\ /�__/�__|<|> *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/ ____<|
ha l'hag di FASTWEB... farebbe prima a farsi mettere una "solo dati" e
attestarvi la camera, costerebbe di meno, andrebbe meglio e non se lo
farebbe mettere in "saccoccia" da pseudo ISP.....
svegliarsi please!!!
[cut]
imho, marca e modello della webcam sono informazioni inutili, cosi'
come eventuale marca/modello del router; quelli di fastweb se li
gestiscono loro, in caso di connettivita' business; in caso di utenze
soho, come mi pare di capire sia il caso in questione, ci si ritrova
con il solo hag e quindi nella situazione tipo un dispositivo in una
rete aziendale il cui router non sia accessibile ne' fisicamente ne'
per amministrazione remota"
Unica possibilita' che mi viene in mente e' tramite hamachi (ma non ho
mai provato) o software tipo teamviewer, con tutte le limitazioni del
caso. In entrambi i casi, serve un pc aziendale acceso e temo qualche
possibile ripercussione sulla sicurezza.
Adriano
Chiedi a Fastweb quanto vuole per assegnarti un ip pubblico.
Il problema non � avere un ip dinamico ma essere sulla rete privata fastweb
che non ti consente visibilit� dall'esterno.
Questa � la via pi� breve.
Stefano
adriano ha scritto:
>
> imho, marca e modello della webcam sono informazioni inutili, cosi'
> come eventuale marca/modello del router; quelli di fastweb se li
> gestiscono loro
IMHO invece un po' di cose :
==
1. Non tutte le IP-Cam sono uguali, per cui puo essere utile sapere cosa
supporti o meno = HTTP-Streaming, FTP-Upload, gestione tramite
apposito SW da pc, motion-capture, invio istantanee via email, etc. .
2. Se leggi bene, non gli chiedo il modello di CPE/HAG (che puo essere
Telsey o Pirelli, o ora altro ancora, ma non importa) = gli chiedo se
- visto che parla di LAN aziendale in presenza di una CPE/HAG (e
quindi contratto SOHO/Microimpresa, mica PMI/Medium con router Cisco
o GAD Telsey...) - abbia un suo router o meno 'a valle' della CPE/HAG
e - in caso affermativo - di fornirne produttore/modello.
3. In seguito all'introduzione dell'IP Pubblico statico (realizzato
tramite NAT 1:1) anche per le utenze SOHO/Microimprese con CPE/HAG,
sono cambiate le condizioni del servizio addizionale IP Pubblico
(che prima era limitato al solo IPPD) = puo essere quindi utile
verificare anche p.es. se egli usufruisca di promo (o meno) sul nuovo
servizio IP statico (visto che il relativo costo e' di 12 Euro + IVA
mensili).
4. Raccogliere il maggior numero di informazioni aiuta sempre ad avere
un quadro il piu' completo possibile del problema e dello scenario
in cui si riscontra -> tutto cio' torna utile proprio ad individuare
quelle soluzioni, che possano essere piu' adeguate/ottimali.
> Unica possibilita' che mi viene in mente e' tramite hamachi (ma non ho
> mai provato) o software tipo teamviewer, con tutte le limitazioni del
> caso. In entrambi i casi, serve un pc aziendale acceso e temo qualche
> possibile ripercussione sulla sicurezza.
Il ricorso a soluzioni di VPN P2P/NAT-Traversal (Hamachi, Wippien, et
similia), piuttosto che a soluzioni di controllo remoto (Teamviewer,
LogmeIn, e altre SSL-based) e' una (non l'unica) possibilita'/soluzione,
ed infatti - anche per quello gli ho chiesto se ci fosse un computer
sempre acceso.
Per il resto, vediamo cosa rispondera' slickfish e quali info/dettagli
fornira' sulla situazione.
> IMHO invece un po' di cose :
certo, tutte cose utili, ma dopo che ha potuto raggiungere il
dispositivo. Finche' quello non e' raggiungibile (tipico con fastweb)
tutto il resto passa in secondo piano
> - visto che parla di LAN aziendale in presenza di una CPE/HAG (e
> quindi contratto SOHO/Microimpresa, mica PMI/Medium con router Cisco
> o GAD Telsey...) - abbia un suo router o meno 'a valle' della CPE/HAG
> e - in caso affermativo - di fornirne produttore/modello.
per quello che mi risulta, il router a valle ti serve per collegare iu'
dispositivi "gabbando" il limite imposto da fastweb. Ma il problema e'
che la sua connessione sara' con tutta probabilita' nattata, quindi
diventa inutile (a questo stadio) impostare un port forwarding sul suo
eventuale router, qualunque esso sia.
> Il ricorso a soluzioni di VPN P2P/NAT-Traversal (Hamachi, Wippien, et
> similia), piuttosto che a soluzioni di controllo remoto (Teamviewer,
> LogmeIn, e altre SSL-based) e' una (non l'unica) possibilita'/soluzione,
> ed infatti - anche per quello gli ho chiesto se ci fosse un computer
> sempre acceso.
> Per il resto, vediamo cosa rispondera' slickfish e quali info/dettagli
> fornira' sulla situazione.
vedremo...imho pero' con fastweb ci si complica sempre la vita, quando
dovesse servire una qualsiasi applicazione server
Adriano
adriano ha scritto:
>
> certo, tutte cose utili, ma dopo che ha potuto raggiungere il
> dispositivo.
Proprio no = considerando la sola IP-Cam (quindi senza prendere in
esame computer accesi d'appoggio o eventuali router interposti tra LAN
e CPE/HAG), trascuri p.es. 2 tra i possibili scenari workaround :
==
A. Le Network CAM anche di fascia bassa integrano un client FTP, che puo
inviare i frame catturati in funzione delle opzioni di motion
detection e di delay/send -> utilizzando uno spazio FTP e una
pagina web (con autenticazione forte tramite .htaccess/.htpasswd se
possibile, o debole con javascript, nel caso di server esterno), e'
quindi possibile visualizzare da fuori della rete FW i capture della
Network CAM.
Cio' non solo in statico (archivio remoto di frame catturati con
relativo timestamp), ma anche in dinamico, tarando opportunamente le
opzioni di invio dei frame e di HTTP-refresh della pagina = e.g. 5
secondi per l'auto-refresh nel codice della pagina web & 3+1 secondi
nelle opzioni di delay/send della cam.
B. Network CAM di fascia media/alta integrano anche p.es. stack IPv6
e/o supporto VPN client/endpoint -> se la network cam di slickfish
soddisfacesse le condizioni per effettuare connessioni in uscita su
IPv6 o instaurare tunnel VPN dietro al Dynamic/Hidden NAT M-M NO
Overload dell'architettura base FW, allora si potrebbe usare proprio
quel 'tunnel' in uscita verso un endpoint esterno comodo, onde
encapsularvi lo streaming della ip-cam.
La soluzione A e' applicabile con qualsiasi network cam 'non fuffatech',
la B con meno prodotti -> pertanto, non e' poi cosi' una brutta idea
scoprire prima quali siano il produttore ed il modello della Network
Cam.
> per quello che mi risulta, il router a valle ti serve per collegare
> iu' dispositivi "gabbando" il limite imposto da fastweb. Ma il
> problema e' che la sua connessione sara' con tutta probabilita'
> nattata, quindi diventa inutile (a questo stadio) impostare un port
> forwarding sul suo eventuale router, qualunque esso sia.
Cosa c'entra il port-forwarding di un eventuale router ? = mica ho
chiesto se c'e' un eventuale router interposto tra CPE/HAG e LAN per
sapere come gestisca il NAT/PAT tra le sue interfacce LAN/WAN...
Visto che il discorso di slickfish e' relativo ad una connessione usata
in ambito SOHO/professionale, non posso semmai escludere a priori che,
qualora slickfish abbia interposto un router, questo non possa essere
anche un modello destinato al mercato SOHO/Office e con funzioni piu'
avanzate (rispetto a quelli Home) e.g. per gestione firewall e supporto
VPN client/endpoint.
Se slickfish disponesse p.es. di un router, che potesse instaurare un
tunnel VPN dalla sua connessione FW verso un endpoint esterno, si
avrebbe un tunnel utilizzabile non solo per accedere all'IP-cam, ma
anche al resto di computer/apparati in LAN.
> vedremo...imho pero' con fastweb ci si complica sempre la vita, quando
> dovesse servire una qualsiasi applicazione server
A livello professionale e business/aziendale FW non c'e' niente di
tecnicamente complicato = e' solo una questione di valutazione dei costi
visto che c'e' la possibilita' di disporre di IP pubblico statico, oltre
che di subnet nel caso delle utenze PMI/Medium/TOP.
I workaround tecnici servono semmai realmente solo nel caso delle utenze
residenziali, qualora il bundle delle 20 ore mensili di IP Pubblico
Dinamico non sia applicabile al loro profilo contrattuale e/o non sia
compatibile con le loro esigenze di visibilita' dall'esterno della rete
FW.
Per il resto, le cose complicate sono solo complicate, non impossibili.
Prima si individuano soluzioni/workaround, poi se ne esegue lo studio di
fattibilita' sullo scenario in esame.
Tradotto in soldoni, le informazioni chieste mi servono proprio per
inquadrare quali siano quelle soluzioni, che non comportino alcun costo
addizionale & siano applicabili alla situazione di slickfish.
In questo modo - una volta indicate - slickfish potra' valutarle, e
decidere se prenderle in esame o puntare su strade alternative, e.g.:
==
- Mantenere la connessione FW SOHO e richiedere l'IP Pubblico statico
- Rivolgersi ad un altro provider per la connettivita'
Mamma mia...
scusa... ma non puoi scendere un attimo sulla terra e parlare in un linguaggio
che non sia cosi' vicino al codice-macchina?
Non puoi parlare con uno sconosciuto e sciovinare mitraglie di sigle e parolette/one
in inglese.. ti seguono in pochi poi...
Normale , da remoto bisogna andare su una pagina dedicata del sito FW myf.page
e attivare di volta in volta una sessione di ip pubblico -a pagamento- che viene penso
inclusa in bolletta, ocio ai prezzi, scomodissimo lo so, dovrebbero avvisare di 'ste cose
la fw..
> Ho provato anche con DynDNs ma nisba....
> Dalla LAN aziendale non ci sono problemi, ma con il Notebook di mia moglie
> che quando lavora da casa sfrutta la mia LAN ma non fa parte del mio
> gruppo di lavoro non riesco ad accedervi, come posso fare?
> Grazie.
> Sam
Il gruppo di lavoro non centra niente, non stai accedendo a risorse windows, ma bensi a
un sever web o uno dedicato se si usa un programma div. dal browser..
credo invece che ci sia un filtro che impedisce al n.book di vedere l'ip della camera,
prova a fare da prompt comandi "ping -ip della camera-" e vedi se risponde..
oppure se la ip camera sfrutta altre porte oltre quella 80 del web il n.book potrebbe
avere firewall con porta chiusa da aprire..
"Dav.p." ha scritto:
>
> Non puoi parlare con uno sconosciuto e sciovinare mitraglie di sigle e
> parolette/one in inglese.. ti seguono in pochi poi...
Esagerato ;) = le espressioni 'critiche' sono semmai tre in numero (il
resto e' scritto in vocaboli appartenenti alla lingua italiana e/o
ritrovabili senza difficolta' in dizionari recenti - non necessariamente
tecnici - in formato cartaceo/elettronico) :
==
- hostname = stringendo banalmente, si puo definire come quel nome, che
identifica un computer/apparato in una rete .
- DPPU = Distributed Pay Per Use -> le info sugli IP Pubblici DPPU FW
sono reperibili p.es. su http://plany.fasthosting.it/dppupool.html .
- NAT Hidden/Dynamic Many-to-Many NO Overload = tipologia di Dynamic
NAT dove piu' indirizzi privati/interni sono associati ad altrettanti
indirizzi IP pubblici/globali in modo esclusivo/univoco. In precedenza
FW adottava la stessa tipologia con Overload (Architettura IPPU) = ad
un singolo IP pubblico risultavano associati tramite NAT piu' IP
privati/riservati.
Per il resto :
==
1. Questo non e' un newsgroup francese, per cui non dovrebbe cascare il
mondo, usando anche terminologia tecnica in lingua inglese (specie
in quei casi dove risultasse piu' criptico l'autartico tentativo
di traduzione in lingua italiana).
2. Una volta - se/quando si ignorava il significato di un vocabolo - si
consultavano dizionari/enciclopedie ed eventualmente si chiedevano
(senza vergogna) spiegazioni all'interlocutore = tale prassi di
apprendimento e' indipendente dal fatto che dizionari/enciclopedie in
formato cartaceo siano stati accantonati in favore di altri strumenti
telematici (e.g. motori di ricerca e Wikipedia).
ma questo = e' un tic o vuol dire qualcosa? :)
> ==
> - hostname = stringendo banalmente, si puo definire come quel nome, che
> identifica un computer/apparato in una rete .
>
> - DPPU = Distributed Pay Per Use -> le info sugli IP Pubblici DPPU FW
> sono reperibili p.es. su http://plany.fasthosting.it/dppupool.html .
>
> - NAT Hidden/Dynamic Many-to-Many NO Overload = tipologia di Dynamic
> NAT dove piu' indirizzi privati/interni sono associati ad altrettanti
> indirizzi IP pubblici/globali in modo esclusivo/univoco. In precedenza
> FW adottava la stessa tipologia con Overload (Architettura IPPU) = ad
> un singolo IP pubblico risultavano associati tramite NAT piu' IP
> privati/riservati.
>
basta ho bisogno di una trasfusione.. quel "Many-to-Many" mi ha sfiancato..
cmq se hai letto il mio altro post penso che la questione fosse molto + semplice
del "Many-to-Many " o come si chiama...
> basta ho bisogno di una trasfusione.. quel "Many-to-Many" mi ha sfiancato..
> cmq se hai letto il mio altro post penso che la questione fosse molto +
> semplice del "Many-to-Many " o come si chiama...
nell'informatica ci sono tantissime sigle. Spero che non pretenderai di
frequentare un ng come it.comp.reti.locali evitando le sigle.
Adriano
"Dav.p." ha scritto:
>
> basta ho bisogno di una trasfusione.. [...]
Ti serve solo eventualmente documentarti & imparare, qualora tu ne abbia
ovviamente ancora la voglia.
> cmq se hai letto il mio altro post penso che la questione fosse molto
> + semplice del "Many-to-Many " o come si chiama...
Non sei documentato/informato sull'architettura della rete FW (oltre che
su altre questioni tecniche legate all'ambito reti) = quando si vogliono
esprimere giudizi tecnici - e chiarisco che lo dico/scrivo senza alcun
intento malevolo nei tuoi riguardi - e' il caso che si disponga anche di
un bagaglio di conoscenze/competenze tecniche sulla materia oggetto di
discussione, altrimenti si rimane nell'ambito di "chiacchiere da bar".
L'IP Pubblico Dinamico IPPD FW non sarebbe p.es. peraltro la prima
soluzione indicabile a slickfish per la sua situazione in virtu' di :
==
1. Fattori economici = slickfish usa una connessione SOHO/Microimprese
FW, per cui - se proprio non volesse ricorrere a workaround tecnici a
zero costi addizionali - potrebbe semmai sottoscrivere la nuova
opzione IP Pubblico Statico per SOHO/Micromprese (12 Euro+IVA/mese),
che e' senz'altro economicamente piu' convenienti delle sessioni di
IPPD.
2. Fattori tecnici del periodo = questo non e' esattamente il momento
migliore per usare IPPD in virtu' della serie di disservizi, che da
meno di 1 mese stanno impattando tale piattaforma -> vi sono alcuni
primi avvisi di rientro dei problemi, ma mancano ancora conferme
ufficiali lato FW e/o ufficiose su Internet/Usenet da parte delle
utenze, che avevano fatto le diverse segnalazioni di KO/anomalie.
preferiresti che al posto di NAT si dicesse "traduzione di indirizzo di
rete"? imho ogni campo ha i suoi termini, e vanno usati.
Adriano
mmmh poco per volta magari..
> > cmq se hai letto il mio altro post penso che la questione fosse molto
> > + semplice del "Many-to-Many " o come si chiama...
>
> Non sei documentato/informato sull'architettura della rete FW (oltre che
> su altre questioni tecniche legate all'ambito reti) = quando si vogliono
> esprimere giudizi tecnici - e chiarisco che lo dico/scrivo senza alcun
> intento malevolo nei tuoi riguardi - e' il caso che si disponga anche di
> un bagaglio di conoscenze/competenze tecniche sulla materia oggetto di
> discussione, altrimenti si rimane nell'ambito di "chiacchiere da bar".
i news sono un po' un bar da chiacchera.. non penso che se il 'capo' ha
un problema con i computer dice all'addetto, 'se non riesci vai sul newsgroup'...
>
> L'IP Pubblico Dinamico IPPD FW non sarebbe p.es. peraltro la prima
> soluzione indicabile a slickfish per la sua situazione in virtu' di :
> ==
> 1. Fattori economici = slickfish usa una connessione SOHO/Microimprese
> FW, per cui - se proprio non volesse ricorrere a workaround tecnici a
> zero costi addizionali - potrebbe semmai sottoscrivere la nuova
> opzione IP Pubblico Statico per SOHO/Micromprese (12 Euro+IVA/mese),
> che e' senz'altro economicamente piu' convenienti delle sessioni di
> IPPD.
tutto qui? Beh se l'avevi gia' detto non ci ero arrivato, sono rimasto tramortito prima..
beh se costa cosi'poco allora faccia un cambio di profilo (30 eu.) non andra' in malora,
meglio cosi' ovvio, io sono rimasto che fw non faceva ip statici, ma posso non ricordarmi...
> 2. Fattori tecnici del periodo = questo non e' esattamente il momento
> migliore per usare IPPD in virtu' della serie di disservizi, che da
> meno di 1 mese stanno impattando tale piattaforma -> vi sono alcuni
> primi avvisi di rientro dei problemi, ma mancano ancora conferme
> ufficiali lato FW e/o ufficiose su Internet/Usenet da parte delle
> utenze, che avevano fatto le diverse segnalazioni di KO/anomalie.
beh qui andiamo sul sottile, che non sia un bel sistema con FW lo si sa,
infatti io se devo far installare un sistema 'remotabile' gli dico se vuoi FW
sono .azzi tua...
"Dav.p." ha scritto:
>
> i news sono un po' un bar da chiacchera..
E' anche vero che la metafora dell'ingresso in un bar si applica alle
modalita' di accesso e partecipazione ai gruppi di discussione, ma cio'
non significa proprio p.es. che nei gruppi tecnici (ved. relativo
manifesto) si debbano fare prevalentemente 'chiacchiere da bar'.
Nel caso specifico di questo newsgroup (oltre che degli altri nella
sotto-gerarchia it.comp.reti.*) e' ben evidente la caratterizzazione
tecnica degli argomenti trattati :
==
- http://www.news.nic.it/gruppi-it.html
> non penso che se il 'capo' ha un problema con i computer dice
> all'addetto, 'se non riesci vai sul newsgroup'...
In primis - considerando un tale scenario capo/subordinato - il 'boss'
sollecita prevalentemente la risoluzione senza vincolarti a come/dove
reperirla.
In secondo luogo valuti l'utilizzo dei newsgroup solo dal tuo punto di
vista, trascurando quanti professionisti accedano anche a gruppi tecnici
di discussione (non solo sulla gerarchia it.*) ed a technical forum
(ufficiali e non) su Internet, proprio per reperire ulteriori info e/o
confrontarsi sulla validita' di soluzioni in merito a tematiche
tecniche di applicazione in ambito professionale (e non domestico).
> beh se costa cosi'poco allora faccia un cambio di profilo (30 eu.) non
> andra' in malora, meglio cosi' ovvio,
L'adeguamento contrattuale di un'utenza SOHO/Microimprese per l'IP
Statico e' necessario solo qualora non sia possibile l'associazione
contrattuale al suo attuale profilo commerciale.
In caso contrario, lo puo richiedere & attivare senza nessun problema.
> io sono rimasto che fw non faceva ip statici, ma posso non
> ricordarmi...
[...]
> se devo far installare un sistema 'remotabile' gli dico se vuoi FW
> sono .azzi tua...
Indipendentemente dagli scenari di soluzioni/workaround a disposizione,
tu valuti l'offerta FW plausibilmente solo dal tuo punto di vista ed in
base alle tue (ristrette) conoscenze, per cui consideri solo l'ambito
residenziale (e tutt'al piu' i vecchi piani SOHO/Microimprese).
A parte il fatto che le condizioni tecniche/commerciali di fornitura
non sono fisse/immutabili nel tempo (ved. appunto contratti SOHO), le
linee FW non sono solo quelle con CPE/HAG.
Considerando p.es. le linee business/aziendali (cioe' a partire dai
profili PMI/Small con router Cisco o GAD Telsey in su), non vi sono mai
stati problemi a disporre di IP pubblici statici singoli o su subnet.
Attualmente le uniche utenze FW, che non possono disporre di IP Pubblico
statico permanente, sono solo quelle residenziali = per loro FW prevede
commercialmente solo le sessioni dinamiche IPPD con limitazioni tecniche
(e quindi non legate solo ai costi) sulla durata continuativa della
singola sessione.
o mi ricordo male o sono cambiate le cose negli anni o sono stato informato male
da uno che conosco che ha contattato f.web x questo, meglio cosi'..
"Dav.p." ha scritto:
>
> sono cambiate le cose negli anni
Sono cambiate, anche se FW ha impiegato piu' di 6 anni per convincersi
dell'improponibilita' commerciale del servizio IP Pubblico Dinamico alle
utenze SOHO, e quindi offrire a queste ultime l'opzione IP Pubblico
Statico ad un costo, che non fosse inaccettabile.
Le utenze SOHO/Microimprese - pur avendo la medesima architettura
tecnica di linea di quelle residenziali - non hanno infatti mai potuto
usufruire delle medesime condizioni commerciali per l'utilizzo del
servizio IP Pubblico Dinamico IPPD.
Da quando e' stato commercializzato il servizio IPPD (Ottobre 2002) le
utenze residenziali con connessione flat hanno sempre avuto il bundle
con l'attivazione gratuita & la possibilita' di effettuare sessioni IPPD
fino a 20 ore mensili senza sostenere costi addizionali, mentre le SOHO
no.
Il servizio IPPD non infatti e' mai risultato interessante per le utenze
SOHO proprio in virtu' dei costi = 12.50 Euro + IVA quota attivazione,
ai quali si devono aggiungere i costi variabili 0.4167 Euro + IVA / ora
o 3.34 Euro + IVA / giorno per sessioni continuative non superiori ai 10
giorni.
rispetto alle residenz. magari, ma un ip statico non ha un costo maggiore per un ISP?
Perche' non dare il dinamico ma almeno pubblico al prezzo dei residenz.?
Quello statico lo sfruttano in pochi penso, proprio perche' le apparecchiature di videosorvegl.
da molto ormai supportano tramite Dyndns etc gli ip dinamici..
> Il servizio IPPD non infatti e' mai risultato interessante per le utenze
> SOHO proprio in virtu' dei costi = 12.50 Euro + IVA quota attivazione,
> ai quali si devono aggiungere i costi variabili 0.4167 Euro + IVA / ora
> o 3.34 Euro + IVA / giorno per sessioni continuative non superiori ai 10
> giorni.
'mappate..
Molto semplice come risposta: utilizzare pochi ip pubblici e sfruttare
sottoreti permette a fastweb di spendere relativamente poco e acquisire una
marea di utenze con lo stesso ip. Gli ip pubblici hanno un elevato costo per
un isp e, in effetti, la stragrande maggioranza delle persone che conosco
non sa neppure cosa sia un ip dinamico, figuriamoci la differenza tra un ip
pubblico ed un privato.
Chiaro che dal punto di vista economico non c'ᅵ paragone per un isp.
Tanto per dirtene una, ho un amico che ha recentemente preso una telecamera
su ip come la tua ed ᅵ utente fastweb residenziale. Ha cambiato casa e ha
riacquistato fastweb residenziale fregandosene della sua non raggiungibilitᅵ
dall'esterno. Si accontenta di usare la funzione di rilevazione di movimento
della network camera che ᅵ settata per inviare emails nel caso si attivi.
Potremmo sindacare sull'utilitᅵ o meno della telecamera ma lui afferma che
gli ᅵ sufficiente cosᅵ, sfruttandola a metᅵ delle sue potenzialitᅵ.
Questa ᅵ l'utenza standard.
Poi esistono quelli che, come te, mutano nel tempo le proprie esigenze e
allora non rimane altro da fare che o passare a fastweb business oppure
cambiare gestore, il che secondo me ᅵ economicamente piᅵ vantaggioso.
Condividere lo stesso ip con centinaia di altri utenti ha anche altri
svantaggi, ad esempio rischiare di essere bannati, da amministratori di reti
molto sbrigativi, in caso di abuso ripetuto della rete, quale spamming,
attacchi dos eccetera.
Chiaramente IMHO,
Stefano
"Dav.p." ha scritto:
>
> un ip statico non ha un costo maggiore per un ISP?
Vi sono dei costi (e.g. iscrizione RIPE http://www.ripe.net/membership )
ovviamente per i provider, ma non ve ne sono di specifici d'acquisto per
l'assegnazione di range di IP pubblici dai registrar RIR = l'ISP fa la
richiesta al Regional Registry di competenza e - qualora vi sia l'OK con
i requisiti previsti/indicati (e.g. tecnici per la gestione dei nuovi
range & numero di utenti finali, che giustifichi la richiesta) - gli
viene assegnata la subnet richiesta, altrimenti una di dimensioni minori
o 'ciccia'.
In realta' quindi il provider non sostiene costi differenziati per gli
IP in virtu' della loro destinazione agli utenti finali -> il costo per
l'utente e' determinato in base ai servizi di annunciazione/routing &
al fatto che stia allocando risorse in modo fisso ad utenti specifici (e
quindi non siano p.es. disponibili come indirizzi dinamici per altri
utenti finali).
Nel caso delle utenze SOHO FW il costo dell'opzione IP Statico risulta
piu' alto di opzioni analoghe di altri gestori, in quanto va considerato
anche il ricarico legato alla raggiungibilita' dall'esterno della rete
FW (che sugli IP Pubblici Dinamici DPPU base e' preclusa) = FW considera
ancora la connettivita' diretta IP end-to-end come un servizio plus, che
possa essere usato per ricavarci redditivita' (mentalita' da Telco,
piuttosto che da ISP).
> Perche' non dare il dinamico ma almeno pubblico al prezzo dei
> residenz.?
Immagino tu volessi scrivere semmai :
==
"Perche' non dare alle utenze SOHO il servizio IP Pubblico Dinamico a
condizioni di prezzo in linea con quelle dei residenziali ?"
La domanda andrebbe girata direttamente a FW, ma potrei provare comunque
con alcune risposte, e.g.:
==
1. Il bundle gratuito per i residenziali era bene/male necessario = le
ore mensili concesse non sono molte, ma si sono rivelate sufficienti
per 'trattenere' quelle utenze residenziali, che avevano un'esigenza
minima/saltuaria di connettivita' diretta IP end-to-end.
2. FW sapeva - definendo sin da subito il bundle gratuito per le utenze
residenziali flat - che queste avrebbero 'maniacalmente' evitato lo
sforamento delle 20 ore mensili IPPD.
Ergo, era necessario ricaricare i costi sulle altre tipologie di
utenze, che architetturalmente avrebbero potuto usare IPPD, cioe' le
SOHO.
3. Mantenere alto il costo IPPD per le offerte SOHO e' servito anche
come strumento commerciale per promuovere le offerte PMI base,
dirottando su queste ultime le utenze professionali, che volevano
sottoscrivere offerte FW con 2 linee telefoniche & disporre di IP
pubblico statico con connettivita' diretta IP end-to-end.
>Sono ormai quasi 9 mesi che non esiste piu' la questione di condivisione
>dell'IP pubblico di uscita per l'architettura base FW :
==
-----
Esiste ma solo per utenze residenz. mi sembrava, peraltro continuo a vedere
altri pc nella sottorete fw, solo stranamente non riesco + a vedere i files degli
altri.. (sono abbonato a fw..)
"Dav.p." ha scritto:
>
> Esiste ma solo per utenze residenz. mi sembrava
La migrazione IPPU->DPPU ha coinvolto tutte le utenze, che prima
'uscivano dalla rete FW' con IP pubblici IPPU condivisi = ergo, da 9
mesi l'architettura DPPU di IP Pubblico Dinamico di uscita univoco vale
per utenze tanto Residenziali quanto SOHO.
Prova a collegare un altro computer alla tua CPE/HAG -> a quel punto da
entrambi i pc vai p.es. su http://www.whatismyip.com = vedrai che sono
assegnati 2 IP Pubblici DPPU distinti.
Poi attendi 10 minuti senza effettuare connessioni fuori dalla rete FW
e verifica nuovamente = li vedrai variare, proprio perche' sono di
natura dinamica le associazioni univoche tra IP riservato MAN & IP
Pubblico DPPU.
> peraltro continuo a vedere altri pc nella sottorete fw, solo
> stranamente non riesco + a vedere i files degli altri.. (sono abbonato
> a fw..)
La migrazione non ha modificato l'architettura MAN degli indirizzamenti
IP interni alla rete FW -> per quanto riguarda la visibilita' a livello
SMB/NetBios da tempo esistevano dei filtri per le connessioni verso
alcune porte remote su TCP (e.g. 135 - 139 - 445), ma non venivano
sempre applicati (a seconda del POP di attestazione) per gli IP di
destinazione appartenenti al medesimo range /24 (subnet 255.255.255.0).
Fw ha corretto anche questa situazione, per cui la visibilita' a livello
MAN su NetBios/SMB e RPC e' consentita solo all'interno del proprio
pool utenza (cioe' gli indirizzi IP MAN assegnabili tramite DHCP dalla
tua CPE/HAG).
Per quanto riguarda la tua appartenenza alla rete MAN FW, non c'e'
bisogno che tu lo scriva esplicitamente ;) = secondo i dati raccolti
negli anni dal sottoscritto, l'IP MAN con cui posti su Usenet ti
identifica a livello della MAN Milano 1.x.x.x/8 come utenza ADSL sulla
subnet 1.244/16 & quindi attestata sull'asse Nord-Ovest (comuni intorno
al tracciato dell'Autolaghi per intenderci).
> Per quanto riguarda la tua appartenenza alla rete MAN FW, non c'e'
> bisogno che tu lo scriva esplicitamente ;) = secondo i dati raccolti
> negli anni dal sottoscritto, l'IP MAN con cui posti su Usenet ti
quali anni quali dati? Vabbe' fa niente.. guardi i dati degli utenti?
Ma a che servira'...? Come in "one hour photo"..?
Hai spulciato pure nei file magari se sei pure tu utente fw, non hai mai trovato
qualche codice di carta di credito?
"Dav.p." ha scritto:
>
> quali anni quali dati?
Sono ormai piu' di 6 anni che ho messo online una piattaforma pubblica,
che serve per tenere traccia delle associazioni MAN/NAT FW :
==
- http://plany.fasthosting.it/ipmapfw2.shtml
- http://plany.fasthosting.it/dbmap.asp
Il sistema funziona tramite un modulo inviabile dall'utente, che
raccoglie alcuni dati rilevati in automatico :
==
- IP Pubblico di uscita
- IP MAN
- Tecnologia della linea
==
e altri, che possano servire a fornire una correlazione piu' precisa
(e.g. comune/ubicazione geografica e tipologia contrattuale).
I dati vengono elaborati periodicamente, generando report pubblici (ved.
link nella pagina del modulo) -> in tali report non sono ovviamente
presenti riferimenti, che possano consentire a terzi un'identificazione
delle utenze, che hanno spedito i moduli (vedasi p.es. mascheramento
dell'ultimo ottetto dell'IP MAN).
Attualmente e' in corso il processo di analisi/elaborazione dei moduli
pervenuti a partire da Marzo 2009, cioe' in seguito alla migrazione
IPPU->DPPU, onde valutare con attenzione gli schemi di correlazione tra
gli IP MAN e gli IP Dinamici DPPU & individuare eventuali logiche ancora
piu' specifiche di quelle basate su MAN di appartenenza & POP FW di
attestazione della linea :
==
- http://plany.fasthosting.it/dppupool.html
> Ma a che servira'...?
Negli anni tali report sono serviti per vari usi = da studi specifici
sull'architettura NAT-ted base della rete FW (ved. schemi di rotazione
in funzione del load-balancing sulle interfacce MSFC di NAT) & le sue
variazioni nel corso degli anni, all'utilizzo da parte di sysadmin su
altre reti per filtraggio e/o gestione delle connessioni provenienti da
rete FW.
> Hai spulciato pure nei file magari se sei pure tu utente fw, non hai
> mai trovato qualche codice di carta di credito?
No, visto che non sono ne' un ragazzino imbecille ne' un criminale.