Hamster e due schede di rete

[Camaleonte]

Ho installato e configurato un'altra scheda di rete sullo stesso server
ibm, dove è installato hamster. La seconda scheda rete va su una rete
con diversa subnet, ma sostanzialmente è sempre una 10.x.x.x

Vedo l'altra rete, ma hamster non funziona più. Appena disabilito la
scheda hamster ritorna funzionante.

Tra l'altro, anche se non è necessario, nel file hostIPaccess (non
ricordo bene come si chiama) la nuova rete è compresa. La nuova scheda
inoltre non interagisce con hamster, ma serve per altro scopo.

Mi aiutate? :-)

[Omero]

Post by Camaleonte
Ho installato e configurato un'altra scheda di rete sullo stesso server
ibm, dove è installato hamster. La seconda scheda rete va su una rete
con diversa subnet, ma sostanzialmente è sempre una 10.x.x.x
Vedo l'altra rete, ma hamster non funziona più. Appena disabilito la
scheda hamster ritorna funzionante.
Tra l'altro, anche se non è necessario, nel file hostIPaccess (non
ricordo bene come si chiama) la nuova rete è compresa. La nuova scheda
inoltre non interagisce con hamster, ma serve per altro scopo.
Mi aiutate? :-)

Ciao

Non so cosa sia Hamster ma il problema può essere dovuta al gateway?
hai mica impostato il gateway su entrambe le schede?
Hamster deve andare in internet? se si lascia l'ip del gateway solo
nella scheda di rete connessa al router/gateway.

Non so che sistema operativo usi ma su windows in alternativa puoi
bindare una delle due schede dalla avanzate > impostazioni avanzate
dalla schermata connessioni di rete, in pratica au connessioni devi
spostare verso l'alto la connessione di rete predefinita che deve
accedere ad internet.

Ciao

[Camaleonte]

Post by Omero
Non so cosa sia Hamster ma il problema può essere dovuta al gateway?
hai mica impostato il gateway su entrambe le schede?
Hamster deve andare in internet? se si lascia l'ip del gateway solo
nella scheda di rete connessa al router/gateway.

hamster è un server di news e posta che funziona benone, ma non va in
internet, mi gestisce solo la parte interna della rete.

Si, ho impostato il gateway su entrambe le schede, che sono diversi,
perché sono due reti diverse. Esempio: La prima è 10.190.5.x la seconda
10.190.6.x. Se lascio solo ip della prima scheda, poi non vedo gli altri
pc, il gateway mi serve proprio per vederli.

Post by Omero
Non so che sistema operativo usi ma su windows in alternativa puoi
bindare una delle due schede dalla avanzate > impostazioni avanzate
dalla schermata connessioni di rete, in pratica au connessioni devi
spostare verso l'alto la connessione di rete predefinita che deve
accedere ad internet.

Ho windows2003 server. Posso provare lo stesso a fare questa operazione,
oppure potrei aggiungere alla seconda scheda, nelle proprietà avanzate,
un secondo gateway, quello della prima, togliendolo del tutto dalle
proprietà della seconda.

Per intenderci, è il primo gateway che mi lascia uscire in internet, il
secondo solo per vedere l'altra rete.

ciao :-)

[Omero]

Post by Camaleonte
hamster è un server di news e posta che funziona benone, ma non va in
internet, mi gestisce solo la parte interna della rete.

Ok

Post by Camaleonte
Si, ho impostato il gateway su entrambe le schede, che sono diversi,
perché sono due reti diverse. Esempio: La prima è 10.190.5.x la seconda
10.190.6.x. Se lascio solo ip della prima scheda, poi non vedo gli altri
pc, il gateway mi serve proprio per vederli.

qui c'è qualche cosa che non va :-)

il gateway ti serve solo per andare in internet e quindi lo devi
mettere solo nella scheda che è connessa con il router/gateway

per accedere ai pc della seconda scheda di rete (solo dal server
altrimenti devi attivare il routing se vuoi che i pc della 10.190.5.X
vedano quelli della 10.190.6.X) se questi hanno tutti ip 10.190.6.X
non devi fare niente perchè automaticamente il sistema ti genera una
route 10.190.6.0 mask 255.255.255.0 metric 10 gateway 10.190.6.X (dove
x è l'ip della seconda scheda del server)

Post by Camaleonte
Ho windows2003 server. Posso provare lo stesso a fare questa operazione,
oppure potrei aggiungere alla seconda scheda, nelle proprietà avanzate,
un secondo gateway, quello della prima, togliendolo del tutto dalle
proprietà della seconda.

Il pc anche se ha più schede deve avere un solo gateway (che usa solo
per gli ip che non appartengono a 10.190.6.X e a 10.190.5.x
normalmente tutto internet) altrimenti ti puoi trovare nella
situazione in cui improvvisamente interviene il secondo gateway e non
accedi più ad internet.

Post by Camaleonte
Per intenderci, è il primo gateway che mi lascia uscire in internet, il
secondo solo per vedere l'altra rete.

Ok

Post by Camaleonte
ciao :-)

Ciao

[Camaleonte]

Post by Omero
il gateway ti serve solo per andare in internet e quindi lo devi
mettere solo nella scheda che è connessa con il router/gateway

ok

Post by Omero
per accedere ai pc della seconda scheda di rete (solo dal server
altrimenti devi attivare il routing se vuoi che i pc della 10.190.5.X
vedano quelli della 10.190.6.X) se questi hanno tutti ip 10.190.6.X
non devi fare niente perchè automaticamente il sistema ti genera una
route 10.190.6.0 mask 255.255.255.0 metric 10 gateway 10.190.6.X (dove
x è l'ip della seconda scheda del server)

no, le due reti non devono essere in routing. se volessi fare il routing
basterebbe fare come hai detto? cioè inserire come gateway della prima
l'ip della seconda?

Post by Omero
Il pc anche se ha più schede deve avere un solo gateway (che usa solo
per gli ip che non appartengono a 10.190.6.X e a 10.190.5.x
normalmente tutto internet) altrimenti ti puoi trovare nella
situazione in cui improvvisamente interviene il secondo gateway e non
accedi più ad internet.

capito, però potrei aggiungere alla prima scheda un'altro indirizzo ip e
subnet? per vedere entrambe le reti con la stessa scheda? 2003 server
permette di aggiungere altri ip!!

a presto ;-)

