Newsgroup: it.comp.os.linux.sys
Titolo: Problemi con iptables

 Relaying not allowed',
Porta: 25, Protezione (SSL): No, Errore del server: 550, Numero di errore:
0x800CCC79
In piu' se scarico i messaggi dai NG mi scarica un solo msg invece dei
soliti 1000 e +.
Convinto che il problema fossero le regole impostate, per fare delle prove
ho tolto tutto tranne il POSTROUTING ma il problema non e' scomparso.
script:
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o *interf_esterna* -s *lan_interna* -j
MASQUERADE
Questo semplice script non mi fa inviare la posta ne ricevere le news
Come fo per inviare le mail con OE o altro client di posta?
E' possibile che linux modifichi i pacchetti in modo che quelli sulla porta
25 non vengano riconosciuti dal server smtp? o magani non ci arriva neanche
al server di tiscali.... visto la velocita' (istantanea) con cui mi ritorna
il messaggio d'errore...!
Grazie a tutti


devi abilitare il traffico dall'interno all'esterno...
iptables -t filter -i *inter_interna* -p all -s 
10.0.0.0/24
 -j ACCEPT
iptables -t filter -i lo -p all -s 
10.0.0.0/24
 -j ACCEPT // per il loopback
--------------------------------
Inviato via 
http://usenet.libero.it


Questa regola ce l'ho messa (...in modo diverso)
Ti posto tutto lo script, magari ti viene in mente qualcosa. eth0 e'
esterna. eth1 e' interna
iptables -F
iptables -F -t nat
iptables -X
iptables -Z
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P PREROUTING ACCEPT
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians
iptables -A INPUT -i eth0 -s 
10.0.0.0/8
 -j DROP
iptables -A INPUT -i eth0 -s 
172.16.0.0/12
 -j DROP
iptables -A INPUT -i eth0 -s 
192.168.0.0/16
 -j DROP
iptables -A INPUT -i eth0 -s 
224.0.0.0/4
 -j DROP
iptables -A INPUT -i eth0 -s 
240.0.0.0/5
 -j DROP
iptables -A INPUT -i eth0 -d 
127.0.0.0/8
 -j DROP
iptables -A INPUT -s 
127.0.0.0/8
 -j ACCEPT
iptables -A OUTPUT -d 
127.0.0.0/8
 -j ACCEPT
iptables -A INPUT -i eth1 -s 
192.168.1.0/24
 -j ACCEPT            #accetto
tutto dalla LAN
iptables -A OUTPUT -o eth1 -d 
192.168.1.0/24
 -j ACCEPT
iptables -A FORWARD -s 
192.168.1.0/24
 -d 0/0 -j ACCEPT    #forward di tutta
la lan in ogni destinazione
iptables -A FORWARD -s 0/0 -d 
192.168.1.0/24
 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -s 
192.168.1.0/24
 -j MASQUERADE
con questo script  funzionano tutti i protocolli http, https, ftp, pop3
ecc.... ma non l'smtp
restituisce l'errore postato in precedenza
Ciao e grazie

 0x800CCC79
Questo e' tipico del caso in cui venga usato un server smtp che non e' del
provider che in quel momento ci sta fornendo la connettivita', non e' un
problema di iptables (altrimenti, altro che errore 550...). Tuttavia, c'e' IMHO
un problema sulla correttezza dello script che hai postato successivamente:
rispondo separatamente all'altro post.
bye G.L.
--
La logica non attiene alla verosimiglianza delle ipotesi,
ma alla coerenza delle tesi con le ipotesi.

 Ciao e grazie
E' che se tu hai connettivita' pinco, devi usare come smtp per tutte le tue
caselle di posta, anche di provider differenti da quello che ti fornisce la
connettivita', il server smtp di pinco.
E' la prima cosa ovvia per aver maggiore probabilita' di combattere chi fa
spam, dal momento che chiunque *non* deve avere relay smtp aperti al mondo...


 ESTABLISHED, RELATED -j ACCEPT
Dimenticavo: replicala pari pari sulla catena INPUT per le connessioni originate
dalla linux-box, probabilmente altri malfunzionamenti da te segnalati derivano da
questo.



Avevi ragione... iptables e linux non c'entravano niente. Impostando come
server smtp, quello da contratto del router telecom funziona tutto
benissimo.
Ho rivisto un po le regole ed alcune erano inutili, come mi avevi detto tu
nell'altro post, ma una cosa nn ho capito:
perche' secondo te le regole su INPUT con sorgente le classi private sono
inutili. Leggendo in giro tutti parlano di queste regole come protezione
allo spoofing.
Ciao e grazie

 spoofing.
Non ho detto che e' inutile proteggersi da quelle classi di indirizzi: ho detto
che, data la policy di default, queste classi non entrerebbero in INPUT anche
non specificando quelle regole. Le _regole_ sono inutili, non gli obbiettivi che
si prefiggono. Anche se e' vero che non e' possibile sostenere cio' che dico in
assoluto: dipende da cosa c'e' prima e dopo nello script. Comunque in effetti la
loro presenza non guasta, assieme al parametro kernel rp_filter impostato
opportunamente: possono essere ridondanti.


 iptables -t nat -A POSTROUTING -o eth0 -s 
192.168.1.0/24
 -j MASQUERADE
Non è preciso preciso... la man page di iptables raccomanda -j DNAT --to
<l'IP dell'interfaccia d'uscita> mentre MASQUERADE è per interfaccie con
indirizzi variabili(aka dialup).
-- 
cat <<EOSIGN
Paolo Giarrusso, aka Blaisorblade(togliere solo REMOVEONLYTHIS per rispondere)
Kernel 2.4.20/2.5.63 on an i686; Linux registered user n. 292729
EOSIGN