Newsgroup: it.comp.os.linux.sys
Titolo: [accademico] iptables nat e ping

devo collegare due reti di due ditte vicine
ho tirato su una macchinetta con iptables e due schede di rete
la $ditta1 deve accedere a 3 host di $ditta2
mentre ditta2 deve accedere alla macchina stessa alle porte di samba
(che shara delle dir caricate via nfs)
nulla di complicato... $ditta1 accede e pinga gli host aperti e ditta2
accede agli share e pinga la macchina che fa nat
il problema, è solo che dalla macchina che fa nat pingo gli host della
$ditta1 ma non pingo quelli di $ditta2
perche??
lo script funziona, voglio solo sapere perchè succede questo
ps. graditi feedback se sono scritte stupidaggini
posto lo script:
---------------------------------------------------
#! /bin/sh
modprobe ip_tables
modprobe iptable_nat
modprobe ip_conntrack_ftp
DITTA2="eth1"
DITTA1="eth0"
echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -t nat -F
iptables -F
iptables -X
iptables -Z
#permette di accedere alla macchina dalla rete DITTA2 sulle porte
specificate
iptables -A INPUT -i $DITTA1 -j ACCEPT
iptables -A OUTPUT -o $DITTA1 -j ACCEPT
iptables -A INPUT -i $DITTA2 -p tcp --dport 139 -j ACCEPT
iptables -A INPUT -i $DITTA2 -p tcp --dport 445 -j ACCEPT
iptables -A OUTPUT -o $DITTA2 -j ACCEPT
#Permetti il ping
iptables -A INPUT -i $DITTA2 -p icmp --icmp-type echo-request -j
ACCEPT
iptables -A INPUT -i $DITTA1 -p icmp --icmp-type echo-request -j
ACCEPT
iptables -A INPUT -p icmp -j ACCEPT
# Accetto tutti i pacchetti sul loopback
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
#$IPTABLES -A FORWARD -i $DITTA1 -o $DITTA2 -d 192.168.1.60 -j ACCEPT
iptables -A FORWARD -i $DITTA2 -o $DITTA1 -m state --state
ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i $DITTA1 -o $DITTA2 -m state --state
ESTABLISHED,RELATED -j ACCEPT
# DITTA1--->DITTA2
iptables -A FORWARD -i $DITTA1  -o $DITTA2 -d 192.168.1.1 -j ACCEPT
iptables -A FORWARD -i $DITTA1  -o $DITTA2 -d 192.168.1.3 -j ACCEPT
iptables -A FORWARD -i $DITTA1  -o $DITTA2 -d 192.168.1.252 -j ACCEPT
iptables -t nat -A POSTROUTING -o $DITTA2 -j MASQUERADE

 ho tirato su una macchinetta con iptables e due schede di rete
Perché non fare una vpn? 30 minuti, forse meno, nei due gw dei
siti installi openvpn e shorewall. Magicamente avrai le due sedi che
colloquiano senza problemi.
Michele

On 22 Ott, 12:35, Michele Petrazzo

perche' le due reti non devono essere aperte volutamente l'una
all'altra, ma devono essere limitate nei "servizi" da offrire

cris... ha scritto:

Quindi, con shorewall, nei due punti metti delle regole che fanno si che
non possono passare nell'interfaccia tun0 certi dati/porte.
Se non ti piace ancora... toccherà dare una guardata alle regole che hai 
scritto :)

 lo script funziona, voglio solo sapere perchè succede questo
No, il problema è che sbagli approccio.
Utilizzare una VPN è l'approccio giusto, come ti hanno già suggerito.


le due reti sono a poche centinaia di metri di distanza collegate con
un bridge wifi... andare a scomodare la vpn mi sembrava esagerato...
poi dovrei avere due macchine
ripeto, lo script funziona
non capisco perche' la ethernet di $ditta2 che e' connessa fisicamente
alla rete non pinga gli host mentre da un pc della $ditta1 tramite
forward si...

 forward si...
Puoi schematizzare un po' meglio, chè non si capisce un apascio?
La macchina che fa da nat ha un'interfaccia $DITTA2 in 192.168.1/qualcosa
e l'altra interfaccia $DITTA1 che indirizzamento ha?
E' il natter stesso che non riesce a pingare indirizzi corrispondenti
all'indrizzamento di $DITTA2?

 all'indrizzamento di $DITTA2?
si era cosi'.... e comunque era in un altra sottorete
Ho risolto,
la scheda $ditta2 era andata in half-duplex...
forzandola in full duplex tutto funziona perfettamente....
io non ho capito il motivo... misteri della fede

 io non ho capito il motivo... misteri della fede
Figurati noi...
cosa *5&&@¼£ ci azzecca ethernet con il firewall o il nat non si sa.
Hai sicuramente fatto (magari involontariamente) altro.

 dovrei avere due macchine
Se c'è un BRIDGE cosa te ne fai del nat ?
Il routing, questo sconosciuto.

 Hai sicuramente fatto (magari involontariamente) altro.
Più che altro: quella cosa poteva capitare in caso di duplex mismatch
(scheda in half, porta switch in full) ma avrebbe anche comportato
malfunzionamento al resto del traffico.
Però se il mismatch va e viene, potrebbe anche essere una spiegazione...
-- 
http://bofhskull.wordpress.com/