[Omero]

Post by Camaleonte

Post by Omero
per accedere ai pc della seconda scheda di rete (solo dal server
altrimenti devi attivare il routing se vuoi che i pc della 10.190.5.X
vedano quelli della 10.190.6.X) se questi hanno tutti ip 10.190.6.X
non devi fare niente perchè automaticamente il sistema ti genera una
route 10.190.6.0 mask 255.255.255.0 metric 10 gateway 10.190.6.X (dove
x è l'ip della seconda scheda del server)

no, le due reti non devono essere in routing. se volessi fare il routing
  basterebbe fare come hai detto? cioè inserire come gateway della prima
l'ip della seconda?

No basta attivare il routing nel server 2003, credo da "routing e
accesso remoto" io l'ho fatto solo su linux e xp fino a oggi, poi se
vuoi che i pc della rete 10.190.5.X possano vedere quelli della rete
10.190.6.x devi creare una route statica nel router che ti fa da
gateway (quello che ti fa andare in internet) nella rete 1 del tipo
192.168.6.X 255.255.255.0 metrica 1 gateway 192.168.5.X dove x è l'ip
della scheda 1 del server, poi o hai un router anche nella seconda
rete che fa da gateway e aggiungi una route 192.168.5.X 255.255.255.0
metric 1 gateway 192.168.5.X dove x è l'ip della scheda 2 del server,
o punti tutti i gateway dei pc della rete 2 sull'ip 192.168.5.X se
questi non hanno bisogno dell'accesso ad internet o crei su ogni pc
una route statica 192.168.5.X 255.255.255.0 metric 1 gateway
192.168.5.X.

Queste due route che devi creare una per i client della rete 1 e una
per quelli della rete 2 serve per specificare alle varie macchine
delle due reti che per contattare l'altra subnet devono usare il pc
192.168.5.X/192.168.6.X (in pratica il server con due schede) come
punto di transito tra le due reti. (questo anche se usi una sola
scheda di rete con due ip)

Post by Camaleonte
capito, però potrei aggiungere alla prima scheda un'altro indirizzo ip e
subnet? per vedere entrambe le reti con la stessa scheda? 2003 server
permette di aggiungere altri ip!!

certo se le due subnet sono presenti nello stesso switch altrimenti o
crei un ponte tra i due switch o usi le due schede separate, a livello
di configurazione non c'è differenza tra usare una o due schede.

Ciao

[Camaleonte]

Post by Omero
certo se le due subnet sono presenti nello stesso switch altrimenti o
crei un ponte tra i due switch o usi le due schede separate, a livello
di configurazione non c'è differenza tra usare una o due schede.
Ciao

grazie Omero, adesso però vorrei risolvere il mio piccolo problema. Nel
senso che le due reti devono rimanere separate, ma vorrei che la seconda
rete venisse vista dal mio server, come sono riuscito a fare, per poter
aggiornare anche i pc di questa, ma senza mandare in tilt hamster. Le
prove purtroppo devono essere rimandate a lunedì.

Vorrei solo sapere una cosa. Il gateway come risaputo è un punto di
passaggio per rete diversa. Io non voglio che le reti si vedano.
Pertanto potrei fare in questo modo:

configurare la seconda scheda per la seconda rete ma senza gateway, oppure
configurare la prima scheda aggiungendo ip e subnet della seconda rete

quando io ho aggiunto anche il gateway alla seconda scheda, le reti
venivano viste entrambe dal server, ricordo dunque che il problema era
solo di hamster, che probabilmente non capiva a quale ip doveva fare
capo. Qui ci vuole chi è già incappato nel problema, sono sicuro che c'è
da aggiungere qualcosina ad hamster :-/

buona serata :-)

[Camaleonte]

Camaleonte ha scritto:

cut

Post by Camaleonte
Le
prove purtroppo devono essere rimandate a lunedì.

ho provato stamattina...

Post by Camaleonte
configurare la seconda scheda per la seconda rete ma senza gateway, oppure
configurare la prima scheda aggiungendo ip e subnet della seconda rete

entrambe andate male. Appena abilito la seconda scheda, hamster non va.
Mentre se aggiungo ip e subnet alla prima scheda, non vede la seconda
rete, mi chiedo a cosa serve aggiungere ip diversi sulla stessa scheda.
Devo abilitare qualcosa?


buona domenica :-/

[Camaleonte]

Ciao

ho capito perché hamster si impalla :-) è già un grande passo...

io punto hamster con il nome del computer, quando dunque outlook express
tenta di contattare il pcname, non sa a quale scheda fare riferimento, e
mi da errore.

Se per ipotesi, in imap e smtp del client di posta mettessi l'ip,
funzionerebbe (non ho provato). E nemmeno mi conviene, perché tutti i pc
sono ormai configurati con il nome. Dovrei trovare il sistema di
aggiungere un nome pc alla seconda scheda, come se il pc avesse in
pratica due nomi. Così quando il client di posta puntano a pcname, sanno
quale ip cercare :-)

ciao e buona domenica ;-)

[Macs]

Follow-up su : it.comp.reti.locali
----------------------------------

Ciao

io punto hamster con il nome del computer [...]

In tal caso e' sufficiente impostare correttamente l'associazione
nome-host/indirizzo-IP a livello dell'eventuale server DNS locale LAN,
oppure tramite definizione nel file HOSTS (quello senza estensione) dei
client :
==
- http://en.wikipedia.org/wiki/Hosts_file

[Camaleonte]

Post by Macs
- http://en.wikipedia.org/wiki/Hosts_file

dunque dovrei:

127.0.0.1 localhost
::1 localhost
10.190.12.33 hamster
10.190.14.144 altronome

e se invece forzassi la cosa mettendo hamster anche per 10.190.14.144?

delle prime due righe, la prima è semplice, ma il ::1 che roba è?

