Al momento, ci sono alcuni protocolli di applicazione TCP/IP che non funzionano con il Mascheramento IP di Linux perchè hanno delle particolari condizioni sui numeri delle porte oppure codificano all'interno del flusso dei dati gli indirizzi TCP/IP e/o i numeri di porta. Per funzionare, questi protocolli necessitano di proxies speciali o particolari moduli di IP-Masq nel codice di Mascheramento.
A meno che non venga specificato diversamente, il Mascheramento di IP di Linux non tocca i servzi in ingresso.
Ci sono alcuni modi per permettere anche queste operazioni. Se non hai bisogno di un livello di protezione molto elevato, puoi semplicemente indirizzare o redirigere verso altre porte IP. Il modo più sicuro per ottenere questo è quello di usare IPPORTFW. Per maggiori informazioni vedi la sezione strumenti per indirizzare alle porte.
Se desideri un certo grado di controllo sulle connesioni in ingresso, puoi configurare un TCP-wrappers o ricorrere a Xinet, con cui puoi permettere il passaggio solamente ad alcuni IP specificati. Il Firewall Toolkit TIS è un posto consigliato per cercare programmi e informazioni su questi argomenti.
Maggiori dettagli sulla sicurezza degli accessi li puoi trovare in
TrinityOS e IP Masquerade Resource.
** Il riferimeto Linux Masquerade Application è un buon punto informativo per saperne di più sulle applicazioni che fuzionano attraverso il Mascheramento IP. Questo sito è stato recentemente preso in carico da Steve Grevemeyer, che lo ha dotato di un completo database. Grande risorsa!
In generale, ogni applicazione che usa TCP e UDP standard dovrebbe funzionare. Se hai suggerimenti o consigli, porta il tuo contributo in IP Masquerade Resource .
Clients di rete che certamente funzionano con IP-Masq
tutte le piattaforme supportate; client di ricerca di files client (non tutti i clients archie sono supportati)
tutte le piattaforme supportate, con il modulo ip_masq_ftp.o per le connessioni FTP attive.
Gopher tutte le piattaforme supportate
tutte le piattaforme supportate; navigazione in rete
tutti i clients IRC su molte piattaforme supportate; DCC è supportato attraverso il modulo ip_masq_irc.o
(USENET) tutte le piattaforme supportate; client per le notizie da USENET
tutte le piattaforme supportate, con la opzione di Mascheramento ICMP nel kernel
tutte le piattaforme supportate, clients per email
tutte le piattaforme supportate, Secure TELNET/FTP clients
tutte le piattaforme supportate, email servers like Sendmail, Qmail, PostFix, etc.
tutte le piattaforme supportate, sessioni remote
sulle piattaforme basate su UNIX e Windows; alcune potrebbero però non funzionare bene
Windows (probabilmente tutte le piattaforme), navigazione nella realtà virtuale
client tutte le piattaforme supportate
Worlds Windows, programma 3D per chat di tipo Client-Server
tutte le piattaforme supportate, con il modulo ip_masq_cuseeme caricato, vedi la sezione CuSeeme per maggiori informazioni.
tutti i clients supportati. Richiede che il kernel linux sia compilato con il supporto per IPPORTFW e che ICQ sia configurato per stare dietro un proxy NON-SOCKS. proxy. Una completa spiegazione di tale configurzione si trova nella sezione ICQ.
Phone 3.2 Windows, comunicazioni audio peer-to-peer, altri ti possono raggiungere solo se tu dai inizio alla chiamata, ma non ti possono chiamare, a meno che non hanno abbiano predisposto un indirizzamento di porta specifico.. Vedi la sezione Indirizzatori.
Wave Player Windows, streaming audio in rete
Windows, comunicazioni peer-to-peer attraverso lavagna, testo e audio, altri ti possono raggiungere solo se tu dai inizio alla chiamata, ma non ti possono chiamare, a meno che non hanno abbiano predisposto un indirizzamento di porta specifico.. Vedi Indirizzatori.
Audio Player Windows, streaming audio in rete, si può raggiungere una più elevata qualità con il modulo UDP ip_masq_raudio.
Speech Player 1.1b Windows, streaming audio in rete
Windows, dopo aver applicato la patch per ip_masq_vdolive
Chat 0.9a Windows, programma 3D di chat di tipo Client-Server
Vedi LooseUDP per la patch per LooseUDP
Funziona, ma è necessario che la porta TCP 116 e 118 e la porta UDP 6112 siano indirizzate mediante IPPORTFW alla macchina su cui si trova il gioco. Vedi indirizzatori. Nota che i servers FSGS e Bnetd richiedono ancora IPPORTFW, in quanto non sono ancora stati riscritti secondo NAT.
1.4 Works with LooseUDP patch and new NAT-friendly .DLLs from Activision
Reign 1.4 Funziona con la patch per LooseUDP; oppure bisogna che la porta TCP 116 e 118 e la porta UDP 6112 siano indirizzate mediante IPPORTFW alla macchina su cui si trova il gioco. Vedi indirizzatori.
Funziona con la patch per LooseUDP; oppure bisogna che la porta TCP 116 e 118 e la porta UDP 6112 siano indirizzate mediante IPPORTFW alla macchina su cui si trova il gioco. Versioni più recenti di Diablo usano solamente la porta TCP 6112 e UDP 6112. Vedi anche indirizzatori.
Gear 2 Funziona con la patch per LooseUDP; oppure bisogna che la porta TCP 116 e 118 e la porta UDP 6112 siano indirizzate mediante IPPORTFW alla macchina su cui si trova il gioco.Vedi indirizzatori.
I/II/III Funziona senza problemi, ma richiede il modulo ip_masq_quake se, dietro alla macchina Mascherata, c'è più di un giocatore di Quake I/II/III.
Nota anche che questo modulo supporta per default solo Quake I e QuakeWorld. Se ti serve il supporto per Quake II o porte non di defaults per il server, leggi la sezione sulla installazione dei moduli nelle istruzioni in kernels 2.0.x e kernels 2.2.x.
Funziona con la patch per LooseUDP e applicando IPPORTFW verso la porta 6112 TCP e UDP alla macchina Mascherata su cui si trova il gioco. Vedi indirizzatori.
Funziona con la patch per LooseUDP
net-acct package Linux, network administration-account package
Telnet 2.3.08 DOS, un pacchetto contenente telnet, ftp, ping, etc.
for Windows MS-Windows, controllo remoto di un PC via TCP/IP, funziona solo se è un client, ma non se non è stata predisposta una specifica porta di indirizzamento. Vedi indirizzatori.
Watch usa NTP (network time protocol)
i programmi in H.323 - MS Netmeeting, Intel Internet Phone Beta 2 - si connette, ma la voce viaggia solo nella direzione in uscita. Per una possibile soluzione, prova a vedere il gateway H.323 in Equivalence's PhonePatch.
Esiste adesso un modulo ALPHA, reperibile sul sito WWW di IP-Masq oppure in http://www.coritel.it/projects/sofia/nat.html che funziona con Microsoft Netmeeting v3.x su kernels 2.2.x. C'è anche un'ltra versine del modulo sul sito WWW di IP-Masq, specifico per Netmeeting 2.x con kernels 2.0.x, ma non supporta Netmeeting v3.x.
Streaming Media Viewer Beta 1 Non riesce a connettersi al server
CoolTalk Non riesce a connettersi all'altra parte.
Al momento non funziona (fa assunzioni errate a proposito degli indirizzi).
Questo paragrafo intende fornire una guida più approfondita per l'uso dello strumento di firewall IPFWADM, nel kernel 2.0.x. Per le istruzioni per IPCHAINS vedi più avanti.
Diamo un esempio per un sistema Mascherato con firewall dietro a una connessione PPP con indirizzo IP statico (le istruzioni per il caso di IP dinamico sono incluse, ma commentate)
L'interfaccia con internet è 192.168.0.1 e l'indirizzo IP dell'interfaccia PPP è stata cambiata. Ogni interfaccia di entrata e di uscita è stata riportata singolarmente per eseguire l'IP spoofing, l'instradamento e/o il mascheramento.
E' PROIBITO (o meglio: respinto) tutto quanto non sia esplicitamente consentito. Se la macchina su cui è in funzione l'IP-Masq si blocca dopo aver implementato questo script rc.firewall, vai a verificare di averlo adattato esattamente per la tua configurazione e cerca i messaggi di errore del firewall nel file di SYSLOG /var/log/messages o /var/adm/messages.
In TrinityOS -capitolo 10 e Pagina WWW sul firewall del GreatCircle puoi trovare esempi più completi e dettagliati di regole IPFWADM forti per PPP, modem via cavo, etc.
NOTA: Se il tuo ISP (PPP, ADSL, modem via cavo, etc) ti foornisce un indirizzo IP dinamico, NON PUOI CARICARE queste istruzioni al boot. Puoi caricare il file OGNI VOLTA che ti viene fornito un nuovo IP oppure rendere più intelligenti le istruzioni contenute in /etc/rc.d/rc.firewall. A questo scopo gli utenti PPP possono decommentare le righe opportune nella sezione "Dynamic PPP IP fetch", dopo averle ben comprese.
In http://www.ecst.csuchico.edu/dranch/LINUX/TrinityOS.wri puoi trovare altre informazioni sulle regole forti e gli indirizzi IP dinamici.
Esistono anche dei programmi con GUI per la creazione di Firewall. Vedi FAQs.
Infine, se usi un indirizzo IP statico, cambia la riga "ppp_ip= "your.static.PPP.address"" con il tuo indirizzo effettivo.
----------------------------------------------------------------
#!/bin/sh
#
# /etc/rc.d/rc.firewall: un esempio di istruzioni di firewall IPFWADM semi-forti
#
PATH=/sbin:/bin:/usr/sbin:/usr/bin
# fa un prova, aspetta un po', poi cancella tutte le regole di firewall.
# de-commenta le righe che seguano, se vuoi che iil firewall si disabiliti automaticamente
# dopo 10 minuti.
# (sleep 600; \
# ipfwadm -I -f; \
# ipfwadm -I -p accept; \
# ipfwadm -O -f; \
# ipfwadm -O -p accept; \
# ipfwadm -F -f; \
# ipfwadm -F -p accept; \
# ) &
# Carica tutti i moduli richiesti per IP-Masq
#
# NOTA: Carica solamente i moduli IP-Masq che ti servono. Tutti i moduli che sono al
# momento diponibili sono mostrati qui di seguito, ma commentati, per escluderli dal caricamento.
#
# Necessario per caricare i moduli
#
/sbin/depmod -a
# Supporto per un corretto Mascheramento del trasferimento di file via FTP con il metodo FORTE
#
/sbin/modprobe ip_masq_ftp
# Supporto per il Mascheramento IP di RealAudio in UDP.Senza questo modulo, RealAudio FUNZIONA
# ugualmente, ma in modo TCP. Cio' può essere causa di una riduzione delle qualità del suono
#
#/sbin/modprobe ip_masq_raudio
# Supporto del Mascheramento IP del trasferimento files in IRC DCC
#
#/sbin/modprobe ip_masq_irc
# Supporto del Mascheramento IP di Quake e QuakeWorld per default. Questi moduli sono
# per più utenti dietro un IP-Masq server. Se intendi giocare con Quake I, II, e III,
# usa il secondo esempio
# NOTA: se ricevi il messaggio ERROR nel caricare il modulo per Quake, significa che
# stai lavorando con kernel vecchio, che ha un difetto (bug).
# Conviene fare un aggiornamento ad un kernel piu' recente
#
# Quake I / QuakeWorld (porte 26000 e 27000)
# /sbin/modprobe ip_masq_quake
#
# Quake I/II/III / QuakeWorld (porte 26000, 27000, 27910, 27960)
# /sbin/modprobe ip_masq_quake ports 26000,27000,27910,27960
# Supporto per Mascheramento IP del programma per videoconferenza the CuSeeme
#
# /sbin/modprobe ip_masq_cuseeme
# Supporto del Mascheramento IP del programma per videoconferenza VDO-live
#
#/sbin/modprobe ip_masq_vdolive
# ESSENZIALE: Abilita l'indirizzamento IP, che è disabilitato per default
#
# Utenti Redhat: puoi provare a cambiare l'opzione in /etc/sysconfig/network da:
#
# FORWARD_IPV4=false
# a
# FORWARD_IPV4=true
#
echo "1" > /proc/sys/net/ipv4/ip_forward
# ESSENZIALE: abilita la deframmentazione automatica di IP, che e' disabilitata per default
# Una volta era una opzione durante la compilazione del kernel, ma le cose sono
# cambiate in 2.2.12
echo "1" > /proc/sys/net/ipv4/ip_always_defrag
#
# Utenti con IP dinamico:
#
# Se l'indirizzo IP ti viene assegnato dinamicamente via SLIP,PPP,o DHCP, abilita la seguente
# opzione. Ciò permetterà l'aggiustamento dell'indirizzo dinamico in IP-Masq, rendendo più facile
# il lavoro dei programmi DialD e simili.
#
#echo "1" > /proc/sys/net/ipv4/ip_dynaddr
# Qui devi devi specificare il tuo indirizzo IP Statico.
#
# Se hai un indirizzo IP dinamico, devi fare in modo che queste istruzioni conoscano
# il tuo indirizzo IP ogni volta che questo ti viene fornito.
# A tale scopo, conviene lanciare lo script di una sola riga, che è riportato al
# termine di questo blocco di commenti.
# Nota che gli apici singoli e doppi hanno un DIVERSO significato.
# Utenti di DHCP:
# -----------
# Se la macchina riceve l'indirizzo TCP/IP attraverso DHCP, *e' necessario* abilitare
# il comando commentato, che e' riportato qui sotto (dopo la parte PPP) e sostituire
# la parola "ppp0" con il nome della connessione ESTERNA verso internet (eth0, eth1, etc).
# Bisogna anche fare attenzione che il server DHCP puo' cambiare il tuo indirizzo IP.
# In vista di questa possibilita', gli utenti devono configurare il proprio client DHCP
# in modo che esegua le regole di firewall ogni volta che la connessione DHCP
# viene ripristinata.
#
# NOTA n.1: Alcuni clients DHCP piu' recenti, come *pump*, NON sono in grado di eseguire
# gli scripts ad ogni ripristino della connessione; in questo caso devi cambiare il client
# con qualcosa tipo "dhcdcd" o "dhclient".
#
# NOTA n.2: La sintassi per "dhcpcd" e' stata modificata, nelle ultime versioni.
#
# Le versioni vecchie avevano una sintassi del tipo:
# dhcpcd -c /etc/rc.d/rc.firewall eth0
#
# mentre nelle piu' recenti si usa una sintassi del tipo:
# dhcpcd eth0 /etc/rc.d/rc.firewall
#
#
# Utenti di PPP:
# ----------
# Nel caso non lo sapessi, lo script /etc/ppp/ip-up e' sempre eseguito al momento
# dello stabilirsi della connessione. Utilizzando questo script, possiamo quindi eseguire
# le regole di firewall, ottenere il nuovo indirizzo PPP IP e aggiornare la regole
# di firewall forti.
#
# Se esiste gia' il file /etc/ppp/ip-up, lo editi e aggiungi una linea, verso la fine, che contenga
# "/etc/rc.d/rc.firewall"
#
# Se non hai il file /etc/ppp/ip-up, ti serve creare il seguente link, in modo che da lanciare
# lo script /etc/rc.d/rc.firewall.
#
# ln -s /etc/rc.d/rc.firewall /etc/ppp/ip-up
#
# Se il file /etc/ppp/ip-up file esiste già, lo dovresti editare per aggiungere
# una riga, verso la fine del file, che contenga "/etc/rc.d/rc.firewall".
#
# * a questo punto potresti abilitare il comando di shell #ed, che trovi piu' avanti *.
#
# Utenti di PPP e di DHCP:
# -------------------
# Togliete il segno # sulla linea qui di sotto e mettete un segno # all'inizio della linea
# che la segue
#
#ppp_ip = "`/sbin/ifconfig ppp0 | grep 'inet addr' | awk '{print $2}' | sed -e 's/.*://'`"
#
ppp_ip="your.static.PPP.address"
#
# MASQ timeouts
#
# timeout di 2 ore per le sessioni TCP
# timeout di 10 sec che segue il ricevimento del pacchetto TCP/IP "FIN"
# timeout di 160 sec per il traffico UDP (rilevante per gli utenti ICQ Mascherati)
#
/sbin/ipfwadm -M -s 7200 10 60
#############################################################################
# Politiche di reject per Incoming, flush e set default.
# In pratica la politica di default non ha importanza, perchè c'è una regola
# valida per tutti con deny e log
#
/sbin/ipfwadm -I -f
/sbin/ipfwadm -I -p reject
# sono validi i pacchetti da interfaccia locale, macchina locale, per qualsiasi destinazione
#
/sbin/ipfwadm -I -a accept -V 192.168.0.1 -S 192.168.0.0/24 -D 0.0.0.0/0
# sono da respingere i pacchetti da interfaccia remota, che dichiarano di provenire
# da macchine locali, che fanno spoofing di IP
/sbin/ipfwadm -I -a reject -V $ppp_ip -S 192.168.0.0/24 -D 0.0.0.0/0 -o
# sono accettabili pacchetti da interfaccia remota, di qualunque preovenienza, diretti
# verso un indirizzo PPP permanente
#
/sbin/ipfwadm -I -a accept -V $ppp_ip -S 0.0.0.0/0 -D $ppp_ip/32
# è valida l'interfaccia di loopback.
#
/sbin/ipfwadm -I -a accept -V 127.0.0.1 -S 0.0.0.0/0 -D 0.0.0.0/0
# Regola valida per tutto; tutto il resto dei pacchetti in entrata non e' valido e
# ne viene fatto rapporto. E' un peccato che non esista una opzione log tra le
# politiche, ma questa istruzione sopperisce.
#
/sbin/ipfwadm -I -a reject -S 0.0.0.0/0 -D 0.0.0.0/0 -o
#############################################################################
# Politiche di reject per Outgoing, flush e set default.
# In pratica la politica di default non ha importanza, perchè c'è una regola
# valida per tutti con deny e log
#
/sbin/ipfwadm -O -f
/sbin/ipfwadm -O -p reject
#
# sono validi i pacchetti da interfaccia locale, da qualsiasi origine e destinati alla rete locale
/sbin/ipfwadm -O -a accept -V 192.168.0.1 -S 0.0.0.0/0 -D 192.168.0.0/24
# non sono validi i pacchetti in uscita, vesro la rete locale, su interfaccia remota, stuffed routing
#
/sbin/ipfwadm -O -a reject -V $ppp_ip -S 0.0.0.0/0 -D 192.168.0.0/24 -o
# non sono validi i pacchetti da rete locale, su interfaccia remota, stuffed masquerading
#
/sbin/ipfwadm -O -a reject -V $ppp_ip -S 192.168.0.0/24 -D 0.0.0.0/0 -o
# non sono validi i pacchetti da rete locale, su interfaccia remota, stuffed masquerading
#
/sbin/ipfwadm -O -a reject -V $ppp_ip -S 0.0.0.0/0 -D 192.168.0.0/24 -o
# sono validi tutti gli altri pacchetti in uscita, su interfaccia remota
#
/sbin/ipfwadm -O -a accept -V $ppp_ip -S $ppp_ip /32 -D 0.0.0.0/0
# è valida l'interfaccia di loopback.
#
/sbin/ipfwadm -O -a accept -V 127.0.0.1 -S 0.0.0.0/0 -D 0.0.0.0/0
# Regola valida per tutto; tutto il resto dei pacchetti in uscita non e' valido e
# ne viene fatto rapporto. E' un peccato che non esista una opzione log tra le
# politiche, ma questa istruzione sopperisce.
#
/sbin/ipfwadm -O -a reject -S 0.0.0.0/0 -D 0.0.0.0/0 -o
#############################################################################
# Politiche di deny per forwarding, flush e set default.
# In pratica la politica di default non ha importanza, perchè c'è una regola
# valida per tutti con deny e log
/sbin/ipfwadm -F -f
/sbin/ipfwadm -F -p deny
# Mascheramento da rete locale su interfaccia locale, per qualunque destinazione.
#
/sbin/ipfwadm -F -a masquerade -W ppp0 -S 192.168.0.0/24 -D 0.0.0.0/0
#
# Regola valida per tutto; tutto il resto dei pacchetti in forwarding non e' valido e
# ne viene fatto rapporto. E' un peccato che non esista una opzione log tra le
# politiche, ma questa istruzione sopperisce.
/sbin/ipfwadm -F -a reject -S 0.0.0.0/0 -D 0.0.0.0/0 -o
Con IPFWADM puoi fermare il traffico verso un particolare sito usando le regole -I, -O o -F . Ricorda che l'insieme delle regole viene letto in sequenza dall'alto verso il basso e che "-a" significa "aggiungi in fondo" ("append") all'insieme delle regole già definito. Ne segue che ogni restrizione specifica deve preccdere le reggole generali (globali). Ad esempio:
Uso delle regole -I. Probabilmente è la cosa più veloce, ma può fermare solamente le macchine locali, mentre il firewall stesso può ancora accedere al sito proibito. Questo potrebbe essere quello che desideri. Ma forse no.
Nelle regole in /etc/rc.d/rc.firewall:
... inizio delle istruzioni -I ... # respingi e registra i pachhetti sulla interfaccia locale, macchina locale, # con destinazione 204.50.10.13 # /sbin/ipfwadm -I -a reject -V 192.168.0.1 -S 192.168.0.0/24 -D 204.50.10.13/32 -o # accetta i pacchetti sulla interfaccia locale, macchina locale, con qualunque destinazione # /sbin/ipfwadm -I -a accept -V 192.168.0.1 -S 192.168.0.0/24 -D 0.0.0.0/0 ... fine delle istruzioni -I ...
Uso delle regole -O. E' più lento, perchè oltre a far passare i pacchetti per il Mascheramento, ferma il firewall che accede ad un sito vietato.
... inizio delle istruzioni -o ... # respingi e registra i pachhetti con destinazione 204.50.10.13 # /sbin/ipfwadm -O -a reject -V $ppp_ip -S $ppp_ip/32 -D 204.50.10.13/32 -o # accetta tutti gli altri pacchetti sulla interfaccia remota # /sbin/ipfwadm -O -a accept -V $ppp_ip -S $ppp_ip/32 -D 0.0.0.0/0 ... fine delle istruzioni -o ...
Uso delle regole -F. Probabilmente è più lento di -I e anche questo ferma solo le macchine mscherate, il firewall può accedere ad un sito vietato.
... inizio delle istruzioni -F... # Respingi e registra i pachhetti provenienti dalla rete locale, sulla interfaccia PPP, # con destinazione 204.50.10.13. # /sbin/ipfwadm -F -a reject -W ppp0 -S 192.168.0.0/24 -D 204.50.10.13/32 -o # Mascheramento da rete locale su interfaccia locale, per qualunque destinazione # /sbin/ipfwadm -F -a masquerade -W ppp0 -S 192.168.0.0/24 -D 0.0.0.0/0 ... fine delle istruzioni -F. ...
Non è necessaria nessuna regola particolare per permettere a 192.168.0.0/24 di andare verso 204.50.11.0; è già previsto dalle regole generali.
C'è più di un modo per instruire le interfacce conle regole date sopra. Ad esempio, invece di "-V 192.168.255.1" si potrebbe porre "-W eth0"; anzichè "-V $ppp_ip" , si può usare "-W ppp0". Il metodo "-V" è caduto in disuso quando è arrivato IPCHAINS, ma per gli utenti con IPFWADM è molto comodo.
Questa sezioe fornisce un approfondimento sull'uso della funzione di firewall IPCHAINS nei kernels 2.2.x. Vedi le regole date sopra per IPFWADM.
L'esempio che segue è per un sistema di mascheramento/firewall dietro una connessione PPP con IP statico (le istruzioni per IP dinamico sono incluse, ma commentate).
L'interfaccia con internet è 192.168.0.1 e l'indirizzo IP dell'interfaccia PPP è stata cambiata. Ogni interfaccia di entrata e di uscita è stata riportata singolarmente per eseguire l'IP spoofing, l'instradamento e/ il mascheramento.
E' PROIBITO (o meglio: respinto) tutto quanto non sia esplicitamente consentito. Se la macchina su cui è in funzione l'IP-Masq si blocca dopo aver implementato questo script rc.firewall, vai a verificare di averlo adattato esattamente per la tua configurazione e cerca i messaggi di errore del firewall nel file di SYSLOG /var/log/messages o /var/adm/messages.
In TrinityOS -capitolo 10 e Pagina WWW sul firewall del GreatCircle puoi trovare esempi più completi e dettagliati di IPFWADM forti per PPP, modem via cavo, etc.
NOTA 1: I kernels 2.2.x precedenti a 2.2.11 hanno difetto di frammentazione in IPCHAINS che rende gli utenti scopri agliattacchi dall'esterno. E' bene aggiornare il kernel.
NOTA 2: Se il tuo ISP (PPP, ADSL, modem via cavo, etc) ti foornisce un indirizzo IP dinamico, NON PUOI CARICARE queste istruzioni al boot. Puoi caricare il file OGNI VOLTA che ti viene fornito un nuovo IP oppure rendere più intelligenti le istruzioni contenute in /etc/rc.d/rc.firewall. A questo scopo gli utenti PPP possono decommentare le righe opportune nella sezione "Dynamic PPP IP fetch", dopo averle ben comprese.
In http://www.ecst.csuchico.edu/dranch/LINUX/TrinityOS.wri puoi trovare altre informazioni sulle regole forti e gli indirizzi IP dinamici.
Esistono anche dei programmi con GUI per la creazione di Firewall. Vedi FAQs.
Infine, se usi un indirizzo IP statico, cambia la riga "ppp_ip= "your.static.PPP.address"" con il tuo indirizzo effettivo.
#!/bin/sh
#
# /etc/rc.d/rc.firewall: un esempio di istruzioni di firewall IPCHAINS semi-forti
#
PATH=/sbin:/bin:/usr/sbin:/usr/bin
# Carica tutti i moduli richiesti per IP-Masq
#
# NOTA: Carica solamente i moduli IP-Masq che ti servono. Tutti i moduli che sono al
# momento diponibili sono mostrati qui di seguito, ma commentati, per escluderli dal caricamento.
#
# Necessario per caricare i moduli
#
/sbin/depmod -a
# Supporto per un corretto Mascheramento del trasferimento di file via FTP con il metodo FORT
#
/sbin/modprobe ip_masq_ftp
# Supporto per il Mascheramento IP di RealAudio in UDP. Senza questo modulo, RealAudio FUNZIONA
# ugualmente, ma in modo TCP. Cio' può essere causa di una riduzione delle qualità del suono
#
# /sbin/modprobe ip_masq_raudio
# Supporto del Mascheramento IP del trasferimento files in IRC DCC
#
# /sbin/modprobe ip_masq_irc
# Supporto del Mascheramento IP di Quake e QuakeWorld per default. # Questi moduli sono
# per più utenti dietro un IP-Masq server. Se intendi giocare con Quake I, II e III,
# usa il secondo esempio
# NOTA: se ricevi il messaggio ERROR nel caricare il modulo per Quake, significa che
# stai lavorando con un kernel vecchio, che ha un difetto (bug).
# Conviene fare un aggiornamento ad un kernel piu' recente
#
# Quake I / QuakeWorld (porte 26000 e 27000)
# /sbin/modprobe ip_masq_quake
#
# Quake I/II/III / QuakeWorld (porte 26000, 27000, 27910, 27960)
# /sbin/modprobe ip_masq_quake ports 26000,27000,27910,27960
# Supporto per Mascheramento IP del programma per videoconferenza CuSeeme
#
# /sbin/modprobe ip_masq_cuseeme
# Supporto del Mascheramento IP del programma per videoconferenza VDO-live
#
# /sbin/modprobe ip_masq_vdolive
# ESSENZIALE: Abilita l'indirizzamento IP, che è disabilitato per default
#
# Utenti Redhat: potete provare a cambiare l'opzione in /etc/sysconfig/network da:
#
# FORWARD_IPV4=false
# a
# FORWARD_IPV4=true
#
echo "1" > /proc/sys/net/ipv4/ip_forward
#
# ESSENZIALE: abilita la deframmentazione automatica di IP, che e' disabilitata per default
# Una volta era una opzione durante la compilazione del kernel, ma le cose sono
# cambiate in 2.2.12
echo "1" > /proc/sys/net/ipv4/ip_always_defrag
#
# Qui devi devi specificare il tuo indirizzo IP Statico.
#
# Se hai un indirizzo IP dinamico, devi fare in modo che queste istruzioni conoscano
# il tuo indirizzo IP ogni volta che questo ti viene fornito.
# A tale scopo, conviene lanciare lo script di una sola riga, che è riportato al
# termine di questo blocco di commenti.
# Nota che gli apici singoli e doppi hanno un DIVERSO significato.
# Utenti di DHCP:
# -----------
# Se la macchina riceve l'indirizzo TCP/IP attraverso DHCP, *e' necessario* abilitare
# il comando commentato, che e' riportato qui sotto (dopo la parte PPP) e sostituire
# la parola "ppp0" con il nome della connessione ESTERNA verso internet (eth0, eth1, etc).
# Bisogna anche fare attenzione che il server DHCP puo' cambiare il tuo indirizzo IP.
# In vista di questa possibilita', gli utenti devono configurare il proprio client DHCP
# in modo che esegua le regole di firewall ogni volta che la connessione DHCP
# viene ripristinata.
#
# NOTA n.1: Alcuni clients DHCP piu' recenti, come *pump*, NON sono in grado di
# eseguire gli scripts ad ogni ripristino della connessione; in questo caso devi cambiare
# il client con qualcosa tipo "dhcdcd" o "dhclient".
#
# NOTA n.2: La sintassi per "dhcpcd" e' stata modificata, nelle ultime versioni.
#
# Le versioni vecchie avevano una sintassi del tipo:
# dhcpcd -c /etc/rc.d/rc.firewall eth0
#
# mentre nelle piu' recenti si usa una sintassi del tipo:
# dhcpcd eth0 /etc/rc.d/rc.firewall
#
#
# Utenti di PPP:
# ----------
# Nel caso non lo sapessi, lo script /etc/ppp/ip-up e' sempre eseguito al momento
# dello stabilirsi della connessione. Utilizzando questo script, possiamo quindi eseguire
# le regole di firewall, ottenere il nuovo indirizzo PPP IP e aggiornare la regole
# di firewall forti.
#
# Se esiste gia' il file /etc/ppp/ip-up, lo editi e aggiungi una linea, verso la fine, che contenga
# "/etc/rc.d/rc.firewall"
#
#Se non hai il file /etc/ppp/ip-up, ti serve creare il seguente link, in modo che da lanciare
# lo script /etc/rc.d/rc.firewall.
#
# ln -s /etc/rc.d/rc.firewall /etc/ppp/ip-up
#
# * a questo punto potresti abilitare il comando di shell #ed, che trovi piu' avanti *.
#
# Utenti di PPP e di DHCP:
# -------------------
# Togliete il segno # sulla linea qui di sotto e mettete un segno # all'inizio della linea
# che la segue
#
# extip="`/sbin/ifconfig ppp0 | grep 'inet addr' | awk '{print $2}' | sed -e 's/.*://'`"
# Per utenti di PPP con indirizzo IP STATICO
#
extip="il.tuo.indirizzo.statico"
# TUTTI gli utenti di PPP e DHCP devono sistemare la riga seguente con il corretto nome per la
# interfaccia ESTERNA
extint="ppp0"
# Assegna l'indirizzo IP interno
intint="eth0"
intnet="192.168.1.0/24"
#
# MASQ timeouts
#
# timeout di 2 ore per le sessioni TCP
# timeout di 10 sec che segue il ricevimento del pacchetto TCP/IP "FIN"
# timeout di 60 sec per il traffico UDP (rilevante per gli utenti ICQ Mascherati)
#
ipchains -M -S 7200 10 60
#############################################################################
# Politiche di reject per Incoming, flush e set default.
# In pratica la politica di default non ha importanza, perchè c'è una regola
# valida per tutti con deny e log
#
ipchains -F input
ipchains -P input REJECT
# sono validi i pacchetti da interfaccia locale, macchina locale, per qualsiasi destinazione
#
ipchains -A input -i $intint -s $intnet -d 0.0.0.0/0 -j ACCEPT
# sono da respingere i pacchetti da interfaccia remota, che dichiarano di provenire
# da macchine locali, che fanno spoofing di IP
#
ipchains -A input -i $extint -s $intnet -d 0.0.0.0/0 -l -j REJECT
# sono accettabili pacchetti da interfaccia remota, di qualunque preovenienza, diretti
# verso un indirizzo PPP permanente
#
ipchains -A input -i $extint -s 0.0.0.0/0 -d $extip/32 -j ACCEPT
# è valida l'interfaccia di loopback.
#
ipchains -A input -i lo -s 0.0.0.0/0 -d 0.0.0.0/0 -j ACCEPT
# Regola valida per tutto; tutto il resto dei pacchetti in entrata non e' valido e
# ne viene fatto rapporto. E' un peccato che non esista una opzione log tra le
# politiche, ma questa istruzione sopperisce.
#
ipchains -A input -s 0.0.0.0/0 -d 0.0.0.0/0 -l -j REJECT
#############################################################################
# Politiche di reject per Outgoing, flush e set default.
# In pratica la politica di default non ha importanza, perchè c'è una regola
# valida per tutti con deny e log
#
ipchains -F output
ipchains -P output REJECT
#
#sono validi i pacchetti da interfaccia locale, da qualsiasi origine e destinati alla rete locale
ipchains -A output -i $intint -s 0.0.0.0/0 -d $intnet -j ACCEPT
# non sono validi i pacchetti in uscita, vesro la rete locale, su interfaccia remota, stuffed routing
#
ipchains -A output -i $extint -s 0.0.0.0/0 -d $intnet -l -j REJECT
# non sono validi i pacchetti da rete locale, su interfaccia remota, stuffed masquerading
#
ipchains -A output -i $extint -s $intnet -d 0.0.0.0/0 -l -j REJECT
# sono validi tutti gli altri pacchetti in uscita, su interfaccia remota
#
ipchains -A output -i $extint -s $extip/32 -d 0.0.0.0/0 -j ACCEPT
# è valida l'interfaccia di loopback.
#
ipchains -A output -i lo -s 0.0.0.0/0 -d 0.0.0.0/0 -j ACCEPT
# Regola valida per tutto; tutto il resto dei pacchetti in uscita non e' valido e
# ne viene fatto rapporto. E' un peccato che non esista una opzione log tra le
# politiche, ma questa istruzione sopperisce.
ipchains -A output -s 0.0.0.0/0 -d 0.0.0.0/0 -l -j REJECT
#############################################################################
# Politiche di deny per forwarding, flush e set default.
# In pratica la politica di default non ha importanza, perchè c'è una regola
# valida per tutti con deny e log
ipchains -F forward
ipchains -P forward DENY
# Mascheramento da rete locale su interfaccia locale, per qualunque destinazione.
# ipchains -A forward -i $extint -s $intnet -d 0.0.0.0/0 -j MASQ
# Regola valida per tutto; tutto il resto dei pacchetti in forwarding non e' valido e
# ne viene fatto rapporto. E' un peccato che non esista una opzione log tra le
# politiche, ma questa istruzione sopperisce.
ipchains -A forward -s 0.0.0.0/0 -d 0.0.0.0/0 -l -j REJECT
# fine del file
Con IPCHAINS puoi fermare il traffico verso un particolare sito usando le regole di "input", "output" e "forward". Ricorda che l'insieme delle regole viene letto in sequenza dall'alto verso il basso e che "-A" significa "aggiungi in fondo" ("append") all'insieme delle regole già definito. Ne segue che ogni restrizione specifica deve preccdere le reggole generali (globali). Ad esempio:
Uso delle regole di "input".
Probabilmente è la cosa più veloce, ma può fermare solamente le macchine locali, mentre il firewall stesso può ancora accedere al sito proibito. Questo potrebbe essere quello che desideri. Ma forse no.
Nelle regole in /etc/rc.d/rc.firewall:
... inizio delle istruzioni di "input" ... # respingi e registra i pachhetti sulla interfaccia locale, macchina locale, con destinazione 204.50.10.13 ipchains -A input -s 192.168.0.0/24 -d 204.50.10.13/32 -l -j REJECT # # accetta i pacchetti sulla interfaccia locale, macchina locale, con qualunque destinazione ipchains -A input -s 192.168.0.0/24 -d 0.0.0.0/0 -l -j ACCEPT ... fine delle istruzioni di "input" ...
This is the slower method to block traffic because the packets must go through masquerading first before they are dropped. Yet, this rule even stops the firewall machine from accessing the forbidden site.
Uso delle regole di output. E' il metodo più lento per bloccare il traffico, perchè i pacchetti devono prima passare attraverso il mascheramento, prima di essere scartati. Pero' questa regola impedisce anche al firewall di accedere ad un sito vietato.
... inizio delle istruzioni di output ... # respingi e registra i pachhetti con destinazione 204.50.10.13 # ipchains -A output -s $ppp_ip/32 -d 204.50.10.13/32 -l -j REJECT # # accetta tutti gli altri pacchetti sulla interfaccia remota # ipchains -A output -s $ppp_ip/32 -d 0.0.0.0/0 -l -j ACCEPT ... fine delle istruzioni di output ...
Uso delle regole di forward. Probabilmente è più lente nel bloccare il traffico di quelle di 'input' e anche queste fermano solo le macchine mscherate (ad es. le macchine interne), il firewall può ugualmente accedere ad un sito vietato.
... inizio delle istruzioni di forward ... # Respingi e registra i pachhetti provenienti dalla rete locale, sulla interfaccia PPP, # con destinazione 204.50.10.13. # ipchains -A forward -i ppp0 -s 192.168.0.0/24 -d 204.50.10.13/32 -l -j REJECT # Mascheramento da rete locale su interfaccia locale, per qualunque destinazione # ipchains -A forward -i ppp0 -s 192.168.0.0/24 -d 0.0.0.0/0 -j MASQ ... fine delle istruzioni di forward ...
Non è necessaria una regola particolare per permettere a 192.168.0.0/24 di andare versoo 204.50.11.0; è già previsto dalle regole generali.
NOTA: al contrario di IPFWADM, esiste solo un modo per codificare le interfacce nelle regole date sopra. IPCHAINS usea l'opzione "-i eth0", dove IPFWADM aveva sia "-W" per il nome della interfaccia che "-V" per l'indirizzo IP della interfaccia.
Il Mascheramento IP per più di una rete interna è molto semplice. Dopo aver verificato che tutte le reti funzionano (sia quelle interne che quella esterna), devi abilitare il traffico al passaggio sia attraverso le interfacce interne che al Masq-server verso internet.
Poi devi abilitare il Mascheramento sulle interfacce INTERNE.
In questo esempio, due interfacce interne eth1 (192.168.0.1) e eth2 (192.168.1.1) vengono Mascherate dall'interfaccia eth0. Aggiungi quindi le seguenti righe alle regole in rc.firewall
#Enable internal interfaces to communication between each other /sbin/ipfwadm -F -a accept -V 192.168.0.1 -D 192.168.1.0/24 /sbin/ipfwadm -F -a accept -V 192.168.1.1 -D 192.168.0.0/24 #Enable internal interfaces to MASQ out to the Internet /sbin/ipfwadm -F -a masq -W eth0 -S 192.168.0.0/24 -D 0.0.0.0/0 /sbin/ipfwadm -F -a masq -W eth0 -S 192.168.1.0/24 -D 0.0.0.0/0
#Enable internal interfaces to communication between each other /sbin/ipchains -A forward -i eth1 -d 192.168.1.0/24 /sbin/ipchains -A forward -i eth2 -d 192.168.0.0/24 #Enable internal interfaces to MASQ out to the Internet /sbin/ipchains -A forward -j MASQ -i eth0 -s 192.168.0.0/24 -d 0.0.0.0/0 /sbin/ipchains -A forward -j MASQ -i eth0 -s 192.168.1.0/24 -d 0.0.0.0/0
Fai attenzione che è GIUSTO specificare "eth0" più di una volta negli esempi qui sopra. Il kernel linux deve conoscere quale interfaccia viene usata per il traffico IN USCITA (verso internet); dato che eth0 rappresenta tale connessione, viene nominata per ogni interfaccia interna.
E' utile inserire la opzione seguente per il kernel, attraverso l'operazione: echo "1" > /proc/sys/net/ipv4/ip_dynaddr.
Esistono generiche funzioni per l'indirizzamento di porta TCP e/o UDP per il Mascheramento IP: IPPORTFW, IPAUTOFW, REDIR, UDPRED, e altre.
Queste funzioni sono usate tipicamente insieme o in sostituzione di particolari moduli per il Mascheramento IP, come queli per FTP, Quake, etc.
Con gli indirizzatori di porta è possibile ridirigere le connessioni da internet ad una macchina interna, con indirizzo privato, dietro il Masq.server. Questa possibiltà si estende ai protocolli di rete TELNET, WWW, SMTP, FTP (con una patch particolare -vedi oltre), ICQ, e molti altri.
NOTA: Anche se vuoi operare in indirizzamento di porta senza Mascheramento IP, hai UGUALMENTE BISOGNO di abilitare il servizio di Mascheramento IP nel kernel E nella tua direttiva IPFWADM o nella direttiva IPCHAINS, per poter utilizzare le funzioni di indirizzamento in Linux.
Perchè tutta questa varietà di possibilità? IPAUTOFW, REDIR, e UDPRED (tutte le URLs sono in Cosa serve in 2.0.x) sono state le prime funzioni che hanno permesso agli utenti di IP-Masq di utilizzare queste funzionalità. Con il progredire del servizio di Mascheramento in Linux, queste funzioni furono sostituite da IPPORTFW che risolve in modo più intelligente il problema. Dato che adesso sono disponibili strumenti migliori, è' MOLTO SCONSIGLIATO l'uso delle vecchie funzioni, come IPAUTOFW e REDIR, perchè informano correttamente il kernel della loro presenza e possono anche BLOCCARE il server, in alcune condizioni particolari.
NOTA n.2: Con PORTFW nei kernels 2.2.x, le macchine interne NON POSSONO passare a PORTFWD lo stesso indirizzo IP per accedere ad una macchia interna, anche se la cosa funziona bene con macchine esterne (in internet). Se questo per te è un problema, è possibile implementare ANCHE la funzione REDIR di portfwd, in modo che le macchine interne vengano redirette verso il server interno. Una buona notizia è che il nuovo software Cosa serve in 2.0.x<@@ref>NetFilter{refnam} in preparazione risolverà questi problemi. Se desideri una spiegazione tecnica sul perchè l'indirizzamento interno/esterno non funziona, leggi alla fine di questo paragrafo.
Before jumping right into installing either the 2.0.x IPPORTFW or 2.2.x version of IPMASQADM with IPPORTFW support, network security can be an issue with any port forwarder. The reason for this is because these tools basically create a hole in the packet firewall for the forwarded TCP/UDP ports. Though this doesn't pose any threat to your Linux machine, it might be an issue to the internal machine that this traffic is being forwarded to. No worries though, this is what Steven Clarke (the author of IPPORTFW) had to say about that:
"L'indirizzamento di porta viene attivato solamente nelle funzioni di Mascheramento, per cui si inserisce nelle stesse regole per IPFWADM/IPCHAINS. Il Mascheramento è un'estensione dell'indirizzamento IP perciò ipportfw può vedere un pacchetto solo se soddisfa le regole di input e masqueramento ipfwadm."
Detto questo, è bene comunque avere delle regole di firewall forti. Vedi i paragrafi {refnam} e {refnam}.
Per installare il supporto di indirizzamento IPPORTFW, sia per ilkernel 2.0.x sia per 2.2.x, è necessario ricompilare il kernel con supporto IPPORTFW.
Prima di tutto, procurati la versione più recente del kernel 2.0.x, decompressa nella directory /usr/src/linux. Se non sei ancora in questa condizione, vedi come fare al paragrafo Compilazione del kernel.
Dopo di che, procurati il programma "ipportfw.c" e la patch per il kernel "subs-patch-x.gz" dal paragrafo {refnam} nella directory /usr/src/.
NOTA: In "subs-patch-x.gz" sostituisci 'x' con la versione più recente che riesci a reperire.
Copia quindi la patch IPPORTFW (subs-patch-x.gz) nella directory Linux. Ad es.:
cp /usr/src/subs-patch-1.37.gz /usr/src/linux
e poi applica la patch, per creare l'opzione IPPORTFW nel kernel:
cd /usr/src/linux zcat subs-patch-1.3x.gz | patch -p1
A questo punto, se prevedi di aver bisogno di indirizzamento di porta del traffico FTP verso un server interno, devi applicare una ULTERIORE patch per il modulo IP_MASQ_FTP, che si trova al paragrafo {refnam}. Per maggiori informazioni, vedi oltre.
Ok, è ora di compilare il kernel, come già descritto in {refnam} section. Fai attenzione a rispondere YES alla opzione IPPORTFW che adesso si presenta, durante la fase di configurazione. A compilazione completata, e dopo aver fatto il reboot, ritorna alla lettura di questo documento, a questo punto.
Con il nuovo kernel appena preparato, compila e installa l'effettivo programma "IPPORTFW"
cd /usr/src gcc ipportfw.c -o ipportfw mv ipportfw /usr/local/sbin
Nell'esempio che seguirà, permetteremo tutto il traffico internet in www (porta 80) che arriva al tuo indirizzo TCP/IP di essere indirizzato verso la macchina interna Mascherata, all'indirizzo IP 192.168.0.10.
NOTA: Una volta abilitato un indirizzatore di porta verso la porta 80, tale porta non potrà più essere usata dal server IP-Masq linux. Ciò significa che se hai un server WWW in funzione sul server IP-Masq e stabilisci un indirizzamento sulla porta 80, verso un pc Mascherato, TUTTI gli utenti da internet vedranno le pagine www del server INTERNO e non quelle del server IP-Masq.
Il solo modo per evitare questo consiste nello stabilire un indirizzamento ad un'altra porta, ad esempio 8080, verso il pc Mascherato. In tal caso, tutti gli utenti da internet che vorranno contattare il server www Mascherato, dovranno appendere :8080 alla URL.
Ad ogni modo, per abilitare l'indirizzamento a porta, si devono modificare le regole in /etc/rc.d/rc.firewall. Usa le righe che seguono, sostituendo la parola "$extip" con il tuo indirizzo IP.
NOTA: Se il tuo ISP ti fornisce un IP DINAMICO (attraverso PPP, ADSL, Cablemodems, etc.), devi rendere più intelligenti le istruzioni in /etc/rc.d/rc.firewall. Vedi TrinityOS - paragrafo 10 per quanto riguarda regole forti e indirizzi IP dinamici.
/etc/rc.d/rc.firewall -- # echo "Enabling IPPORTFW Redirection on the external LAN.." # /usr/local/sbin/ipportfw -C /usr/local/sbin/ipportfw -A -t$extip/80 -R 192.168.0.10/80 --
Questo è tutto! Fai ripartitire le istruzioni in /etc/rc.d/rc.firewall e provane il funzionamento!
Se ricevi un errore del tipo "ipfwadm: setsockopt failed: Protocol not available", non stai usando il nuovo kernel. Controlla di aver di averlo posizionato correttamente e di aver rilanciato LILO. Fai di nuovo il reboot.
Port Forwarding FTP servers:
Se vuoi un indirizzamento di porta per FTP verso un macchina interna, le cose sono un po' più complicate perchè il modulo standard IP_MASQ_FTP non era stato scritto a questo scopo. Per fortuna, Fred Viles ha scritto una versione opportunamente modificata del modulo IP_MASQ_FTP. Se ti interessa sapere quali sono ESATTAMENTE i problemi che bisognava risolvere, procurati l'archivio che diamo qui sotto, dove Fred ha documentato tutto in modo accurato. Fai comunque attenzione che questa è una patch ancora un po' sperimentale; al momento è disponibile SOLAMENTE per i kernels 2.0.x. Una parte del lavoro per portare la patch ai kernels 2.2.x è già stato avviato; se ti interessa aiutare a completare l'opera, comunica le tue intenzioni direttamente all'indirizzo Fred Viles - fv@episupport.com .
Allora, per mettere al lavoro la patch per 2.0.x devi fare::
Infine edita le regole /etc/rc.d/rc.firewall e aggiungi le seguenti righe, sostituendo "$extip" con il tuo indirizzo IP.
NOTA: Se il tuo ISP ti fornisce un IP DINAMICO (attraverso PPP, ADSL, Cablemodems, etc.), devi rendere più intelligenti le istruzioni in /etc/rc.d/rc.firewall. Vedi TrinityOS - paragrafo 10 per quanto riguarda regole forti e indirizzi IP dinamici.
L'esempio che segue permette che TUTTO il traffico FTP da internet (porta 21) che arriva al tuo indirizzo TCP/IP venga dirottato verso la macchina interna, Mascherata, di indirizzo 192.168.0.10.
NOTA: Una volta abilitato un indirizzatore di porta verso la porta 21, tale porta non potrà più essere usata dal server IP-Masq linux. Ciò significa che se hai un server FTP in funzione sul server IP-Masq e stabilisci un indirizzamento sulla porta 21, verso un pc Mascherato, TUTTI gli utenti da internet vedranno i files del server FTP INTERNO e non quelle del server FTP sulla workstation IP-Masq.
/etc/rc.d/rc.firewall -- #echo "Enabling IPPORTFW Redirection on the external LAN.." # /usr/local/sbin/ipportfw -C /usr/local/sbin/ipportfw -A -t$extip/21 -R 192.168.0.10/21 --
Questo è tutto! Fai ripartitire le istruzioni in /etc/rc.d/rc.firewall e provane il funzionamento!
Se ricevi un errore del tipo "ipchains: setsockopt failed: Protocol not available", non stai usando il nuovo kernel. Controlla di aver di averlo posizionato correttamente e di aver rilanciato LILO. Fai di nuovo il reboot. Se ssei sicuro di aver fatto il boot del nuovo kernel, lancia il comando "ls /proc/net" e verifica che esista il file "ip_portfw". In contrario, hai fatto un errore nella configurazione del kernel. Riprovaci.
Prima di tutto, procurati la versione più recente del kernel 2.2.x, decompressa nella directory /usr/src/linux. Se non sei ancora in questa condizione, vedi come fare al paragrafo Compilazione del kernel.
Dopo di che, procurati il programma "ipmasqadm.c" nella directory /usr/src (vedi il paragrafo {refnam}).
Poi compila il kernel, come spiegato in {refnam}. Fai attenzione a rispondere YES alla opzione IPPORTFW, nell aase di configurazione. Terminata la compilazione, fai il reboot e ritorna a leggere il presente manuale, a questo punto.
Adesso compila e installa la funzione IPMASQADM:
cd /usr/src tar xzvf ipmasqadm-x.tgz cd ipmasqadm-x make make install
Nell'esempio che seguirà, permetteremo tutto il traffico internet in www (porta 80) che arriva al tuo indirizzo TCP/IP di essere indirizzato verso la macchina interna Mascherata, all'indirizzo IP 192.168.0.10.
NOTA. Al momento si ritiene che il modulo IP_MASQ_FTP modificato per connessioni FTP a porta indirizzata NON funzioni per i kernels 2.2.x, ma alcuni utilizzatori hanno riportato che tale modulo non è più necessario e che il normale PORTFW del traffico FTP funziona egregiamente.. Se te la senti di fare qualche esperimento, prova a portare il modulo modificato nei kernels 2.2.x e informa Ambrose Ranch (dranch@trinnet.net) dei risultati che ottieni.
NOTA: Una volta abilitato un indirizzatore di porta verso la porta 80, tale porta non potrà più essere usata dal server IP-Masq linux. Ciò significa che se hai un server WWW in funzione sul server IP-Masq e stabilisci un indirizzamento sulla porta 80, verso un pc Mascherato, TUTTI gli utenti da internet vedranno le pagine www del server INTERNO e non quelle del server IP-Masq.
Ad ogni modo, per abilitare l'indirizzamento a porta, si devono modificare le regole in /etc/rc.d/rc.firewall. Usa le righe che seguono, sostituendo la parola "$extip" con il tuo indirizzo IP.
NOTA: Se il tuo ISP ti fornisce un IP DINAMICO (attraverso PPP, ADSL, Cablemodems, etc.), devi rendere più intelligenti le istruzioni in /etc/rc.d/rc.firewall. Vedi TrinityOS - paragrafo 10 per quanto riguarda regole forti e indirizzi IP dinamici.
Un suggerimento: /etc/ppp/ip-up per gli utenti PPP.
/etc/rc.d/rc.firewall -- #echo "Enabling IPPORTFW Redirection on the external LAN.." # /usr/sbin/ipmasqadm portfw -f /usr/sbin/ipmasqadm portfw -a -P tcp -L $extip 80 -R 192.168.0.10 80 --
Questo è tutto! Fai ripartitire le istruzioni in /etc/rc.d/rc.firewall e provane il funzionamento!
Se ricevi un errore del tipo "ipchains: setsockopt failed: Protocol not available", non stai usando il nuovo kernel. Controlla di aver di averlo posizionato correttamente e di aver rilanciato LILO. Fai di nuovo il reboot.
Se sei sicuro di usare il nuovo kernel, batti il comando "ls /proc/net/ip_masq" e verifica che esista il file "portfw". In caso contrario, devi aver fatto quache errore nella compilazione del kernel. Prova di nuovo.
Per chi vuole capire perchè PORTFW non è in grado di redirigere il traffico per le interface interne ed esterne, ecco qui una email da Juanjom, che spiega:
From Juanjo Ciarlante
--
> If I use:
>
> ipmasqadm portfw -a -P tcp -L 1.2.3.4 80 -R 192.168.2.3 80
>
> Everything works great from the outside but internal requests for the same
> 1.2.3.4 address fail. Are there chains that will allow a machine on localnet
> 192.168.2.0 to accesss www.periapt.com without using a proxy?
Actually not.
I usually setup a ipmasqadm rule for outside, *AND* a port redirector
for inside. This works because ipmasqadm hooks before redir will get
the eventual outside connection, _but_ leaves things ok if not (stated
by APPROPIATE rules).
The actual "conceptual" problem comes from the TRUE client
(peer) IP goal (thanks to masq) being in same net as target
server.
The failing scenario for "local masq" is :
client: 192.168.2.100
masq: 192.168.2.1
serv: 192.168.2.10
1)client->server packet
a) client: 192.168.2.100:1025 -> 192.168.2.1:80 [SYN]
b) (masq): 192.168.2.100:1025 -> 192.168.2.10:80 [SYN]
(and keep 192.168.2.1:61000 192.168.2.100:1025 related)
c) serv: gets masqed packet (1b)
2)server->client packet
a) serv: 192.168.2.10:80 -> 192.168.2.100:1025 [SYN,ACK]
b) client: 192.168.2.100:1025 -> 192.168.2.10:80 [RST]
Now take a moment to compare (1a) with (2a).
You see, the server replied DIRECTLY to client bypassing masq (not
letting masq to UNDO the packet hacking) because it is in SAME net, so
the client resets the connection.
hope I helped.
Warm regards
Juanjo
Il Mascheramento di IP in Linux supporta CuSeeme attraverso il modulo "ip_masq_cuseeme" del kernel. Tale modulo dovrebbe essere caricato nello script /etc/rc.d/rc.firewall script. Una volta che il modulo "ip_masq_cuseeme" è installato, dovresti essere in grado di avviare e ricevere le connessioni CuSeeme verso i riflettori e/o utenti remoti.
NOTA: Per usare CuSeeme è' consigliabile usare la funzione IPPORTFW anzichè la vecchia IPAUTOFW.
Se hai bisogno di informazioni più dettagliate per configurare CuSeeeme, vedi il Mini-HOWTO alla Pagina di CuSeeMe di Michael Owings o The IP Masquerade Resources per un mirror del Mini-HOWTO.
Ci sono due modi per far funzionare ICQ dietro ad un IP-Masq server Linux. Una soluzione è usare un recente modulo ICQ Masq, mentre l'altra è usare IPPORTFW.
Il modulo ICQ ha alcuni vantaggi, ma anche alcuni limiti. Permette una semplice sistemazione di molti utenti in ICQ dietro all'IP-Masq server. Inoltre non richiede nessun particolare cambiamento nei clients ICQ. Però, al momento, non funziona nè il trasferimento di files nè il chat in read-time.
Con IPPORTFW è necessario fare qualche cambiamento sia nella workstation Linux sia nei clients ICQ, poi funziona tutto: messaggi in ICQ, URLs, chat, trasferimento files, etc.
Se sei interessato al modulo ICQ IP masq per i kernels 2.2.x, di Andrew Deryabin djsf@usa.net, vedi il paragrafo {refnam} per ulteriori informazioni.
Se preferisci il metodo classico per far funzionare ICQ diatro un IP-Masq server, segui la seguente procedura:
Ho quiincluso due esempi per l'utente; entrambi funzionano bene:
-- /usr/local/sbin/ipportfw -A -t10.1.2.3/2000 -R 192.168.0.10/2000 /usr/local/sbin/ipportfw -A -t10.1.2.3/2001 -R 192.168.0.10/2001 /usr/local/sbin/ipportfw -A -t10.1.2.3/2002 -R 192.168.0.10/2002 /usr/local/sbin/ipportfw -A -t10.1.2.3/2003 -R 192.168.0.10/2003 /usr/local/sbin/ipportfw -A -t10.1.2.3/2004 -R 192.168.0.10/2004 /usr/local/sbin/ipportfw -A -t10.1.2.3/2005 -R 192.168.0.10/2005 /usr/local/sbin/ipportfw -A -t10.1.2.3/2006 -R 192.168.0.10/2006 /usr/local/sbin/ipportfw -A -t10.1.2.3/2007 -R 192.168.0.10/2007 /usr/local/sbin/ipportfw -A -t10.1.2.3/2008 -R 192.168.0.10/2008 /usr/local/sbin/ipportfw -A -t10.1.2.3/2009 -R 192.168.0.10/2009 /usr/local/sbin/ipportfw -A -t10.1.2.3/2010 -R 192.168.0.10/2010 /usr/local/sbin/ipportfw -A -t10.1.2.3/2011 -R 192.168.0.10/2011 /usr/local/sbin/ipportfw -A -t10.1.2.3/2012 -R 192.168.0.10/2012 /usr/local/sbin/ipportfw -A -t10.1.2.3/2013 -R 192.168.0.10/2013 /usr/local/sbin/ipportfw -A -t10.1.2.3/2014 -R 192.168.0.10/2014 /usr/local/sbin/ipportfw -A -t10.1.2.3/2015 -R 192.168.0.10/2015 /usr/local/sbin/ipportfw -A -t10.1.2.3/2016 -R 192.168.0.10/2016 /usr/local/sbin/ipportfw -A -t10.1.2.3/2017 -R 192.168.0.10/2017 /usr/local/sbin/ipportfw -A -t10.1.2.3/2018 -R 192.168.0.10/2018 /usr/local/sbin/ipportfw -A -t10.1.2.3/2019 -R 192.168.0.10/2019 /usr/local/sbin/ipportfw -A -t10.1.2.3/2020 -R 192.168.0.10/2020 -- <itemize> <item> <tt>Esempio n. 2 <verb> --port=2000 while [ $port -le 2020 ] do /usr/local/sbin/ipportfw -A t10.1.2.3/$port -R 192.168.0.10/$port port=$((port+1)) done
--
Ho quiincluso due esempi per l'utente; entrambi funzionano bene:
Esempio n. 1
--
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2000 -R 192.168.0.10 2000
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2001 -R 192.168.0.10 2001
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2002 -R 192.168.0.10 2002
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2003 -R 192.168.0.10 2003
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2004 -R 192.168.0.10 2004
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2005 -R 192.168.0.10 2005
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2006 -R 192.168.0.10 2006
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2007 -R 192.168.0.10 2007
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2008 -R 192.168.0.10 2008
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2009 -R 192.168.0.10 2009
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2010 -R 192.168.0.10 2010
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2011 -R 192.168.0.10 2011
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2012 -R 192.168.0.10 2012
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2013 -R 192.168.0.10 2013
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2014 -R 192.168.0.10 2014
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2015 -R 192.168.0.10 2015
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2016 -R 192.168.0.10 2016
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2017 -R 192.168.0.10 2017
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2018 -R 192.168.0.10 2018
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2019 -R 192.168.0.10 2019
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2020 -R 192.168.0.10 2020
--
Esempio n. 2
--
port=2000
while [ $port -le 2020 ]
do
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 $port -R 192.168.0.10 $port
port=$((port+1))
done
--
Adesso ICQ ti informerà che devi farlo ripartire, affinchè le modifiche fatte vengano effettivamente applicate. In verità io ho dovuto fare il REBOOT della macchina Windows9x, per far funzionare il tutto, ma altri dicono che non è necessario. Quindi.. prova entrambi i modi.
La patch per LooseUDP permette ai giochi compatibili con NAT, che usano le connessioni UDP sia di FUNZIONARE sia di comportarsi molto bene dietro un server IP-Masq. Al momento LooseUDP è disponibile come patch per i kernels 2.0.36+, mentre è già incorporata nei kernels 2.2.3+, ma è DISABILITATA per DEFAULT in 2.2.16+.
Nel caso di un file compresso: zcat loose-udp-2.0.36.patch.gz | patch -p1
Nel caso di un file NON compresso: cat loose-udp-2.0.36.patch | patch -p1
A seconda della versione della patch", comparirà uno dei seguenti testi:
patching file `CREDITS' patching file `Documentation/Configure.help' patching file `include/net/ip_masq.h' patching file `net/ipv4/Config.in' patching file `net/ipv4/ip_masq.c'
Dopo aver applicato la patch, riconfigura il kernel, come descritto al paragrafo {refnam} e fai attenzione a rispondere "Y" alla opzione "IP: loose UDP port managing (EXPERIMENTAL) (CONFIG_IP_MASQ_LOOSE_UDP) [Y/n/?]".
echo "0" > /proc/sys/net/ipv4/ip_masq_udp_dloose to a "1"
ed quindi esegui le regole in rc.firewall. Un esempio si trova in Firewall in 2.2.x e in Firewall Forte in 2.2.x.
Adesso che hai un kernel in funzione con LooseUDP abilitato, puoi usare la maggior parte dei giochi che usano NAT. Sono state fornite alcune URLs di particolari patches che srervono a basare su NAT giochi come BattleZone e altri. Per informazioni vedi il paragrafo {refnam}.