Sempre RedHat... Routing.

[frakka]

Sempre il solito server redhat.
Due NIC, di cui eth0 si affaccia sulla rete privata (composta dalle subnet 192.168.1.x, 192.168.2.x, 192.168.3.x, 192.168.4.x, 192.168.5.x, 192.168.10.x, 192.168.101.x, 192.168.201.x, 192.168.205.x, 10.10.10.x) ed eth1 che invece è connessa ad una DMZ costituita dalla subnet locale 192.168.11.x che è nattata sugli ip pubblici.

Il gateway di default del server deve quindi essere 192.168.11.254 ma il traffico per le subnet della rete privata deve essere instradato attraverso la eth0.

Questa è la configurazione delle NIC:

DHCP_HOSTNAME=server.miodominio.lan
BOOTPROTO=none
PEERDNS=yes
IPV6INIT=no
TYPE=Ethernet
HWADDR=00:24:81:B2:B5:00
DEVICE=eth0
NETMASK=255.255.255.0
IPADDR=192.168.10.31
USERCTL=no
ONBOOT=yes

default 192.168.11.254 dev eth1

192.168.1.0/24 via 192.168.10.254 dev eth0
192.168.2.0/24 via 192.168.10.254 dev eth0
192.168.3.0/24 via 192.168.10.254 dev eth0
192.168.4.0/24 via 192.168.10.254 dev eth0
192.168.5.0/24 via 192.168.10.254 dev eth0
192.168.10.0/24 via 192.168.10.254 dev eth0
192.168.101.0/24 via 192.168.10.254 dev eth0
192.168.201.0/24 via 192.168.10.254 dev eth0
192.168.205.0/24 via 192.168.10.254 dev eth0
10.10.10.0/24 via 192.168.10.254 dev eth0

DEVICE=eth1
BOOTPROTO=none
HWADDR=00:23:7D:FD:90:F8
ONBOOT=yes
HOTPLUG=no
DHCP_HOSTNAME=server.miodominio.it
IPADDR=192.168.11.31
NETMASK=255.255.255.0
#GATEWAY=192.168.11.254
TYPE=Ethernet
USERCTL=no
IPV6INIT=no
PEERDNS=yes

GATEWAY0=192.168.11.254
NETMASK0=0.0.0.0
ADDRESS0=0.0.0.0

Per funzionare funziona e sembra fare il routing corretto ma lanciando il comando /sbin/route -n ottengo il seguente output (in ordine modificato per raggruppare prima tutte le route instradate attraverso eth0):

Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 192.168.10.254 255.255.255.0 UG 0 0 0 eth0
192.168.2.0 192.168.10.254 255.255.255.0 UG 0 0 0 eth0
192.168.3.0 192.168.10.254 255.255.255.0 UG 0 0 0 eth0
192.168.4.0 192.168.10.254 255.255.255.0 UG 0 0 0 eth0
192.168.5.0 192.168.10.254 255.255.255.0 UG 0 0 0 eth0
192.168.101.0 192.168.10.254 255.255.255.0 UG 0 0 0 eth0
192.168.201.0 192.168.10.254 255.255.255.0 UG 0 0 0 eth0
192.168.205.0 192.168.10.254 255.255.255.0 UG 0 0 0 eth0
10.10.10.0 192.168.10.254 255.255.255.0 UG 0 0 0 eth0
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.11.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
0.0.0.0 192.168.11.254 0.0.0.0 UG 0 0 0 eth1

Non è sbagliato?
Come mai la subnet 192.168.10.0 viene instradata con "0.0.0.0" invece che con 192.168.10.254?

[tHeGoOd]

frakka ma che cavolo, io vorrei risponderti ma te fai sempre domande difficilissime!

[tHeGoOd]

Tipo, perchè la tua rete privata ha tutte quelle sottoreti differenti?

[tHeGoOd]

Cmq direi che è normale, nel senso che per la sottorete 192.168.10.0 non hai bisogno di passare da un gateway perchè ci sei collegato direttamente! Non sapendo il significato dello 0.0.0.0 mi sento di pensare che intende che non devi passare dal gateway ma mandare direttamente all'ip destinazione

[frakka]

? Difficilissime?