p.s. Macs, scusami se in un altro threads non ho risposto, non ho
proprio visto il tuo post, comunque quella di officesip è cosa rimasta
in sospeso, quando ho tempo riprovo. A dire la verità, avendo molti pc
disponibili, avevo pensato di provare direttamente con XP.

[Macs]

Ciao

Post by Camaleonte
e se invece forzassi la cosa mettendo hamster anche per
10.190.14.144?

Perche' ? = se non ho letto male, a te serve che i client appartenenti
ad una subnet sappiano con precisione univoca quale sia l'indirizzo IP
associato al nome-host, evitando che tentino di contattare l'altra
interfaccia in seguito ad un browse sulla rete.

Definendo appunto correttamente/univocamente l'associazione host/IP nel
file HOSTS dei client, eviti proprio tale problematica.

Post by Camaleonte
delle prime due righe, la prima è semplice, ma il ::1 che roba è?

Corrisponde all'indirizzo IPv6 dell'intefaccia localhost di loopback su
IPv6 -> ritrovi pertanto tale riga solo nei sistemi, che abbiano lo
stack TCP/IPv6 attivo.

Post by Camaleonte
p.s. Macs, scusami se in un altro threads non ho risposto, non ho
proprio visto il tuo post, comunque quella di officesip è cosa
rimasta in sospeso, quando ho tempo riprovo.

OK, non ci sono problemi = non vedendo evoluzioni, pensavo che avessi
comunque gia' risolto (tramite OfficeSIP o altra soluzione).

[Camaleonte]

Post by Macs
Perche' ? = se non ho letto male, a te serve che i client appartenenti
ad una subnet sappiano con precisione univoca quale sia l'indirizzo IP
associato al nome-host, evitando che tentino di contattare l'altra
interfaccia in seguito ad un browse sulla rete.

no, perché non ho ancora provato a puntare il server dall'altra rete, e
forse non ce n'è nemmeno bisogno. L'idea era quella di indicare ad
hamster programma di posta e news, che 10.190.14.144 si chiama sempre
hamster, e così evitare che si impalli.

Post by Macs
Definendo appunto correttamente/univocamente l'associazione host/IP nel
file HOSTS dei client, eviti proprio tale problematica.

un momento, forse ci stiamo confondendo. Io non ho ancora provato da
altri pc a vedere il server per aggiornare i loro s.o. con wsus. Mi sono
fermato prima, cioè al problema che hamster, non mi gestisce più la
posta, e la prova la faccio dal server stesso, dove è installato hamster.

Se devo configurare il file hosts del server, allora proverò appena
possibile, cioè domani, tentando di confondere hamster, o come hai
suggerito di chiarirgli le idee e mettere 10.190.14.144 nuovonome

ciao

[Macs]

Ciao

L'idea era quella di indicare ad hamster programma di posta e news,
che 10.190.14.144 si chiama sempre hamster, e così evitare che si
impalli.

[...]

la prova la faccio dal server stesso, dove è installato hamster.

La modifica del file HOSTS e' determinante lato client, qualora tu
non disponga su rete LAN di server DNS ove definire l'associazione
nome-host/IP -> la definizione di tale associazione serve appunto ad
evitare che i client riscontrino problemi di connessione per questioni
di risoluzione non corretta nome-host/IP.

Per quanto riguarda l'accesso ai servizi Hamster lato server-side devi
operare nelle relative opzioni di configurazione, definendo il nome del
server & l'indirizzamento IP di binding per servizi/porte in ascolto.

Provo ad illustrarlo con un scenario pratico d'esempio lato server in
termini di indirizzamenti IPv4 & instradamenti = definisco 2 subnet LAN
/24 disgiunte, che non consentano la comunicazione tra clienti loro
associati attraverso il server (IP Forwarding/Routing non impostato) :
==
-----------------------------------------------------------------------
- Eth0 : 10.190.14.144 Subnet Mask 255.255.255.0 GW 10.190.14.254
- Eth1 : 10.190.15.155 Subnet Mask 255.255.255.0 No GW

- DST 0.0.0.0 M 0.0.0.0 GW 10.190.14.254 IF 10.190.14.144

- DST 10.190.14.0 M 255.255.255.0 GW 10.190.14.144 IF 10.190.14.144
- DST 10.190.14.144 M 255.255.255.255 GW 127.0.0.1 IF 127.0.0.1
- DST 10.190.14.255 M 255.255.255.255 GW 10.190.14.144 IF 10.190.14.144

- DST 10.190.15.0 M 255.255.255.0 GW 10.190.15.155 IF 10.190.15.155
- DST 10.190.15.155 M 255.255.255.255 GW 127.0.0.1 IF 127.0.0.1
- DST 10.190.15.255 M 255.255.255.255 GW 10.190.15.155 IF 10.190.15.155
-----------------------------------------------------------------------

Se tu vuoi che Hamster (vale sia per la versione Classic che per quella
Playground) stia "in ascolto" solo per i client LAN 10.190.14/24, e'
sufficiente definire il binding su 10.190.14.144 & autorizzare gli
accessi da parte della subnet /24 nelle opzioni di configurazione di
Hamster (ed anche a livello di impostazioni ICF o RRAS TCP/UDP Filter).

A quel punto e' sufficiente definire (lato server DNS in LAN o tramite
modifica del file HOSTS) la corretta associazione nome-host HAMSTER con
l'IP 10.190.14.144 .


Se poi volessi che i servizi NNTP/POP3/IMAP Hamster fossero accessibili
anche da client sull'altra subnet (e/o su eventuali future/nuove subnet
associate ad interfacce fisiche/logiche), senza abilitare pero' l'IP
forwarding/routing lato server, basterebbe che impostassi 0.0.0.0 come
IP binding & aggiornassi le autorizzazioni Hamster/OS con le nuove
subnet.

In tal caso dovresti ovviamente differenziare l'associazione host/IP in
base alla subnet di appartenenza dei client :
==
- Client 10.190.14/24 -> 10.190.14.144 hamster
- Client 10.190.15/24 -> 10.190.15.155 hamster

