Chi mi indica un tutorial a prova di stupido che spiega come funziona iptables quando c'è di mezzo un bridge?
Ho trovato questo, lo sto digerendo ma con una certa fatica :p e soprattutto non ho ancora capito se è sufficiente (però gli schemini colorati sono carini):
http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html#section6La domanda nasce, casomai non fosse ovvio, dalla necessità di firewallare opportunamente un server Proxmox VE e una delle VM che ospita, senza che il firewall del server interferisca con le necessità della VM: il server PVE ha un IP pubblico che in pratica ha aperto solo ssh (e non sulla porta standard) e fa da reverse proxy HTTP per alcuni server virtuali, mentre una delle VM ha a sua volta un IP pubblico.
Inizialmente iptables sul server fisico era impostato con: -A INPUT -i vmbr2 -p tcp --dport http -j ACCEPT -A INPUT -i vmbr2 -p tcp --dport 2222 -j ACCEPT -A INPUT -i vmbr2 -m state --state INVALID,NEW -j DROP -A FORWARD -i vmbr2 -m state --state INVALID,NEW -j DROP...ma questo uccideva anche i pacchetti destinati al server virtuale che invece nel suo iptables aveva aperto varie porte (ad es. http e smtp). Non ho capito *bene* perché, ma con i disegnini colorati di cui sopra ci sto arrivando, spero.
Le soluzioni che mi sono venute in mente sono:1. non dare un IP alla porta vmbrX sul server fisico e lasciar passare tutto: non sono convinto che ciò basti a proteggere il server da qualsiasi porcheria che potrebbe arrivare su quella porta, anzi, sono proprio sicuro che non sia sufficiente; 2. non dare un IP pubblico alla VM: metterlo come alias su vmbrX e ridirigere il necessario con DNAT, ma temo che mi complicherei la vita più del necessario (soprattutto se dovessi migrare la VM sull'altro server in cluster e quindi portarmi dietro tutte le regole...);
3. aprire tutto all'IP del server virtuale sull'iptables del server fisico: -A INPUT -i vmbr2 -d IP.DEL.SERVER.VIRTUALE -j ACCEPT...ma non mi piace troppo, ad es. di nuovo per la necessità di portarmi dietro la regola se sposto la VM su un altro server fisico.
Non so, ma ho la sensazione che ci sia una soluzione più furba alla quale non ho pensato.
Aiuto... -- Ciao, Flavio Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer -- Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO "subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxx