Esperienza su proxy ARP
Esperienza su proxy ARP |
|
|
|
Questo argomento è stato affrontato nella realtà quando
ho dovuto costrure una piccola rete all'interno dell'Istituto scolastico.
Il mio intento era quello di non
appesantire il lavoro dei colleghi che la gestivano
forzando una riconfigurazione della stessa.
Ho proceduto come segue:
per prima cosa ho chiesto e ottenuto un insieme di indirizzi IP privati
della rete d'istituto (classe C 192.168.0.X) che mi permettessero di
configurare una subnet. Il numero minimo
per lo schema che avevo in mente era 8. Mi sono stati assegnati
gli indirizzi a partire dal 192.168.0.216 fino al 192.168.0.223.
La soluzione è affiorata pensando di utilizzare
una tecnica chiamata "proxy ARP" (RFC 1027).
La tecnica è quella di far apparire una macchina posizionata su una rete come appartenente ad una differente rete connessa allo stesso router. Tipicamente questo viene utilizzato per nascondere all'interno di una rete privata un nodo con IP publico. Il router dirotterà il traffico da e per la macchina nascosta.
Analizzeremo una rete
(pdf,
xml)
composta appunto da un router fw connesso alla
rete d'istituto e al router d'istituto schoolRouter
e connesso ad una rete privata dove ci sono due host: left
con indirizzo appartenente alla rete d'istituto e right
con indirizzo nella rete privata.
Quando un host all'interno dell'istituto
intende comunicare con left riconosce
l'IP come appartente alla stessa rete e quindi l'host genera un pacchetto
ARP per conoscerne il MAC.
Il router risponderà con il MAC della sua
scheda nella rete d'istituto e sarà pronto a ricevere il pacchetto.
Successivamente per trovare il MAC dell'host di destinazione il router
manderà un ARP nella rete sperimentale e dopo aver ricevuto la risposta
manderà il pacchetto all'host destinazione.
Per provare la configurazione appena descritta
useremo
Netkit4TIC.
Scarica il file
tarball,
scompattalo in una sottodirectory della
HOME dell'utente, entra nella directory
Proxy-ARP e lancia il comando lstart
(screenshot).
Il file di configurazione più caratterizzante è
/etc/shorewall/proxyarp:
# /etc/shorewall/proxyarp #ADDRESS INTERFACE EXTERNAL HAVEROUTE PERSISTENT 192.168.0.217 eth1 eth0 no yes
Il file di configurazione /etc/shorewall/interfaces:
# /etc/shorewall/interfaces #ZONE INTERFACE BROADCAST OPTIONS net eth0 detect loc eth1 detect
Mentre la policy rimane "standard":
# /etc/shorewall/policy #SOURCE DEST POLICY LOG LEVEL loc net ACCEPT net all DROP info all all REJECT info
e le eccezioni riguardano i servizi presenti sul nodo iterno 192.168.0.217:
# /etc/shorewall/rules #ACTION SOURCE DEST PROTO DEST [...] # Accept http, ssh, smtp, domain, snmp from net to 192.168.0.217 # Web/ACCEPT net loc:192.168.0.217 SSH/ACCEPT net loc:192.168.0.217 SMTP/ACCEPT net loc:192.168.0.217 DNS/ACCEPT net loc:192.168.0.217 SNMP/ACCEPT net loc:192.168.0.217
Per maggiore chiarezza abbiamo settato i MAC address come segue:
eth0@schoolRouter 00:00:00:AA:AA:AA eth0@fw 00:00:00:00:00:FA eth1@fw 00:00:00:00:00:FB eth0@left 00:00:00:BB:BB:BB
Sperimentazione interattiva |
|
Proviamo a scatenare il proxy arp. Attiviamo allo scopo il server
apache sul nodo "interno" left, proviamo ad accedervi
dal nodo "esterno" schoolRouter e poi chiediamo la visualizzazione
della ARP cache in due intervalli leggermente distanziati:
schoolRouter# lynx -dump http://192.168.0.217 | strings; \
echo -e ''; arp -n; sleep 5; echo -e '\n'; arp -n
Benvenuto 192.168.0.254 su 192.168.0.217
Address HWtype HWaddress Flags Mask Iface
192.168.0.217 ether 00:00:00:00:00:FA C eth0
Address HWtype HWaddress Flags Mask Iface
192.168.0.217 ether 00:00:00:00:00:FA C eth0
192.168.0.216 ether 00:00:00:00:00:FA C eth0
Il MAC address associato a 192.168.0.217 è dovuto alla richiesta
iniziale di comunicazione del nodo schoolRouter
verso il nodo left.
Il MAC address associato a 192.168.0.217 è invece dovuto
alla scadenza del timeout sul nodo schoolRouter
(eth0@schoolRouter).
L'ARP cache nel nodo fw è la seguente:
fw# arp -n
Address HWtype HWaddress Flags Mask Iface
192.168.0.254 ether 00:00:00:AA:AA:AA C eth0
192.168.0.217 ether 00:00:00:BB:BB:BB C eth1
192.168.0.217 * * MP eth0
Il nodo right è ovviamente raggiungibile:
schoolRouter# ping -c 1 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=63 time=5.50 ms
--- 192.168.1.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 5.504/5.504/5.504/0.000 ms
Abbiamo appena verificato il funzionamento del proxy ARP per
il nodo left: è
inserito fisicamente nel dominio di collisione B ma
configurato come se fosse nel dominio di collisione A.
Come controprova ora disabiliteremo il proxy ARP, spostiamo
left nel dominio di collisione A e vediamo
le variazioni di funzionamento in rete.
/etc/shorewall/proxyarp
del nodo fw;fw# /etc/init.d/shorewall restart
schoolRouter# arp -d 192.168.0.217
left sul dominio di
collisione A:
realHost$ lcrash left; \
patch lab.conf < patch; \
lstart left
Osserviamo che la sua raggiungibilità a livello 3 non cambia ma a livello 2:
schoolRouter# lynx -dump http://192.168.0.217 | strings; \
echo -e ''; arp -n; sleep 5; echo -e '\n'; arp -n
Benvenuto 192.168.0.254 su 192.168.0.217
Address HWtype HWaddress Flags Mask Iface
192.168.0.217 ether 00:00:00:BB:BB:BB C eth0
Address HWtype HWaddress Flags Mask Iface
192.168.0.217 ether 00:00:00:BB:BB:BB C eth0
|
|
Sandro Doro (email me)