[Camaleonte]

Post by Macs
La modifica del file HOSTS e' determinante lato client, qualora tu
non disponga su rete LAN di server DNS ove definire l'associazione
nome-host/IP -> la definizione di tale associazione serve appunto ad
evitare che i client riscontrino problemi di connessione per questioni
di risoluzione non corretta nome-host/IP.

fin qui è tutto chiaro, anche se c'è da dire che il dns è imho, inerente al
proxy per la connessione internet, ma andiamo avanti, dove veramente ho
compreso pochino :-)

Post by Macs
Per quanto riguarda l'accesso ai servizi Hamster lato server-side devi
operare nelle relative opzioni di configurazione, definendo il nome del
server & l'indirizzamento IP di binding per servizi/porte in ascolto.

indirizzamento ip, ok, di binding, non ho proprio conoscenza. Mi dici in due
parole a che serve?

Post by Macs
Provo ad illustrarlo con un scenario pratico d'esempio lato server in
termini di indirizzamenti IPv4 & instradamenti = definisco 2 subnet LAN
/24 disgiunte, che non consentano la comunicazione tra clienti loro

due subnet, ok

Post by Macs
-----------------------------------------------------------------------
- Eth0 : 10.190.14.144 Subnet Mask 255.255.255.0 GW 10.190.14.254
- Eth1 : 10.190.15.155 Subnet Mask 255.255.255.0 No GW
- DST 0.0.0.0 M 0.0.0.0 GW 10.190.14.254 IF 10.190.14.144
- DST 10.190.14.0 M 255.255.255.0 GW 10.190.14.144 IF 10.190.14.144
- DST 10.190.14.144 M 255.255.255.255 GW 127.0.0.1 IF 127.0.0.1
- DST 10.190.14.255 M 255.255.255.255 GW 10.190.14.144 IF 10.190.14.144
- DST 10.190.15.0 M 255.255.255.0 GW 10.190.15.155 IF 10.190.15.155
- DST 10.190.15.155 M 255.255.255.255 GW 127.0.0.1 IF 127.0.0.1
- DST 10.190.15.255 M 255.255.255.255 GW 10.190.15.155 IF 10.190.15.155
-----------------------------------------------------------------------
Se tu vuoi che Hamster (vale sia per la versione Classic che per quella
Playground) stia "in ascolto" solo per i client LAN 10.190.14/24, e'
sufficiente definire il binding su 10.190.14.144 & autorizzare gli
accessi da parte della subnet /24 nelle opzioni di configurazione di
Hamster (ed anche a livello di impostazioni ICF o RRAS TCP/UDP Filter).

Io vorrei che hamster funzionasse innanzi tutto per entrambe le reti...

Post by Macs
A quel punto e' sufficiente definire (lato server DNS in LAN o tramite
modifica del file HOSTS) la corretta associazione nome-host HAMSTER con
l'IP 10.190.14.144 .

è quello che ho provato a fare stamattina, ho aggiunto l'ip e il nome del
server, che per pigrizia ho chiamato... hamster :-) ma niente, hamster
programma non ne vuole sapere di gestire due schede di rete :-(

Post by Macs
Se poi volessi che i servizi NNTP/POP3/IMAP Hamster fossero accessibili
anche da client sull'altra subnet (e/o su eventuali future/nuove subnet
associate ad interfacce fisiche/logiche), senza abilitare pero' l'IP
forwarding/routing lato server, basterebbe che impostassi 0.0.0.0 come
IP binding & aggiornassi le autorizzazioni Hamster/OS con le nuove
subnet.
In tal caso dovresti ovviamente differenziare l'associazione host/IP in
==
- Client 10.190.14/24 -> 10.190.14.144 hamster
- Client 10.190.15/24 -> 10.190.15.155 hamster

ciao Macs, spero di non averti scocciato, ma la strada pare che non è questa :-)

[Macs]

Ciao

Post by Camaleonte
fin qui è tutto chiaro, anche se c'è da dire che il dns è imho,
inerente al proxy per la connessione internet

Dipende da come sono gestite le query DNS sulla tua rete = non ho i
dettagli sulla tua configurazione LAN/Intranet, per cui non so se tutte
le query DNS dei client vengano effettivamente inoltrate tramite la
piattaforma proxy (ved. anche controllo del traffico query/lookup DNS
in LAN & impostazioni DNS/proxy lato client).

Post by Camaleonte
di binding, non ho proprio conoscenza. Mi dici in due parole a che
serve?

Corrisponde all'indirizzamento e/o all'interfaccia di rete a cui sono
associati in ascolto i servizi TCP (NNTP/POP/IMAP) gestiti da Hamster.
Nel tuo caso (IP Forwarding/Routing disabilitato lato server) Hamster
puo essere infatti impostato in ascolto p.es. su :
==
- 127.0.0.1 -> utilizzo solo a livello della macchina locale

- 10.190.14.144 -> accesso/utilizzo dai client 10.190.14/24

- 10.190.15.155 -> accesso/utilizzo dai client 10.190.15/24

- 0.0.0.0 -> Hamster e' in ascolto su tutte le interfacce di rete
fisiche/logiche del server (e quindi anche su Eth0 e
Eth1)

La verifica lato binding si effettua gia' tramite netstat -na da prompt
dei comandi.

Post by Camaleonte
Io vorrei che hamster funzionasse innanzi tutto per entrambe le reti...

[...]

Post by Camaleonte
hamster programma non ne vuole sapere di gestire due schede di rete
:-(

Se e' per quello, ne gestisce anche di piu' ;) = va definito in primis
il binding su 0.0.0.0 -> in questo modo i relativi servizi gestiti
saranno in ascolto su tutte le interfacce del server (loopback + IP
associati ad interfacce di rete fisiche e logiche).

Se sono corrette le impostazioni di subnetting/routing sul server, non
vi sono problemi di gestione per le connessioni provenienti da subnet
distinte & associate ad interfacce fisiche/logiche sul server.

A quel punto dovrai ovviamente definire le autorizzazioni a livello sia
di Hamster che di server/rete, onde consentire l'accesso solo ai client
delle tue subnet LAN.