Quelle subnet sono il risultato di 4 anni di crescita incontrollata, in cui diverse sedi sono state informatizzate un pezzo alla volta, connettendole tra loro come era possibile al momento. Ieri è venuto un consulente Fastweb per discutere del passaggio dalla fascia "small business" alla fascia "top", che dovrebbe permetterci una drastica riconfigurazione delle reti, attualmente connesse tra loro tramite VPN e ponti radio. Quelle subnet sono le reti locali delle sedi remote.

[frakka]

Cmq direi che è normale, nel senso che per la sottorete 192.168.10.0 non hai bisogno di passare da un gateway perchè ci sei collegato direttamente! Non sapendo il significato dello 0.0.0.0 mi sento di pensare che intende che non devi passare dal gateway ma mandare direttamente all'ip destinazione

E quello che hai descritto sarebbe un comportamento piuttosto normale ed è quello che pensavo di ottenere impostando quelle route.
Temo però che in realtà ci siano dei problemi, che portano randomicamente ad un instradamento sbagliato od ad un conflitto con le regole di IPtables.

In particolare, l'agente di BackupExec randomicamente fallisce il task ed il supporto tecnico ha identificato la causa del problema nella fase in cui la connessione si sposta nel range delle porte dinamiche. Però se fosse un problema di firewall sulla eth0 il task non dovrebbe riuscire mai. Invece a volte va a buon fine, altre si interrompe immediatamente ed altre ancora si interrompe verso la fine, al momento di effettuare la verifica del backup (e quindi quando, presumo, chiusa la connessione sulle porte dinamiche attraverso le quali ha effettuato il backup ne cerca di aprire un altra su altre porte dinamiche per effettuare la verifica...).

Non sò se può essere utile, ma nel file /etc/hosts ci sono anche le seguenti righe:
127.0.0.1 server.miodominio.lan server localhost.localdomain localhost
192.168.10.31 server.miodominio.lan server
192.168.11.31 server.miodominio.it
I nomi " server.miodominio.lan" e "server" si ripetono quindi per 127.0.0.1 e per 192.168.10.31. Non è sbagliato? Potrebbe causare confusione?

[frakka]

In particolare, l'agente di BackupExec randomicamente fallisce il task ed il supporto tecnico ha identificato la causa del problema nella fase in cui la connessione si sposta nel range delle porte dinamiche. Però se fosse un problema di firewall sulla eth0 il task non dovrebbe riuscire mai. Invece a volte va a buon fine, altre si interrompe immediatamente ed altre ancora si interrompe verso la fine, al momento di effettuare la verifica del backup (e quindi quando, presumo, chiusa la connessione sulle porte dinamiche attraverso le quali ha effettuato il backup ne cerca di aprire un altra su altre porte dinamiche per effettuare la verifica...).

Sono "piuttosto convinto" che la configurazione di iptables sia corretta (ho provato anche con un ACCEPT incondizionato su lo ed eth0 ed anche con un ACCEPT su tutto ciò che non proviene e non va verso eth1) ma il problema rimane invariato) quindi stò cercando un altra possibile spiegazione per questo problema, per quanto assurda possa sembrare...

[tHeGoOd]

Le route sembrano ok. Non dovrebbe essere un problema loro anche perchè il routing è fatto pacchetto per pacchetto, se ti si interrompe solo al momento della creazione di una connessione può essere il firewall o quel doppio nome sull'hosts. In realtà non dovrebbe dare problemi, ma se BackupExec (che non conosco) cerca di collegarsi ad un server locale tramite il nome server.miodominio.lan, in alcuni casi questo può essere risolto come 127.0.0.1 e in altri con 192.168.10.31. Se il server ascolta solo su una delle due porte, allora quando si prova quella sbagliata non va una cippa

[frakka]

Le route sembrano ok. Non dovrebbe essere un problema loro anche perchè il routing è fatto pacchetto per pacchetto, se ti si interrompe solo al momento della creazione di una connessione può essere il firewall o quel doppio nome sull'hosts. In realtà non dovrebbe dare problemi, ma se BackupExec (che non conosco) cerca di collegarsi ad un server locale tramite il nome server.miodominio.lan, in alcuni casi questo può essere risolto come 127.0.0.1 e in altri con 192.168.10.31. Se il server ascolta solo su una delle due porte, allora quando si prova quella sbagliata non va una cippa

Potrebbe essere e anche se l'agente di BE non credo funzioni proprio così mi sembra una motivazione più plausibile.
Lunedì farò le verifiche del caso, grazie!!