Newsgroup: it.comp.os.linux.sys
Titolo: Ipchains e forward, perde il Masq ?!?

Ciao a tutti,
ho uno strano problema che si manifesta su un pc sul quale ho
installato una RH 6.1 con Kernel 2.2.12
Ho configurato detta LinuxBox per svolgere funzioni di router/firewall
e Dial on Demand tramite l'opzione demand di PPP per condividere
l'accesso a Internet da parte di un paio di PC con W98
A occhio e croce funziona tutto bene se non per il fatto che ogni
tanto i client con Win non riescono piu' ad uscire in internet, mentre
la connessione e' ancora attiva e dalla LinuxBox si esce
tranquillamente.
Dopo diverse prove mi sono accorto che disabilitando la regola di
masquerading e riabilitandola senza toccare altro tutto riprende il
suo corso.
La connessione rimane attiva per diverse ore al giorno (l'ADSL in
quella zona non c'e') e il problema purtroppo non si manifesta sempre.
Non sono riuscito ancora a capire se sia un problema di kernel, di
firewall o che cosa.
Le regole del firewall sono settate tutte come filtri in INPUT tranne
il DENY sul forward seguito ovviamente dalla regola che maschera tutta
la rete con indirizzi di classe C.
Non sto a postare lo script per Ipchains, per non diventare
kilometrico, ma se puo' servire a capire meglio o qualcuno me lo
richiede lo faro'.
Qualche anima pia ha per caso una buona idea a tal proposito?!?
La cosa si risolve come dicevo prima semplicemente lanciando lo script
che toglie il firewall e quello che lo riattiva, pero' siccome io non
presidio sempre la postazione, da spiegare ad un utente Win (alle
prime armi) che si deve connettere alla macchina, digitare username
ecc. ecc. diventa un po' lunga. :-))
|----
|Stefano Orsi
|Email: 
s.orsixxxflashnet.it
|http: www.geocities/wallStreet2153
*** Remove xxx from Email address ***

Manda lo script. Una curiosita': hai compilato il masquerade come
modulo?


Mi rispondo da solo, come fanno i matti ;-)
Posto per maggiore chiarezza parte del log dei messaggi di sistema:
=============================================================
Jul 11 11:29:05 selenia named[369]: listening on [151.15.134.250].53
(ppp0)
Jul 11 11:29:05 selenia named[369]: deleting interface
[151.15.152.4].53
Jul 11 11:29:05 selenia named[369]: USAGE 963307745 962872713
CPU=17.67u/8.73s
Jul 11 11:29:05 selenia named[369]: NSTATS 963307745 962872713 A=1043
PTR=426
Jul 11 11:29:05 selenia named[369]: XSTATS 963307745 962872713 RR=487
RNXD=49
Jul 11 11:46:52 selenia named[369]: reloading nameserver
Jul 11 11:46:53 selenia named[369]: Forwarding source address is
[0.0.0.0].401
Jul 11 11:46:53 selenia named[369]: Ready to answer queries.
Jul 11 11:46:59 selenia network: Disabling IPv4 packet forwarding
succeeded
Jul 11 11:47:00 selenia named[369]: reloading nameserver
Jul 11 11:47:00 selenia named[369]: Forwarding source address is
[0.0.0.0].401
Jul 11 11:47:00 selenia named[369]: Ready to answer queries.
==============================================================
A mio avviso, e controllando anche quello dei giorni passati
sembrerebbe che il DNS  tagli il forwarding source address a default
route 0.0.0.0, ma e' regolare?
Nella riga dopo si puo' vedere come addirittura venga disabilitato,
suppongo a livello di kernel l' IPv4 forwarding.
Esaminando anche i log degli altri giorni, mi pare di capire che cio'
avvenga quando named effettua lo scambio con gli altri dns.
Ho dichiarato nelle zone un paio di domini virtuali con indirizzi di
rete interna in classe C, forse questa cosa da' fastidio a named?    
Il Dns non e' effettivamente un servizio necessario e quindi lo posso
disabilitare, se cosi' funziona potrei ritenermi soddisfatto, ma e'
giusto per saperne un po' di piu'....
Grazie anticipate per chi proporra' un suggerimento
|----
|Stefano Orsi
|Email: 
s.or...@ogcs.com
|http: 
www.ogcs.com


modulo?
Ciao,
no e' un kernel 2.2.12-20 gia' precotto della RH 6.0 (o 6.1 non
ricordo) ed e' integrato.
Lo script nelle parti che interessano (ho lasciato solo porta http, le
altre dovrebbero andare bene), e' questo:
================================================================
IPCHAINS="/sbin/ipchains"
INTERFACE2="ppp0"
MASQ=
192.168.0.0/24
  $IPCHAINS -P input ACCEPT
                  $IPCHAINS -P forward DENY
                  $IPCHAINS -P output ACCEPT
$IPCHAINS -A input -i $INTERFACE2 -p tcp -s 0/0 --destination-port 80
-j DENY
$IPCHAINS -A input -i $INTERFACE2 -p udp -s 0/0 --destination-port 80
-j DENY 
 $IPCHAINS -A forward -s $MASQ -j MASQ
===============================================================================0
come regole di Output non c'e' nulla.
Secondo me pero', come ho detto nel altro mio messaggio, considerando
che il firewall funziona e sono i Client Win a non riuscire piu' a
navigare, credo che il problema dipenda da qualche settaggio errato
nel DNS che risiede sulla stessa macchina.


succeeded
Soluzione trovata:
non era questione, ne' di Ipchains, ne del DNS, semplicemente la
funzione network di redHat ricaricava e attivava le varie interfacce.
Non so perche' il comando IPv4 forward era disabilitato nel file
/etc/sysconfig/network. (forse avro' usato Linuxconf una volta o due
;-))
Rimesso ad un valore diverso da 'no' tutto si e' messo a funzionare
regolarmente.