Se riportassi la tabella di routing del tuo server (route print da
prompt) & indicassi la versione di Hamster (Classic o Playground) in
uso, potrei sia verificare le configurazioni che indicarti dove/come
controllare le varie impostazioni (ved. file di configurazione setup o
pannello di controllo GUI opzioni).


Per quanto riguarda la gestione delle risoluzioni nome-host/IP, si puo
procedere in modi diversi a seconda della piattaforma/configurazione
in rete LAN per la gestione di DNS query/lookup.

Se consente risposte diverse in funzione dell'IP di origine della query
(e.g. stile Bind con definizione Views o tramite 'DNS doctoring' a
livello di instradamento/controllo del traffico DNS), allora puoi
procedere in tal senso senza problemi.

Altrimenti, in base anche al numero di client coinvolti, devi optare
per altre soluzioni (e.g. modifiche a livello file HOSTS dei client
tramite deployment automatico o IP/Port redirection in base all'IP
sorgente del client).

[Camaleonte]

Post by Macs
Corrisponde all'indirizzamento e/o all'interfaccia di rete a cui sono
associati in ascolto i servizi TCP (NNTP/POP/IMAP) gestiti da Hamster.
Nel tuo caso (IP Forwarding/Routing disabilitato lato server) Hamster
==
- 127.0.0.1 -> utilizzo solo a livello della macchina locale
- 10.190.14.144 -> accesso/utilizzo dai client 10.190.14/24
- 10.190.15.155 -> accesso/utilizzo dai client 10.190.15/24
- 0.0.0.0 -> Hamster e' in ascolto su tutte le interfacce di rete
fisiche/logiche del server (e quindi anche su Eth0 e
Eth1)

hamster è impostato che vede tutte le reti 10.190.0.0 -
Avevo previsto l'altra rete, e pre questo mi sono tenuto largo, ma
domani se ho tempo, perché sto facendo un lavoraccio su tutte le
macchine, (antivirus e agg. s.o.) ti posto sia il file di congiruazione
di hamster classic, sia la print route


ci sentiamo domani, ciao :-)

[Macs]

Ciao

Post by Camaleonte
hamster è impostato che vede tutte le reti 10.190.0.0

L'impostazione a livello di host autorizzati su Hamster deve essere
congruente con lo stato di binding dei relativi servizi TCP = vedasi
output di netstat o tcpview con la situazione IP/Porte in ascolto su
TCP.

Se infatti autorizzi su Hamster l'accesso da parte di Host 10.190/16,
ma poi risulta in binding/ascolto solo sull'IF 10.190.14.144 impostata
per la relativa subnet /24, allora e' normale che (in assenza di IP
Routing) non possano accedervi p.es. i client su 10.190.15/24 .


Qualora tra i tuoi obiettivi non fosse rientrato anche quello di
mantenere il traffico delle subnet /24 disgiunto & associato ad
interfacce differenti, avresti potuto procedere con modifiche a
livello di routing su client/rete o di subnetting per IF 10.190.14.244,
onde mantenere il binding di Hamster su una singola interfaccia.

Questo non e' compatibile con le esigenze/specifiche, che hai indicato
finora, ed ecco perche' devi impostare Hamster in binding/ascolto su
0.0.0.0 .

Post by Camaleonte
domani se ho tempo, perché sto facendo un lavoraccio su tutte le
macchine, (antivirus e agg. s.o.) ti posto sia il file di
congiruazione di hamster classic, sia la print route

OK -> aggiungici anche l'output di netstat (o tcpview), in modo da
disporre di tutte le info necessarie.

[Camaleonte]

Post by Macs
L'impostazione a livello di host autorizzati su Hamster deve essere
congruente con lo stato di binding dei relativi servizi TCP = vedasi
output di netstat o tcpview con la situazione IP/Porte in ascolto su
TCP.
Se infatti autorizzi su Hamster l'accesso da parte di Host 10.190/16,
ma poi risulta in binding/ascolto solo sull'IF 10.190.14.144 impostata
per la relativa subnet /24, allora e' normale che (in assenza di IP
Routing) non possano accedervi p.es. i client su 10.190.15/24 .

non mi sono spiegato :-( dunque, io non ho mai provato se un client di
quell'altra rete vede hamster e i suoi servizi. Quello che accade è che appena
abilito l'altra scheda rete, dal server stesso, provo con outlook a scaricare
posta e news, e non funziona :-)

Post by Macs
Questo non e' compatibile con le esigenze/specifiche, che hai indicato
finora, ed ecco perche' devi impostare Hamster in binding/ascolto su

posterò in mattinata anche la config di hamster, così hai il quadro completo :-)

a presto

[Camaleonte]

Post by Macs
OK -> aggiungici anche l'output di netstat (o tcpview), in modo da
disporre di tutte le info necessarie.

Ecco i display :-)

C:>route print

IPv4 Tabella route
===========================================================================
Elenco interfacce
0x1 ........................... MS TCP Loopback interface
0x10003 ...00 09 6b a5 c1 70 ...... Broadcom NetXtreme Gigabit Ethernet
===========================================================================
===========================================================================
Route attive:
Indirizzo rete Mask Gateway Interfaccia Metrica
0.0.0.0 0.0.0.0 10.193.12.1 10.193.12.33 20
10.193.12.0 255.255.254.0 10.193.12.33 10.193.12.33 20
10.193.12.33 255.255.255.255 127.0.0.1 127.0.0.1 20
10.255.255.255 255.255.255.255 10.193.12.33 10.193.12.33 20
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
224.0.0.0 240.0.0.0 10.193.12.33 10.193.12.33 20
255.255.255.255 255.255.255.255 10.193.12.33 10.193.12.33 1
Gateway predef.: 10.193.12.1
===========================================================================
Route permanenti:
Nessuna

questo è il file IPAccess.hst che abilita hamster a ricevere, come si vede alla
terza riga le reti 10.193.12.0 e 10.193.14.0

