Tre server con lo stesso IP nella stessa LAN: raggiungerli tutti con MikroTik

Qual è il problema?

Tre server, tre NVR, tre centraline: escono tutti dalla fabbrica con lo stesso indirizzo, per esempio 192.168.1.1. Per qualche motivo non puoi cambiarlo: il software del costruttore lo vuole così, l’installatore non c’è più, o semplicemente non è roba tua. Però devi raggiungerli tutti e tre, dallo stesso PC, nella stessa LAN.

Collegati a uno switch qualunque è il caos: alla domanda “chi è 192.168.1.1?” rispondono in tre, e il PC parla un po’ con uno e un po’ con l’altro. Con un MikroTik al posto dello switch li vedi invece come 192.168.1.11, .12 e .13, senza toccare né i server né il PC, e senza uscire dalla LAN.

Negli esempi il PC è 192.168.1.100 su ether1, i tre server sono su ether2, ether3 ed ether4. Va bene uno switch CRS o un router con più porte.

Come funziona il trucco?

Due attrezzi, uno per livello:

• il bridge NAT risponde all’ARP al posto dei server: quando il PC chiede “chi è .12?”, gli risponde “il server 2”, con il MAC vero del server 2. Da quel momento il PC manda i pacchetti per .12 direttamente al server 2;
• il NAT IP cambia la destinazione da .12 a .1 mentre il pacchetto attraversa il bridge, così il server lo riconosce come suo. Al ritorno il router rimette a posto l’indirizzo, e il PC vede rispondere .12.

Il bridge NAT da solo non basta: cambia gli indirizzi MAC, mai quelli IP, e il server scarterebbe un pacchetto per .12. Il NAT IP da solo nemmeno: senza qualcuno che risponda all’ARP, il PC non saprebbe a chi mandare i pacchetti. Insieme fanno il lavoro.

Passo 1: quali sono i MAC dei server?

Ti serve il MAC di ciascun server: di solito è sull’etichetta. Altrimenti collegali al MikroTik e guarda su quale porta compare ogni MAC:

/interface bridge host print where !local

Negli esempi: server 1 AA:AA:AA:00:00:01, server 2 AA:AA:AA:00:00:02, server 3 AA:AA:AA:00:00:03. Metti i tuoi.

Passo 2: come collego le porte?

Tutte e quattro le porte nello stesso bridge, ma con i server separati fra loro:

/interface bridge add name=bridge-lan
/interface bridge port
add bridge=bridge-lan interface=ether1 hw=no
add bridge=bridge-lan interface=ether2 horizon=1 hw=no
add bridge=bridge-lan interface=ether3 horizon=1 hw=no
add bridge=bridge-lan interface=ether4 horizon=1 hw=no

• horizon=1: le porte con lo stesso horizon non si parlano. I tre server non si vedono fra loro, quindi non litigano per l’indirizzo, ma vedono tutti il PC;
• hw=no: su uno switch CRS, il traffico che il chip dello switch inoltra da solo non arriva mai alla CPU, e quindi né il bridge NAT né il firewall lo vedono. Con hw=no passa dalla CPU. Su un router senza chip switch il parametro non cambia niente.

L’ho verificato su uno switch CRS vero, con chip Prestera, con una telecamera al posto di un server: con hw=no la telecamera risponde all’indirizzo nuovo, ping e pagina web; con hw=yes l’ARP funziona ancora, ma i pacchetti li consegna il chip senza passare dal NAT, e non risponde niente.

E la port isolation dello switch (/interface ethernet switch port-isolation), al posto di horizon? Sullo switch del laboratorio funziona solo per il traffico che inoltra il chip: con hw=no viene ignorata, e la porta “isolata” torna a parlare con tutti. Qui il lavoro lo fa la CPU, quindi serve horizon, che vale per il bridge della CPU.

⚠️ Attenzione: se sei collegato al MikroTik da una di queste porte, perdi per un attimo la connessione. Lavora da un’altra porta, o da WinBox via MAC.

Passo 3: come rispondo all’ARP al posto dei server?

Una regola di bridge NAT per ogni server. È un proxy ARP su misura: risponde solo per quell’indirizzo, e con il MAC che decidi tu.

/interface bridge nat
add chain=dstnat mac-protocol=arp arp-opcode=request arp-dst-address=192.168.1.11/32 \
    action=arp-reply to-arp-reply-mac-address=AA:AA:AA:00:00:01 comment="server 1"
add chain=dstnat mac-protocol=arp arp-opcode=request arp-dst-address=192.168.1.12/32 \
    action=arp-reply to-arp-reply-mac-address=AA:AA:AA:00:00:02 comment="server 2"
add chain=dstnat mac-protocol=arp arp-opcode=request arp-dst-address=192.168.1.13/32 \
    action=arp-reply to-arp-reply-mac-address=AA:AA:AA:00:00:03 comment="server 3"

Perché non il proxy ARP classico dell’interfaccia (arp=proxy-arp)? Perché risponderebbe con il MAC del MikroTik, e il MikroTik dovrebbe poi instradare i pacchetti: è l’altra strada, quella della fine dell’articolo. Qui invece il PC parla direttamente con i server, e il MikroTik resta uno switch. L’azione arp-reply è descritta nel manuale MikroTik: Bridging and Switching.

Controlla gli indirizzi .11, .12 e .13: devono essere liberi nella rete del PC. Te lo dice l’IP calculator del Dojo se sono nella stessa subnet.

