Newsgroup: it.comp.os.linux.sys
Titolo: Instradare porta 80 in un pc della lan

Salve ragazzi.
Ho un gateway con installato debian (che e' su internet) e instrada via
port forwarding internet al mio pc desktop (ubuntu).
Ho bisogno di instradare i pacchetti di richiesta che arrivano al gateway
dalla porta 80 al mio pc (che ha un server apache) che pero' e'
all'interno della mia rete.
Ho sintetizzato la mia situazione con 2 script di bash (non sono quelli
che uso e non uso le variabili, ma questi sono un riassunto piu' chiaro):
# lato gateway  (debian)
ETHGATEWAY="eth0"
ETHMODEM="eth1"
IPGATEWAY="192.168.1.1"
IPPUBBLICO="$(ip ricavato con uno script)"
IPMODEM="10.0.0.1"
iptables -I INPUT -i $ETHGATEWAY -s $IPAPACHE -j ACCEPT
iptables -t nat -A POSTROUTING -s $1 -o $ETHMODEM -j MASQUERADE
iptables -t nat -A PREROUTING -p tcp -i eth0 -d $IPPUBBLICO --dport 80 -j
DNAT --to 
192.168.1.2:80
   # Funzionera' ???
# lato desktop  (ubuntu)
ETHALGATEWAY="eth0"
IPAPACHE="192.168.1.2"
iptables -t nat -A PREROUTING -p tcp -i $ETHALGATEWAY -d $IPPUBBLICO
--dport 80 -j DNAT --to $IPAPACHE:80   # Funzionera' ???
Ho provato ad aggiungere quelle regole col prerouting ("funzionera?") ma
non sembra funzionare. Se dal mio desktop provo con firefox ad aprire
l'indirizzo pubblico mi va in timeout e con l'indirizzo del gateway mi da'
connessione rifiutata.
Ho sbagliato qualcosa? Voi come fate? Sono parecchio arrugginito con
iptables...
Grazie
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 iptables...
google risolve...sempre! (terzo risultato di iptables port forwarding)
http://www.debian-administration.org/articles/73
Ciao Jack

 Ciao Jack
8-) Cavolo, come hai fatto?? Sono due giorni che cerco qualcosa di cosi'
specifico... provo subito, per il momento grazie Jack !


 specifico... provo subito, per il momento grazie Jack !
Niente da fare, mi da' subito connessione non riuscita (rifiutata).
Quelle due regole le ho provate nel solo gateway.
Come interfacce ho provato "eth1" (il modem), poi "eth0" (la lan) e anche
ppp0 (il punto a punto) ma non va mai.
Devo magari impostare qualche regola anche nel desktop? Quest'ultimo ha
gia' gli instradamenti con queste regole:
iptables -I INPUT 2 -i $INTERF_LAN -s $IPDESKTOP -j ACCEPT
iptables -t nat -A POSTROUTING -s $IPDESKTOP -o $INTERF_MODEM -j MASQUERADE
sysctl -w net.ipv4.ip_forward=1
Grazie


 sysctl -w net.ipv4.ip_forward=1
Idem come sopra.. Semmai va messa sul gateway.

 sulla porta 8000...
Ho provato lasciando come porta di ascolto "80" e vedendo da tcpdump e dal
port scanner "sembrerebbe" andare lo stesso. Unica cosa e' che nel log di
apache non c'e' traccia ne' di accesso ne' di errore.
Per la precisione mi fa cosi': se dal firefox dello stesso pc (quello col
webserver) inserisco l'IP pubblico mi resta a caricare senza fare niente
(nella status bar non compare niente). Se provo con 127.0.0.1 mi funziona,
se provo con l'indirizzo locale del gateway il firefox mi ritorna subito
connessione rifiutata.
Se provo da un altro computer passando per il proxy, il gateway mi lascia
una pagina (con la sua firma) che mi dice "(111) connection refused".
Ma il pc flank (il port scanner che uso) continua a dire che la porta 80
e' proprio "open" e non protetta o chiusa.
L'unica cosa che mi viene da pensare e' che dovrei instradare anche le
richieste del dns (porta 53) del web server verso il gateway, ma il mio
gateway usa gia', logicamente, quella porta per ricevere le query dagli
host. Questo server dns (del gateway) non fa niente di speciale, passa le
interrogazioni a quello della telecom; non deve risolvere dei nomi di host
interni.
I comandi che ho dato per arrivare a questo punto sono questi:
IP_PUBBLICO_DEL_GATEWAY="80.2.3.4"
IP_DEL_SERVER_WEB="192.168.1.2"
# script nel gateway
iptables -A PREROUTING -t nat -p tcp -d 80.2.3.4 --dport 80 -j DNAT
--to-destination 
192.168.1.2:80
iptables -t filter -P FORWARD ACCEPT
echo 1 > /proc/sys/net/ipv4/ip_forward
#script nel server web
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
echo 1 > /proc/sys/net/ipv4/ip_forward
Fiducioso attendo vostri lumi.



Secondo metodo di risoluzione dei problemi: aggirare il problema.
Dovresti fare un paio di prove per verificare la fattibilità, ma questo 
metodo può funzionare:
la prova consiste nell'aprire sul gateway la porta 80 (ad esempio con nc 
da root:
# nc -l 80
Se connettendoti dall'esterno arrivi a netcat, allora puoi procedere con 
la seconda fase: mettere sul gateway un Apache come reverse proxy.
Ci penserà poi Apache a ricevere le richieste dal mondo, tradurle, 
mandarle al(ai) server interno(i) e reinviare al visitatore la risposta.
Cerca "Apache reverse proxy" su google (senza doppi apici)
Luca
PS: se non riesci a raggiungere il netcat sulla macchina gateway, non 
funzionerà né questo metodo né quello con iptables

 l'indirizzo ip pubblico. Ma perche' cosi' non dovrebbe andare?