ALL,NA,LOCAL,127.0.0.1
ALL,RW,127.0.0.1
ALL, RW, 10.193.0.0, 10.193.255.255
ALL,NA,0.0.0.0,255.255.255.255

C:>netstat -na

Connessioni attive

Proto Indirizzo locale Indirizzo esterno Stato
TCP 0.0.0.0:21 0.0.0.0:0 LISTENING
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1025 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1026 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1027 0.0.0.0:0 LISTENING
TCP 0.0.0.0:5769 0.0.0.0:0 LISTENING
TCP 0.0.0.0:8098 0.0.0.0:0 LISTENING
TCP 0.0.0.0:8099 0.0.0.0:0 LISTENING
TCP 10.193.12.33:23 0.0.0.0:0 LISTENING
TCP 10.193.12.33:25 0.0.0.0:0 LISTENING
TCP 10.193.12.33:80 10.193.12.228:1098 ESTABLISHED
TCP 10.193.12.33:110 0.0.0.0:0 LISTENING
TCP 10.193.12.33:119 0.0.0.0:0 LISTENING
TCP 10.193.12.33:139 0.0.0.0:0 LISTENING
TCP 10.193.12.33:143 0.0.0.0:0 LISTENING
TCP 10.193.12.33:4844 10.193.12.32:139 TIME_WAIT
TCP 10.193.12.33:4845 10.193.12.32:139 TIME_WAIT
TCP 127.0.0.1:1028 0.0.0.0:0 LISTENING
UDP 0.0.0.0:445 *:*
UDP 0.0.0.0:500 *:*
UDP 0.0.0.0:3456 *:*
UDP 0.0.0.0:4500 *:*
UDP 10.193.12.33:123 *:*
UDP 10.193.12.33:137 *:*
UDP 10.193.12.33:138 *:*
UDP 127.0.0.1:123 *:*
UDP 127.0.0.1:3399 *:*
UDP 127.0.0.1:3456 *:*

[Macs]

Ciao

Indirizzo rete Mask Gateway Interfaccia Metrica
0.0.0.0 0.0.0.0 10.193.12.1 10.193.12.33 20
10.193.12.0 255.255.254.0 10.193.12.33 10.193.12.33 20

[...]

questo è il file IPAccess.hst che abilita hamster a ricevere, come si
vede alla terza riga le reti 10.193.12.0 e 10.193.14.0
ALL,NA,LOCAL,127.0.0.1
ALL,RW,127.0.0.1
ALL, RW, 10.193.0.0, 10.193.255.255
ALL,NA,0.0.0.0,255.255.255.255

[...]

TCP 10.193.12.33:23 0.0.0.0:0 LISTENING
TCP 10.193.12.33:25 0.0.0.0:0 LISTENING

[...]

TCP 10.193.12.33:110 0.0.0.0:0 LISTENING
TCP 10.193.12.33:119 0.0.0.0:0 LISTENING

[...]

TCP 10.193.12.33:143 0.0.0.0:0 LISTENING

In realta' la tua configurazione prevede che Hamster sia impostato per :
==
1. Trattare tutti gli indirizzi IP locali (cioe' associati ad interfacce
fisiche/logiche sul server) come se fossero quello dell'interfaccia
di loopback localhost 127.0.0.1 .

2. Autorizzare l'accesso a tutti i server (compreso quello Telnet di
Amministrazione Remota) sia da locale che da client attestati sulla
subnet 10.193/16 (10.193.0.0 10.193.255.255), e non quindi solo sulle
10.193.12/24 e 10.193.14/24 .

I reali vincoli di accesso sono infatti determinati semmai dalle
impostazioni di subnetting dell'IF Eth0 /23 (10.193.12.0-19.193.13.255)
& dal binding esclusivo dei servizi NNTP/POP/IMAP/SMTP + Telnet su tale
interfaccia.

Se il tuo scopo era quello di limitare l'accesso solo agli utenti su
10.193.12/24, la configurazione non e' ottimale -> peraltro vi e' anche
il problema della visibilita' del server di Amministrazione Remota da
parte delle utenze client.


Aggiungendo ulteriori indirizzamenti IP lato server & associazioni ad
altre subnet, devi adeguare ovviamente le impostazioni di binding dei
servizi & le autorizzazioni IPAccess di Hamster.

Ti illustro la configurazione pratica per uno scenario, che preveda :
==
1. Aggiunta di un'interfaccia IF Eth1 10.193.14.33 associata ad una
subnet utenti 10.193.14/23 (10.193.14.0-10.193.15.255).

2. Autorizzazioni d'accesso ai servizi NNTP/POP/IMAP/SMTP gestiti da
Hamster per le utenze su 10.193.12/24 e 10.193.14/24.

3. Autorizzazione d'accesso al servizio Telnet di Amministrazione Remota
di Hamster, escludendone la visibilita' alle subnet utenti.

Applichiamo quindi la configurazione IP 10.193.14.33 / SM 255.255.254.0
(No Gateway / No DNS) sulla IF Eth1 & verifichiamo che la tabella di
routing sia OK :
==
------------------------------------------------------------------------
Indirizzo rete Mask Gateway Interfaccia Metrica
0.0.0.0 0.0.0.0 10.193.12.1 10.193.12.33 20
10.193.12.0 255.255.254.0 10.193.12.33 10.193.12.33 20
10.193.12.33 255.255.255.255 127.0.0.1 127.0.0.1 20
10.193.14.0 255.255.254.0 10.193.14.33 10.193.14.33 20
10.193.14.33 255.255.255.255 127.0.0.1 127.0.0.1 20
------------------------------------------------------------------------

A quel punto va definito adeguatamente il binding dei servizi Hamster.
Se pertanto si vuole che un dato server locale risponda sia su Eth0 che
su Eth1, e' necessario definire il binding su 0.0.0.0 :
==
- Hamster > Menu Configura > Server Locali
- Scelta del server da configurare
- Scrivere 0.0.0.0 nel box Interfaccia IP (Indirizzo IP in scheda POP3)