sembra comunque di aver risolto,
grazie a tutti!
ps. grazie anche per i consigli, vedro' di prenderli in considerazione
in futuro...
pps. la situazione attuale per la cronaca l'ho ereditata, anche se con
parametri diversi ha funzionato cosi' per oltre 5 anni, quindi mi
hanno detto di non cambiare nulla
Grazie di nuovo

 Il routing, questo sconosciuto.
A me sembra che quello che ha problemi di comprensione sia tu...
Ho una situazione (vagamente ma un po' più complessa) simile in una 
delle sedi dell'azienda dove lavoro.
Sede A ----wifi bridge---> sede B.
2 VLan, quindi differenti 2 subnet. La subnet della sede A è portata, 
via WiFi bridge fino ad un AccessPoint nella sede B, attaccato a questo 
access point c'è l'interfaccia "sedeA" del router(ip forwarding) che fa 
anche da firewall. L'interfaccia "sedeB" di siffatto router/firewall 
forwarda, con una precisa ACL, le richieste di una delle sedi verso 
l'altra e viceversa.
La supponenza, questa conosciuta...
-- 
GenTLe ...di Varese, provincia.
La mia HP: 
http://digilander.iol.it/thegentle/index.htm
La vita è fatta anche di ardue scelte, tipo: "Un cuba... O una birra 
media???"

 iptables -t nat -A POSTROUTING -o $DITTA2 -j MASQUERADE
Perché fai il nat dinamico? A che ti serve su una connessione lan-to-lan?
Prova a rimuovere questa riga e vedi se il ping funziona.
Fammi sapere,
Ciao!


 Sede A ----wifi bridge---> sede B.
Embè?
CtRix ha perfettamente ragione.
Se quello tra A e B è un bridge, allora A e B avranno un'interfaccia
sulla stessa subnet, chiamiamola ab.
Basta e avanza il routing, non c'è alcuna necessità di nat.
Su A metto
ip route add $net-b via $ip-b-net-ab
Su B metto
ip route add $net-a via $ip-a-ab
Ora dimmi esattamente a cosa ti serve il nat, invece, potendo fare del
sano ed economico routing.

 ESTABLISHED,RELATED -j ACCEPT
Lezione 0: la catena di OUTPUT si riferisce ai soli pacchetti generati
localmente dal firewall stesso.
Delle due l'una: se l'OP voleva effettivamente concedere al firewall
di poter comunicare con chiunque, in uscita verso $DITTA2, e allora va
bene la regola scritta da lui.
In caso contrario, a cosa servirebbe, esattamente, la regola che 
hai scritto tu?
Solo a consentire l'uscita dal firewall  di pacchetti in risposta
a pacchetti ricevuti dalla subnet $DITTA2 e generati dal firewall
stesso?
Oddio, può aver senso, essendoci una policy DROP in OUTPUT, tabella
di filtering, per consentire, ad esempio, che i pacchetti di risposta
a una sessione ssh iniziata da $DITTA2 verso il firewall, ma ho qualche
dubbio che tu ti riferissi a un simile scenario...

 ci metterei un DROP.
facendo copiaincolla con le varie versioni dello script mi e' rimasto
questo doppione...
.
x il resto appena ho un po' di tempo gli do un'occhiata
Grazie

x quanto riguarda il bridge
la situazione è questa:
$ditta1 ---> FW ---->switch--->ap1===bridge==ap2--->ditta2
io posso gestire FW e $ditta1
gli ap1 e ap2 sono gestiti da $ditta2
attaccato allo switch c'e' una terza ditta che si collega direttamente
a $ditta2 che sono sulla stessa subnet di ditta2

 da $ditta2 si connettono direttamente al samba installato sul fw
In tal caso è sufficiente la regola con ESTABLISHED, RELATED, in effetti.

 Basta e avanza il routing, non c'è alcuna necessità di nat.
Questo l'ho scritto pure io nella risposta all'OP.
(vedi sotto l'analisi dello script)


 dubbio che tu ti riferissi a un simile scenario...
Non c'è nessuna sessione ssh verso il firewall da Ditta2, non essendoci 
nessuna policy in input che accetti la porta 22.


 In tal caso è sufficiente la regola con ESTABLISHED, RELATED, in effetti.
:-)


 Il routing, questo sconosciuto.
Scusa CtRiX, per qualche ragione ho letto "firewall" invece di "nat" e 
ti ho risposto in malomodo...


 nessuna policy in input che accetti la porta 22.
"per esempio". :-)

 Chiarivo, nulla di male, no?
Si, era il tono da maestrino che mi dava sui nervi, tutto qui :-)


 
ATTENZIONE: Commento generale e in tono da maestrino, si impone ai soggetti
sensibili di leggere con gli occhi chiusi.
Lezione -1: non si dovrebbe smettere mai di ricevere o di dare lezioni,
nemmeno sulle cose che si dovrebbe o si conosce bene, nemmeno se danno
fastidio, anzi se non danno fastidio probabilmente sono lezioni inutili.
Lezione -2: Questo specialmente in un news group che consente di ignorare le
lezioni sgradite, e obbligherebbe a usare le e-mail personali per regolare
i conti personali.