slacky.eu

Salve a tutti trovo ultimamente difficoltà nell'avviare automaticamente il firewall all'avvio del sistema. Dico "ultimamente" perchè il problema è cominciato a verificarsi dopo un reset improvviso causato da una mancanza d'alimentazione.

Come nelle altre discussioni pubblicate in questo forum ho seguito precedentemente tutti i suggerimenti e nel mio caso ho scelto di rendere avviabile il file /etc/rc.firewall richiamandolo in /etc/rc.d/rc.local . Tutto andava dunque bene fino a quando non è avvenuto il fatidico reset.

Ora il problema non è propriamente quello d'avviare il firewall (perchè facendo #iptables -L noto effettivamente che il firewall si avvia in modo corretto) ma quello d'avviare alcune funzioni del firewall, ovvero dopo un normale avvio quando mi collego con amule parte in low-id ma se (da root) faccio poi partire il file /etc/rc.firewall e tento la connessione con amule il problema sparisce e si collega in high-id.
Il problema quindi è che l'avvio del firewall non è completo (o così sembra!) e così devo riavviarlo manualmente ad ogni avvio!

Ho fatto una ricerca ed ho trovato che dopo un normale avvio digitando #iptables -L ottengo tante righe in particolare queste:

Chain nicfilt (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
logdrop all -- anywhere anywhere

Chain s0 (1 references)
target prot opt source destination
f0to1 all -- anywhere localhost
logdrop all -- anywhere anywhere

se riavvio successivamente /etc/rc.firewall in modo manuale da root ottengo nel punto dell'output indicato sopra:

Chain nicfilt (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
RETURN all -- anywhere anywhere
logdrop all -- anywhere anywhere

Chain s0 (1 references)
target prot opt source destination
f0to1 all -- anywhere localhost
f0to1 all -- anywhere host205-207.pool8258.interbusiness.it
logdrop all -- anywhere anywhere

come mai allora c'è questa discordanza??

hummm
magari il tuo script parte prima o in contemporanea con un altro?

hai porvato a mfarlo aprtire alla fiendi tutto oppure non so mi verrebbe da pensare di piazzare uno sleep per ritardarne la partenza...

Codice: Seleziona tutto

iptables -A INPUT -p tcp --dport 4662 -j ACCEPT
iptables -A INPUT -p udp --dport 4665 -j ACCEPT

sono sicuro non si tratta della mancata alimentazione

ad ogni modo è un problema del tuo firewall....hai provato a caricare i moduli di iptables ?

orso75 ha scritto:hummm
magari il tuo script parte prima o in contemporanea con un altro?

..saperlo!!! dove potrei cercare?

hai porvato a mfarlo aprtire alla fiendi tutto oppure non so mi verrebbe da pensare di piazzare uno sleep per ritardarne la partenza...

...come faccio a farlo partire alla fine?? nel file rc.local è l'unica istruzione che carico!

OhiOhiOhi ha scritto:sono sicuro non si tratta della mancata alimentazione

di che alimentazione ti stai riferendo? quella del pc?
....sono sicuro che quando sotto linux la corrente se ne va si perdono parte delle impostazioni a seconda del momento: infatti su 5 volte che mi è successo finora solo una volta ho perso le impostazioni, per esempio, di amule, mentre per le altre volte è andato tutto ok. Con l'ultimo reset il firewall, come ho detto, è cominciato a funzionare male......impostazioni perse? mah! il fatto è che ho riprovato ANCHE a cancellare il file rc.firewall e a riconfigurarlo (sempre con guarddog) ma il problema persiste:impostazioni caricate parzialmente!

Codice:
iptables -A INPUT -p tcp --dport 4662 -j ACCEPT
iptables -A INPUT -p udp --dport 4665 -j ACCEPT

queste sono le righe per il corretto funzionamento di amule, vero? bene, su rc.firewall sono già presenti, non per niente all'avvio manuale funziona tutto ok.

Ma ditemi una cosa: una volta reso avviabile il rc.firewall con "chmod 755" dovrebbe funzionare o no se lo uso da utente normale? Perchè all'avvio (sempre da utente) mi da una serie di questi messaggi tutti uguali:

iptables v1.3.3: can't initialize iptables table `filter': Permission denied (you must be root)
Perhaps iptables or your kernel needs to be upgraded.

è normale che non abbia i permessi per farlo? (mentre da root va tutto ok)

....hai provato a caricare i moduli di iptables ?

se intendi questi che ottengo con un "lsmod"

ipt_state 536 53 (autoclean)
ipt_REJECT 3352 4 (autoclean)
ipt_limit 888 6 (autoclean)
ipt_LOG 3448 6 (autoclean)
ip_conntrack_ftp 3888 0 (unused)
ip_conntrack 19460 1 [ipt_state ip_conntrack_ftp]
iptable_filter 1740 1 (autoclean)
ip_tables 12096 5 [ipt_state ipt_REJECT ipt_limit ipt_LOG iptable_filter]
.....

allora ti rispondo che mi si caricano già tutti all'avvio.

cosa mi sfugge???
Grazie.Ciao

Ma ditemi una cosa: una volta reso avviabile il rc.firewall con "chmod 755" dovrebbe funzionare o no se lo uso da utente normale? Perchè all'avvio (sempre da utente) mi da una serie di questi messaggi tutti uguali:

iptables v1.3.3: can't initialize iptables table `filter': Permission denied (you must be root)
Perhaps iptables or your kernel needs to be upgraded.

è normale che non abbia i permessi per farlo? (mentre da root va tutto ok)

è normale; indipendentemente dal fatto che lo script sia eseguibile da utente iptables vuole (giustamente) essere eseguito da root; prova a dare un comando di iptables da utente (come

Codice: Seleziona tutto

  /usr/sbin/iptables -F

) e te ne accorgerai

piuttosto vedi se all'avvio iptables si "lamenta" con

Codice: Seleziona tutto

 dmesg | grep iptables

Scusate per l' intromissione ma tanto per capirci, come si fa a sapere se all' avvio del pc iptables è in funzione? Che domandona eh? Purtroppo l' ignoranza si combatte male. ciao.

all'avvio del pc il fw di linux è sempre in funzione perchè è parte integrante del kernel; iptables è solo l'interfaccia verso di esso

Paoletta ha scritto:all'avvio del pc il fw di linux è sempre in funzione perchè è parte integrante del kernel; iptables è solo l'interfaccia verso di esso

Thanks!

all'avvio del pc il fw di linux è sempre in funzione perchè è parte integrante del kernel; iptables è solo l'interfaccia verso di esso

è probabile che allora iptables si avvii in automatico "dimenticandosi" di caricare il file rc.firewall o caricando magari un file diverso da quello creato da guarddog? ... è strano che si dimentichi perchè altrimenti dovrebbe andare tutto normalmente altrimenti perchè allora ho una parte delle porte chiuse (tipo quelle per amule)?

prova a dare un comando di iptables da utente (come
Codice:
/usr/sbin/iptables -F
) e te ne accorgerai

....infatti! stesso messaggio.

piuttosto vedi se all'avvio iptables si "lamenta" con
Codice:
dmesg | grep iptables

nessuna lamentela da parte di iptables......boh!

altri suggerimenti??

Se non hai indicato erroneamente i path nel tuo post originale (e hai rc.firewall in /etc/ e non in /etc/rc.d/rc.firewall ) prova a creare un link simbolico a rc.firewall in questo modo :

Codice: Seleziona tutto

ln -s /etc/rc.firewall /etc/rc.d/rc.firewall

e a togliere il richiamo da rc.local, o anche a copiare il file li (non so se funge il link simbolico)...
In teoria rc.local dovrebbe essere l'ultimo ad essere caricato, ma se metti rc.firewall in /etc/rc.d/rc.firewall esso verrà richiamato automaticamente dai vari rc.inet e in questo modo se il problema è il prima o dopo dovrebbe risolversi!

Se non hai indicato erroneamente i path nel tuo post originale (e hai rc.firewall in /etc/ e non in /etc/rc.d/rc.firewall ) prova a creare un link simbolico a rc.firewall in questo modo :
Codice: Seleziona tutto
ln -s /etc/rc.firewall /etc/rc.d/rc.firewall
e a togliere il richiamo da rc.local, o anche a copiare il file li (non so se funge il link simbolico)...
In teoria rc.local dovrebbe essere l'ultimo ad essere caricato, ma se metti rc.firewall in /etc/rc.d/rc.firewall esso verrà richiamato automaticamente dai vari rc.inet e in questo modo se il problema è il prima o dopo dovrebbe risolversi!

sbadatamente non l'ho detto ma avevo anche creato il link simbolico su /etc/rc.d/ visto che il file rc.intet2 ha una istruzione per caricarlo.

Wait! ho controllato il file rc.init2: per controllare se il file rc.firewall è eseguibile c'è l'istruzione

Codice: Seleziona tutto

-x /etc/rc.d/rc.firewall

ma questa stranamente non funziona da console (da root)!! manca qualcosa prima di "-x" o è tutto normale??

riporto l'errore:

Codice: Seleziona tutto

bash: -x: command not found

Codice: Seleziona tutto

bash: -x: command not found

il -x è un parametro del comando test (man test)...per avviare quel file da console devi fare

Codice: Seleziona tutto

 /etc/rc.d/rc.firewall [/ocde]

...per avviare quel file da console devi fare

Codice: Seleziona tutto

 /etc/rc.d/rc.firewall [/ocde][/quote]
chiaro, non lo mettevo in dubbio.

[quote]il -x è un parametro del comando test (man test)...[/quote]
Il dubbio era: sarà forse scritta un'istruzione sbagliata in rc.inet2 ('-x' invece quindi di 'test -x FILE') per cui il funzionamento del firewall ne è compromesso? NO! ho fatto una prova per capirlo:
1) ho commentato tutto cio che riguardava il firewall in rc.local
2) ho cancellato il collegamento /etc/rc.d/rc.firewall
3) ho riavviato il pc
4) facendo lsmod nessun modulo riguardante il firewall si era caricato!
5) ho creato quindi SOLAMENTE il collegamento in /etc/rc.d/
6) ho riavviato il pc
7) facendo lsmod tutti (almeno credo! se volete sapere quali guardate in qualche risposta precedente) i moduli del firewall erano attivi
8 ) ho capito quindi che il file rc.inet2 funziona bene così come è stato scritto
9) ma purtroppo ancora una volta amule non funziona in high-id!

si potrebbe ipotizzare che il file rc.firewall sia scritto male, ma così non è, perchè se poi lo avvio (da root) manualmente, improvvisamente, dopo aver provato la connessione ad un altro server di amule, funziona in high-id. Come mai le porte per amule non si avviano in modo automatico con tutti i moduli del firewall?


NB: prima di provare l'avvio manuale ho provato a collegarmi a molti server per vedere se era il server sfigato o meno, ma ho ottenuto sempre low-id.

ho trovato qualcosa di nuovo: se attivo il firewall soltanto in maniera manuale funziona tutto correttamente se e soltanto se lo attivo dopo essermi collegato in internet. Se lo faccio prima sono costretto a riavviarlo anche dopo la connessione.
Si tratta quindi di un problema non legato all'avvio in modo automatico ma all'avvio prima o dopo la connessione internet!

In questo modo,cioè avviandolo dopo la connessione in internet non è che per caso tutto funziona perchè in realtà il firewall fa finta di funzionare??

Qualche idea

mmhh

slacky.eu

guarddog iptables avvio amule

guarddog iptables avvio amule