Passo 4: come cambio l’indirizzo IP dentro il bridge?

Di serie il traffico in bridge non passa dal firewall IP: il bridge lo inoltra e basta. Glielo facciamo attraversare, e poi aggiungiamo una sola regola di NAT per tutti e tre:

/interface bridge settings set use-ip-firewall=yes
/ip firewall nat add chain=dstnat dst-address=192.168.1.11-192.168.1.13 \
    action=dst-nat to-addresses=192.168.1.1 comment="tre server"

Una regola basta perché la scelta del server l’ha già fatta l’ARP: il pacchetto per .12 è già indirizzato al MAC del server 2, il NAT deve solo correggere l’IP. Senza use-ip-firewall non funziona: in laboratorio, spegnendolo, il ping è caduto a zero e i contatori sui server sono rimasti fermi.

Passo 5: come verifico che ogni indirizzo porti al server giusto?

Dal PC:

ping 192.168.1.11
ping 192.168.1.12
ping 192.168.1.13
arp -a

arp -a deve mostrare .11, .12 e .13 con i MAC dei tre server, uno diverso per indirizzo. Ma che rispondano non basta: apri la pagina web di ognuno e controlla che siano tre apparati diversi. In laboratorio ho mandato 3, 4 e 5 ping ai tre indirizzi, e su ciascun server ne sono arrivati esattamente 3, 4 e 5. Lo stesso con le pagine web: 1, 2 e 3 connessioni, ognuna al suo server.

Sul MikroTik i contatori dicono chi ha lavorato:

/interface bridge nat print stats
/ip firewall nat print stats

Una curiosità che vedrai: nella tabella ARP del PC compare anche 192.168.1.1, con il MAC di uno dei server. È normale: i server, per rispondere, chiedono “chi è .100?”, e il PC si segna chi glielo ha chiesto. Non dà fastidio, finché non provi a usare .1 direttamente.

E se non voglio legarmi ai MAC?

Se un server si guasta e lo sostituisci, cambia il MAC e va aggiornata la sua regola del passo 3. Se preferisci una soluzione che non dipende dai MAC, c’è la strada routed: ogni server su una porta fuori dal bridge, il MikroTik che prende .11, .12 e .13 sul lato del PC e una tabella di routing per server, scelta dal mangle.

/ip address add address=192.168.1.11/24 interface=bridge-lan
/ip address add address=192.168.1.250/32 network=192.168.1.1 interface=ether2
/routing table add name=srv1 fib
/ip route add dst-address=192.168.1.1/32 gateway=ether2 routing-table=srv1
/ip firewall mangle add chain=prerouting dst-address=192.168.1.11 action=mark-routing new-routing-mark=srv1
/ip firewall nat add chain=dstnat dst-address=192.168.1.11 action=dst-nat to-addresses=192.168.1.1
/ip firewall nat add chain=srcnat out-interface=ether2 action=masquerade

Qui sopra c’è il server 1; per gli altri si ripete con .12/ether3/srv2 e .13/ether4/srv3, togliendo prima le tre porte dal bridge. L’ho provata anch’essa in laboratorio, con lo stesso risultato. La differenza: i server vedono arrivare tutto dal MikroTik (192.168.1.250) invece che dal PC, e i tre 192.168.1.1 non sono più nella stessa LAN del PC. Tabelle e mark-routing sono spiegati nel manuale MikroTik: Policy Routing. E attenzione: senza mangle sembra funzionare, perché tutti e tre gli indirizzi rispondono, ma in laboratorio tutti i ping finivano sullo stesso server.

Cosa controllo prima di metterlo in produzione?

• il NAT non si fa nel chip: le regole dello switch (/interface ethernet switch rule) possono dirottare il traffico verso la CPU o cambiargli porta e VLAN, ma non riscrivono né MAC né IP. Il NAT in hardware esiste solo su alcuni switch Prestera più grandi, e solo per il traffico instradato con fasttrack; gli switch CRS3xx, come quello del mio laboratorio, non lo hanno. Ho provato anche a lasciare le porte in hardware e a mandare alla CPU solo il traffico dei server con una regola dello switch: non funziona;
• passa tutto dalla CPU: use-ip-firewall fa passare dal firewall tutto il traffico del bridge, e hw=no toglie il lavoro al chip dello switch. Per la gestione, le pagine web e le telecamere va benissimo; per spostare gigabyte di backup no. Tieni nel bridge solo le porte che servono;
• appena puoi, la soluzione vera resta cambiare gli indirizzi dei server. Questa è una cura, non il progetto;
• il MikroTik in mezzo è il punto da proteggere: se non l’hai ancora fatto, segui l’Hardening di base di un router MikroTik.

Provato in laboratorio su PNETLab con CHR RouterOS 7.24.5 (stable): un client Debian 12 come PC e tre CHR con lo stesso indirizzo come server, collegati su tre VLAN separate al posto delle tre porte. Con il bridge NAT: ping e HTTP verso i tre indirizzi, ognuno arrivato al server giusto (verificato con i contatori sui server), e la prova senza use-ip-firewall, che non funziona. Con il routing: stesso risultato, e la prova senza mangle, con tutto il traffico finito sul primo server. Su uno switch CRS con chip Prestera e RouterOS 7.24.5 e una telecamera come server: trucco del bridge NAT funzionante con hw=no e non con hw=yes, port isolation efficace solo con hw=yes, regole dello switch con redirect-to-cpu non sufficienti.