Newsgroup: it.comp.os.linux.iniziare
Titolo: SSH & Netfilter

Scusate ragazzi ma che differenza c'è tra fare un port forwarding
con ssh o con netfilter(iptables)?
Grazie per la vostra attenzione
Newbie

 con ssh o con netfilter(iptables)?
Nel primo caso *non* hai un port-forward ma un tunnel realizzato con un
applicativo.
Nel secondo hai solamente una riscrittura degli indirizzi negli header del
pacchetto in corsa.
Molto a grandi linee..
Anzi, a strisce...
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Skull says:
The old signature is gone...
Won't you suggest me a new one?!?

 Anzi, a strisce...
Molto gentile...ma io sinceramente non ho capito un h
Newbie

 Molto gentile...ma io sinceramente non ho capito un h
Orco... :-D
Ci riprovo:
immagina di avere 3 macchine, rispettivamente A, B e C
Per questioni di struttura di rete, A può contattare B (e viceversa) e B
può contattare C (e viceversa), ma A e C non si possono vedere.
Hai necessità di contattare una porta di C (immaginiamo la 80) da A.
Puoi:
- installare un proxy applicativo su B che giri a C le richieste di A.
Buona soluzione, ma richiede un software specifico per il protocollo da
utilizzare
- usare un port forwarding su B usando netfilter:
iptables -A PREROUTING -t nat -s A -d B --dport 8000 -j DNAT
--to-destination C:80
questa da sola funziona purchè B sia un router nella tratta tra A e C (cfr
http://www.skullkrusher.net/linux/iptables.html
 e port forwarding dentro
la stessa rete ).
Letteralmente dice a B: "prendi tutto quello che risulta essere diretto a
te sulla porta 8000 e rigiralo alla porta 80 di C".
Il tutto avverrà a solo livello di rete, maneggiato direttamente dal
kernel, che si occuperà di prendere i singoli pacchetti che rispondono ai
requisiti e di sostituire l'indirizzo di B con quello di C e fare
viceversa con quanto torna indietro.
Piccolo difetto: bisogna andare a toccare le regole del firewall (a volte
rischiando di fare casini) e per farlo bisogna essere root (rischiando di
fare anche peggio...)
- usare ssh da A a B per creare un tunnel e convogliarci dentro del
traffico verso C:
su A si dà il comando:
ssh -L 8000:C:80 utente@B
questo mette in comunicazione la porta 8000 di A (sull'ip di loopback) con
la 80 di C, passando dentro alla sessione ssh stabilita con B. Come?
Se su A dai un netstat -natp, vedrai che su A, la porta 8000 risulta in
ascolto, e ad ascoltare c'è ssh. Se A punta il browser su
http://127.0.0.1:8000
, contatterà quindi ssh.
Questi (ssh) piglierà tutto quello che viene infilato lì dentro (la
richiesta http fatta dal browser) e userà il canale ssh per portarla fino
a B.
A questo punto, si vedrà partire da B (aperta con porta effimera su B da
ssh stesso) e diretta alla porta 80 di C, contenente le stesse richieste
http di A.
Quindi in questo caso la richiesta http da A a C viaggia in realtà su 3
tratte distinte: c'è una connessione da A a sè stesso
(
http://127.0.0.1:8000
), una connessione ssh da A a B, e una connessione
da B a C. Ci viaggia dentro sempre lo stesso *contenuto*, ma sono sessioni
tcp diverse, mentre nel caso precedente avevamo una unica sessione tcp che
veniva "modificata al volo" strada facendo.
Come limitazioni in questo caso abbiamo che ci deve essere un server ssh
su B e che possiamo portare solamente un protocollo che usi solamente un
socket tcp (ftp che ne usa due non funzionerebbe, ad esempio...).
Spero sia più chiara della precedente ;-)
Aggiungo comunque che la stessa cosa può essere fatta in altri X modi
(rinetd, ad esempio) ma la comodità di farlo con ssh è che non hai bisogno
di usare altro software oltre a quello già installato e che la
comunicazione tra A e B, passando dentro ssh, viene crittata.
Hola...


> Spero sia più chiara della precedente ;-)
Molto esaustivo...
Grazie sei meglio di un manuale ;-)