Un binding su 0.0.0.0 per i servizi NNTP/POP/IMAP/SMTP, una volta
applicato, risulta evidente dall'output di netstat :
==
------------------------------------------------------------------------
Proto Local Address Foreign Address State
TCP 0.0.0.0:25 0.0.0.0:0 LISTENING
TCP 0.0.0.0:110 0.0.0.0:0 LISTENING
TCP 0.0.0.0:119 0.0.0.0:0 LISTENING
TCP 0.0.0.0:143 0.0.0.0:0 LISTENING
------------------------------------------------------------------------

Qualora si desideri restringere l'accesso ad una determinata subnet
utenza, conviene farlo gia' vincolando l'interfaccia d'ascolto se/quando
possibile = se nel caso specifico tu volessi autorizzare p.es. l'accesso
a tutti i servizi solo alla subnet 10.193.12/24, consentendo agli utenti
su 10.193.14/24 solo i Newsgroup, potresti gia' applicare la seguente
situazione in termini di binding :
==
------------------------------------------------------------------------
NNTP - Interfaccia IP : 0.0.0.0 / Porta : 119
POP3 - Indirizzo IP ..: 10.193.12.33 / Porta : 110
IMAP - Interfaccia IP : 10.193.12.33 / Porta : 143
SMTP - Interfaccia IP : 10.193.12.33 / Porta : 25
------------------------------------------------------------------------
Proto Local Address Foreign Address State
TCP 10.193.12.33:25 0.0.0.0:0 LISTENING
TCP 10.193.12.33:110 0.0.0.0:0 LISTENING
TCP 0.0.0.0:119 0.0.0.0:0 LISTENING
TCP 10.193.12.33:143 0.0.0.0:0 LISTENING
------------------------------------------------------------------------

Una volta effettuate correttamente le associazioni di binding, si puo
procedere alla definizione delle autorizzazioni in IPAccess.hst -> nel
caso specifico, consideriamo che tu voglia autorizzare l'accesso in
lettura+scrittura per i servizi NNTP e SMTP/POP/IMAP alle utenze sulle
subnet 10.193.12/24 e 10.193.14/24 :
==
------------------------------------------------------------------------
ALL,NA,LOCAL,127.0.0.1
ALL,RW,127.0.0.1
NNTP,RW,10.193.12.0,10.193.12.255
NNTP,RW,10.193.14.0,10.193.14.255
MAIL,RW,10.193.12.0,10.193.12.255
MAIL,RW,10.193.14.0,10.193.14.255
ALL,NA,0.0.0.0,255.255.255.255
------------------------------------------------------------------------

Ovviamente puoi applicare restrizioni d'accesso in IPAccess.hst, che
replichino e/o integrino quelle definite a livello di binding -> se
riprendessi p.es. la precedente configurazione 'sample' di binding
differenziato, avresti queste regole per il controllo degli accessi :
==
------------------------------------------------------------------------
ALL,NA,LOCAL,127.0.0.1
ALL,RW,127.0.0.1
NNTP,RW,10.193.12.0,10.193.12.255
NNTP,RW,10.193.14.0,10.193.14.255
MAIL,RW,10.193.12.0,10.193.12.255
ALL,NA,0.0.0.0,255.255.255.255
------------------------------------------------------------------------

Per ulteriori info sulla definizione delle regole d'accesso con
differenziazione in base anche a tipologia di servizi & d'accesso
(lettura e/o scrittura), basta far riferimento alla guida di Hamster.


Qualora volessi mantenere attivo anche il server locale Telnet di
Hamster per operazioni di Amministrazione Remota, sarebbe opportuno che
questo non fosse visibile/accessibile (per ovvie ragioni) dagli utenti.

A meno quindi che tu decidessi di mantenerlo comunque attivo, ma poi
usarlo solo localmente con binding su 127.0.0.1, avresti 2 possibilita':
==
1. Definire il binding del server Telnet/RECO in associazione ad
un'apposita subnet distinta da quelle utenti & riservata solo agli
Amministratori di rete/sistema, impostando poi ovviamente la
relativa regola di accesso/autorizzazione in IPAccess.hst e.g.:
==
* Subnet Admin IF IP 172.16.81.33 SM 255.255.255.248
* Telnet - Interfaccia IP : 172.16.81.33 / Porta : 23
RECO,ALL,172.16.81.34,172.16.81.38

2. Effettuare solo le restrizioni d'accesso in IPAccess.hst e.g.:
==
RECO,ALL,10.193.12.11 # Administrator Subnet 01
RECO,ALL,10.193.14.11 # Administrator Subnet 02

E' ovvio che la possibilita' 1 e' migliore in termini di sicurezza.

non mi sono spiegato :-( dunque, io non ho mai provato se un client di
quell'altra rete vede hamster e i suoi servizi. Quello che accade è
che appena abilito l'altra scheda rete, dal server stesso, provo con
outlook a scaricare posta e news, e non funziona :-)

Situazione logica, vista la configurazione che hai postato = il binding
dei servizi e' fisso su 10.193.12.33 (ved. appunto impostazioni server
locali Hamster), per cui - dato che tu provi ad accedere indicando il
nome-host del computer - si ha un KO proprio quando la risoluzione di
quest'ultimo 'switcha' in associazione all'IP dell'altra interfaccia IF
fisica aggiunta.

Ti sei quindi spiegato bene, ma il punto e' un altro = la configurazione
che hai testato (e che hai riportato) non e' adeguata allo scenario
Multi-IF lato server, e di conseguenza ha 'sfalsato' gia' le sole
verifiche in locale sul server effettuate finora.


Una volta configurati adeguatamente i servizi sul server, devi solo
decidere come procedere per quanto riguarda l'accesso lato client delle
2 subnet utenti in base al puntamento su un nome-host univoco.

Se la tua piattaforma/configurazione per la gestione del traffico DNS
consente risposte diverse in funzione dell'IP di origine della query
(e.g. stile Bind con definizione Views o tramite 'DNS doctoring' a
livello di instradamento/controllo del traffico DNS), allora puoi
procedere in tal senso senza problemi :
==
SRC 10.193.12/24 -> resolve to 10.193.12.33
SRC 10.193.14/24 -> resolve to 10.193.14.33


