Ci sono un po' di problemi e un po' di cose che possono andare male usando un documento semplice come questo, perché ci sono diversi casi particolari. La maggior parte di essi riguardano la configurazione degli apparati della rete interna e di quella esterna. Cercherò di rispondere alle persone che hanno dei problemi: segnalatemi cosa è andato male e aggiungerò dei link in questo documento, così le persone che hanno problemi riguardanti casi particolari possono avere una traccia per un aiuto. Contattatemi pure all'indirizzo pramsey@refractions.net.
Alcune parti di ICQ funzionano bene con il masquerading. Altre
parti non funzionano affatto. C'è un
modulo ICQ beta, anche se in fase di sviluppo,
che risolve alcuni dei problemi (ma non tutti) nel far girare ICQ
con il masquerading. Il file README nel codice sorgente della distribuzione
descrive come compilare il modulo. Una volta compilato
ed installato, si digiti /sbin/modprobe ip_masq_icq.
Bene, per prima cosa congratulazioni per la controtendenza! Seconda cosa, Nelson Gibbs (ngibbs@pacbell.net) invia buone notizie, perché molte di queste istruzioni saranno valide per Caldera. Ci sono alcuni cambiamenti importanti da tenere in conto, comunque:
GATEWAY=xxx.xxx.xxx.xxx nei file /etc/sysconfig/network-scripts/ifcfg-eth0
ed eth1 per l'interfaccia (l'interfaccia locale usa un indirizzo
IP remoto e l'interfaccia remota usa l'IP del gateway del provider).
/etc/sysconfig/daemons/dhcpd segnali
ROUTE_DEVICE come eth1 e non eth0. /etc/dhcpd.conf richiede una dichiarazione di sottorete per entrambe
le interfacce (non sono completamente sicuro perché ho fatto la seconda
dichiarazione: subnet 216.102.154.201 netmask 255.255.255.255 {
} senza nessun'altra opzione ed il server DHCP ascolta e spedisce
sulla eth0 e la eth1). Il server DHCP dà errore se è
specificata una sola sottorete. 255.255.255.255, lo script /etc/rc.d/init.d/dhcpd
che usa Caldera ha già risolto il problema. Assicurarsi di cambiare
a eth1 tutti i riferimenti all'eth0 contenuti nello script.
Una cosa da nulla! Comunque, si ha bisogno di un indirizzo IP statico affinché questa semplice serie di istruzioni funzioni. Nel caso di indirizzo IP dinamico, si avrà bisogno di qualche script in più per assicurarci che l'indirizzo IP sia aggiornato nei comandi di port forwarding quando l'indirizzo cambia.
Si ricordi che fare il forwarding di una porta esterna su una
macchina interna rende la macchina "interna" meno "interna"
di prima, ma può essere fatto in maniera trasparente e con
una degradazione delle prestazioni praticamente nulla. Uno degli effetti collaterali
del codice dell'IP masquerading nel kernel di Linux è l'abilità di
fare alcuni giochetti divertenti con i pacchetti quando questi raggiungono
lo strato network, e ipmasqadm ne trae
vantaggio.
Per alcune ragioni ipmasqadm non è fornito con tutte le varianti
di Red Hat e di Mandrake, quindi si dovrà probabilmente scaricarlo dal
sito web del manutentore -- esiste un
RPM ed anche il codice sorgente.
Una volta ottenuto l'RPM, lo si installi e si aggiungano le seguenti
righe al file /etc/rc.d/rc.local:
/usr/sbin/ipmasqadm portfw -f /usr/sbin/ipmasqadm portfw -a -P tcp -L x.x.x.x 80 -R 192.168.1.x 80
Il primo comando svuota le regole del port forwarding ed il secondo comando aggiunge il forward dalla porta 80 dell'interfaccia esterna alla porta 80 della macchina interna che fa da web server. Si noti che l'indirizzo IP statico esterno va al posto di x.x.x.x e l'indirizzo IP dell'interfaccia della macchina interna va al posto di 192.168.1.x.
Adesso le richieste esterne per la porta 80 saranno redirette in modo trasparente alla porta 80 della macchina interna. Non si può testare questo meccanismo effettuando un telnet o connettendosi alla porta 80 del gateway da una delle macchine interne: il port forwarder serve solo le richieste che arrivano sull'interfaccia esterna.