E' roba che scrissi oramai 10 anni fa, ma č ancora lě e iptables č
sempre lo stesso.
Vedi se aiuta:
http://www.skullkrusher.net/linux/iptables.html
(sito assolutamente non mantenuto da lustri...)
-- 
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/

 IP_DEL_SERVER_WEB="192.168.1.2"
Se, come credo, il client da cui stai facendo i test ha un indirizzo nella
stessa subnet di 192.168.1.2, è normale che non funzioni.
Un tcpdump (il miglior amico del network-man insieme al target TRACE di iptables...)
sul client stesso ti avrebbe immediatamente chiarito il perché.
Mettiamo che il client abbia indirizzo 192.168.1.5.
Per connettersi alla porta 80 di 80.2.3.4, 192.168.1.5 manderà un pacchetto TCP
con flag SYN; tale pacchetto sarà inoltrato, a layer 2, al default gateway.
Il default gateway vedrà tale pacchetto, e, conformemente a quanto gli hai
detto di fare. cambierà, prima di instradarlo, l'indirizzo di destinazione, inoltrando
dunque il pacchetto a 192.168.1.2
Riassumiamo:
Questo è il pacchetto che tu invii dal tuo client
src 192.168.1.5 dst 80.2.3.4 proto tcp sport xxxx dport 80 flag SYN
Questo è il pacchetto in uscita dal gateway, viste le regole da te scritte:
src 192.168.1.5 dst 192.168.1.2 proto tcp sport xxxx dport 80 flag SYN
e tale pacchetto arriva a 192.168.1.2 il quale risponderà come segue
src 192.168.1.2 dst 192.168.1.5 proto tcp sport 80 dport xxxx flag SYN ACK
e tale pacchetto sarà inviato *direttamente* a 192.168.1.5, *senza* passare
dal gateway, visto che i due host stanno sulla stessa subnet.
Morale: 192.168.1.5 si vedrà arrivare un pacchetto SYN ACK da un host al quale
non ha mai inviato alcun SYN e risponderà inevitabilmente con un RST.

 Cerca "Apache reverse proxy" su google (senza doppi apici)
Purtroppo apache non lo posso installare nel gateway perche'... non ha
abbastanza ram! E' un nslu2 (da 10 watt) e gli si puo' chiedere al massimo
di fare da router/proxy! Volendo si riesce anche a far partire, ma finisce
subito nell'area di swap e ogni richiesta di pagina e' camaleontica! Per
questo cercavo più una soluzione di routing.
Mi hai comunque dato una ottimo consiglio Luca Pascali, ho visto che
esiste "pound" che e' un'utility specializzata nel reverse proxy e load
balancing. Se funziona mi piacerebbe poter direzionare le richieste al mio
pc e quando questo e' spento che si passi a lighttpd; sarebbe anche meglio
di come l'avevo pensata io!
Faccio qualche prova e poi vi faccio sapere.
fapo1


 non ha mai inviato alcun SYN e risponderà inevitabilmente con un RST.
Prima di tutto grazie della risp dettagliata whiplash.
Non sono così infarinato di challenge/response, ma credevo che nel mio
caso il gateway ricevesse un pacchetto son src=192.168.1.5 e dst=80.2.3.4,
che poi andava a finire in ppp0 e veniva quindi mascherato e demascherato
subito (senza bisogno di uscire perche' ppp0 e' gia' 80.2.3.4).
Quando ad es. attivo il server web direttamente sul gateway mi funziona
sia se dal browser del client richiedo 
http://192.168.1.2/
 che
http://80.2.3.4/
 . Inoltre riscontro l'errore (con le regole di
prerouting) anche passando dal proxy del gateway.
Pero' la tua tesi e' compatibile con quello che riscontro.
In questo momento ho finito di aggiornare la debian del gateway e provero'
con un reverse proxy, come consigliatomi da Luca Pascali.
Per il momento grazie!


Allora, ho provato col reverse proxy e dal client (che e' anche il server
web) mi ha rifiutato la connessione sia dall'indirizzo pubblico che da
quello di rete.
Se pero' dal gateway provo ad aprire una pagina web con lynx (un browser
testuale):
127.0.0.1 - funziona!
192.168.1.2 (ip del gateway) - non funziona (rifiutato)
80.2.3.4 (ip pubblico) - non funziona (rifiutato)
[RISOLTO] (*con proxy reverse al posto del routing)
Il mio problema era che pound si mette in ascolto sull'indirizzo
127.0.0.1, mentre dovevo specificare "0.0.0.0" .
Adesso va che e' una scheggia!!
Probabilmente prima non andava anche perche' mi ostinavo a specificare gli
indirizzi ip locali e di rete, mentre sarebbe stato meglio, forse, non
specificarli...
Grazie mille a tutti per il supporto tecnico e morale! :D
E meno male che esiste it.comp.os.linux.sys ! E' un pozzo di conoscenza
imo!
fapo1


 subito (senza bisogno di uscire perche' ppp0 e' gia' 80.2.3.4).
No.
-t nat PREROUTING agisce, come suggerisce il nome della catena, prima del routing.
Dunque l'indirizzo di destinazione viene cambiato *prima* del routing e lo scenario
è esattamente quello che ti ho descritto, credimi. :)