Altrimenti, qualora cio' non fosse possibile/applicabile, avresti
comunque alternative in funzione anche del numero di client e/o della
piattaforma/configurazione a livello proxy/gateway per l'instradamento
delle connessioni & DNS per la risoluzione di query/lookup, e.g.:
==
1. Definire a livello DNS LAN la risoluzione su 10.193.12.33, forzando
a livello gateway/proxy un IP/Port Redirect :
==
- SRC : IP : 10.193.14/0 - Port : Any
- DST : IP : 10.193.12.33 - Port : 25 / 110 / 119 / 143
- RDR : IP : 10.193.14.33 - Port : 25 / 110 / 119 / 143

2. Definire a livello DNS LAN la risoluzione su 10.193.12.33, forzando
a livello HOSTS (e.g. tramite deployment o batch logon script) dei
singoli client su 10.193.14/24 quella su 10.193.14.33 .

3. Definenire a livello DNS LAN la risoluzione su 10.193.12.33, forzando
a livello dei singoli client l'IP/Port Redirect sopracitato tramite
un apposito TCP Redirector, e.g. RINETD su Linux/*Nix-like o FPIPE
su OS Windows :
==
- http://www.foundstone.com/us/resources/proddesc/fpipe.htm

[Camaleonte]

Post by Macs
==
1. Trattare tutti gli indirizzi IP locali (cioe' associati ad interfacce
fisiche/logiche sul server) come se fossero quello dell'interfaccia
di loopback localhost 127.0.0.1 .

ok.

Post by Macs
2. Autorizzare l'accesso a tutti i server (compreso quello Telnet di
Amministrazione Remota) sia da locale che da client attestati sulla
subnet 10.193/16 (10.193.0.0 10.193.255.255), e non quindi solo sulle
10.193.12/24 e 10.193.14/24 .

ok.
cut

Post by Macs
Se il tuo scopo era quello di limitare l'accesso solo agli utenti su
10.193.12/24, la configurazione non e' ottimale -> peraltro vi e' anche
il problema della visibilita' del server di Amministrazione Remota da
parte delle utenze client.

no, nessun limite a telnet, che non utilizzo, ma potrebbe farmi comodo da
qualsiasi postazione stoppare e riattivare un servizio, ma hamster non me ne
da mai il motivo :-)

Post by Macs
Aggiungendo ulteriori indirizzamenti IP lato server & associazioni ad
altre subnet, devi adeguare ovviamente le impostazioni di binding dei
servizi & le autorizzazioni IPAccess di Hamster.

vediamo...

cut

Post by Macs
Applichiamo quindi la configurazione IP 10.193.14.33 / SM 255.255.254.0
(No Gateway / No DNS) sulla IF Eth1 & verifichiamo che la tabella di

ok, anche se l'altra rete ha una subnet diversa 255.255.255.192

cut

Post by Macs
A quel punto va definito adeguatamente il binding dei servizi Hamster.
Se pertanto si vuole che un dato server locale risponda sia su Eth0 che

ok, ho settato tutti i servizi su 0.0.0.0 devo solo abilitare l'altra eth per
vedere se è tutto ok, ma suppongo che andrà bene :-)

cut

Post by Macs
Qualora si desideri restringere l'accesso ad una determinata subnet
utenza, conviene farlo gia' vincolando l'interfaccia d'ascolto se/quando
possibile = se nel caso specifico tu volessi autorizzare p.es. l'accesso
a tutti i servizi solo alla subnet 10.193.12/24, consentendo agli utenti
su 10.193.14/24 solo i Newsgroup, potresti gia' applicare la seguente
==
------------------------------------------------------------------------
NNTP - Interfaccia IP : 0.0.0.0 / Porta : 119
POP3 - Indirizzo IP ..: 10.193.12.33 / Porta : 110 (?)
IMAP - Interfaccia IP : 10.193.12.33 / Porta : 143
SMTP - Interfaccia IP : 10.193.12.33 / Porta : 25

ok, capito

Post by Macs
------------------------------------------------------------------------
Proto Local Address Foreign Address State
TCP 10.193.12.33:25 0.0.0.0:0 LISTENING
TCP 10.193.12.33:110 0.0.0.0:0 LISTENING
TCP 0.0.0.0:119 0.0.0.0:0 LISTENING
TCP 10.193.12.33:143 0.0.0.0:0 LISTENING
------------------------------------------------------------------------

ok.

Post by Macs
Una volta effettuate correttamente le associazioni di binding, si puo
procedere alla definizione delle autorizzazioni in IPAccess.hst -> nel
caso specifico, consideriamo che tu voglia autorizzare l'accesso in
lettura+scrittura per i servizi NNTP e SMTP/POP/IMAP alle utenze sulle
==
------------------------------------------------------------------------
ALL,NA,LOCAL,127.0.0.1
ALL,RW,127.0.0.1
NNTP,RW,10.193.12.0,10.193.12.255
NNTP,RW,10.193.14.0,10.193.14.255
MAIL,RW,10.193.12.0,10.193.12.255
MAIL,RW,10.193.14.0,10.193.14.255
ALL,NA,0.0.0.0,255.255.255.255
------------------------------------------------------------------------

devo aggiungere dalla seconda alla penultima, ok capito

Post by Macs
Ovviamente puoi applicare restrizioni d'accesso in IPAccess.hst, che
replichino e/o integrino quelle definite a livello di binding -> se
riprendessi p.es. la precedente configurazione 'sample' di binding
==
------------------------------------------------------------------------
ALL,NA,LOCAL,127.0.0.1
ALL,RW,127.0.0.1
NNTP,RW,10.193.12.0,10.193.12.255
NNTP,RW,10.193.14.0,10.193.14.255
MAIL,RW,10.193.12.0,10.193.12.255
ALL,NA,0.0.0.0,255.255.255.255
------------------------------------------------------------------------

ok.

per il resto leggerò con calma, meglio prima risolvere il problemino ;-)
sei stato chiarissimo, anche se su alcune cose faccio fatica, colpa mia.

ti faccio sapere gli esiti delle nuove config, ciao