@FrancYescO così facendo però ti tocca impostare l'accesso lato wan alle varie interfacce web ed ssh per gestirli ed è rognoso. Secondo me gli conviene fare così, che è una cosa simile a quella che ho ancora dove avevo l'ftth tiscali tra il 789 e il mio openwrt, solo elevato a qualche potenza in più.
Schema esplicativo del risultato:
https://imgur.com/a/CFgxQIHSui device in cascata:
- impostare ip lan a 192.168.1.X (dove X è diverso per ogni device in cascata)
- mettere la porta eth4 nel bridge insiema alle altre eth0-3
- configurare il device waneth4 su vlan 42 (dove 42 è un bellissimo numero scelto a caso)
- configurare l'interfaccia wan per usare il device waneth4 in modalità ip static su una subnet differente da quella lan, diciamo 192.168.42.X (dove 42 è un bellissimo numero scelto casualmente uguale al precedente ed X è lo stesso di sopra) e gateway 192.168.42.1 mediante route statica creata manualmente e non tramite option gateway
- o in alternativa configurare analogamente un server dhcp sul device a monte su vlan 42 su subnet 192.168.42.0, e impostate qui l'interfaccia wan in modalità dhcp
- disattivare server dhcp su lan
- se da questo device la cascata deve continuare, creare una nuova interfaccia:
- nome: cascatona
- protocollo: bridge
- tipo: bridge
- interfaccia fisica: lista di interfacce contenente waneth4 e tutte le altre cascataethN create anche su questo device come spiegato qui sotto per il device a monte, dove le N sono tutte le porte da cui la cascata deve continuare (occhio che il bridge va creato sempre secondo modello DSA e fatto tramite LuCI potrebbe non funzionare o creare casini)
Sul device a monte:
- lasciare ip lan su default: 192.168.1.1
- server dhcp attivo come di default per lan su subnet 192.168.1.0
- creare un nuovo device su vlan 42 prendendo spunto dalla waneth4 presente nelle config di default e cambiando:
- nome: cascataethN dove N è la porta eth da cui parte la cascatona (ripetere per ogni N tra 0 e 3 da cui si intende farne partire una, nel caso stiate mettendo in piedi un WISP abusivo nel vostro isolato)
- vid: 42
- creare una nuova interfaccia:
- nome: cascatona
- protocollo: ip statica
- tipo: nessuno o bridge tra le porte ethernet da cui si intende far partire le dorsali per il WISP abusivo
- interfaccia fisica: cascataethN o lista di interfacce facenti parte del bridge (occhio che il bridge va creato sempre secondo modello DSA e fatto tramite LuCI potrebbe non funzionare o creare casini)
- zona firewall: lan
- ip: 192.168.42.1
- netmask 255.255.255.0
- gateway: nessuno
- server dhcp: disabilitato per questa interfaccia, o abilitato e correttamente configurato per l'alternativa detta sopra, nel caso la cascatona vada per le lunghe
Potrebbe mancare qualcosina, a memoria potrei essermi saltato qualche passaggio, se ve ne accorgete ditemelo che la aggiungo, ma il concetto di fondo dovrebbe essere chiaro. Quello di cui si è parlato nei post successivi l'ho già integrato.
Io uso una cosa del genere per far fare al Netgear sia una connessione pppoe tramite ont connesso al 789 e sia una banale connessione lan-lan tra i due - che mi viene comodo per uscire in internet dalla pppoe del 789 quando da remoto mi connetto in ipsec al Netgear - ma in fin dei conti è piuttosto semplice se uno ci prova. Ovviamente alla fine tutti i normali device (pc cellulari e amenità varie) collegati alle porte ethernet e wifi della cascata prendono ip in 192.168.1.0 e hanno come gateway 192.168.1.1 e pingano 192.168.42.1 tramite livello 3, quelli che si affacciano su vlan 42 possono eventualmente arrivare all'interfaccia 192.168.42.1 a livello 2 ed usarla come gateway e navigare, quindi il led diventa spontaneamente verde e possono andare in rete a scaricare pacchetti, fungere da ata voip e quant'altro. Se qualcuno ci prova e arriviamo ad avere dei file /etc/config/network e dintorni decenti li metto qui in questo post come esempio pratico, soprattutto per i due passaggi di creazione delle interfacce che causa specifica DSA non viene comodo fare via LuCI.
Update 8/5: Qui c'è un esempio completo dei file /etc/config/network di questo setup nella sua incarnazione minima, un 4132 a monte, un 789 unico membro terminale della cascata
https://www.ilpuntotecnico.com/forum/index.php/topic,80755.msg250608.html#msg250608Approfondimento 3/5: A distanza di tempo, voglio chiarirvi un aspetto importante.- Tutto questo funziona senza scomodare il tagging in hardware dello switch integrato da quattro porte, viene invece fatto dal SoC principale e questo ha i suoi pro e contro. Tra questi ultimi, c'è che il traffico passante attraverso un device intermedio o terminale della cascata e proveniente da o diretto a monte viene gestito via SoC da un bridge software tra due interfacce che by design sono fatte per comunicare tra loro su un path accelerato e ottimizzato che prevede i soliti router nat e firewall. Per ovviare a questo potenziale limite, si può fare in modo da delegare il ruolo di eth4 ad una delle altre quattro porte facenti parte dello switch, per il quale va abilitata la gestione vlan, in modo che il traffico non taggato sulle quattro porte venga reso al SoC principale su un vid qualsiasi (ad esempio nei firmware UNO per tg789 così come su openwrt si usai il vid '1') mentre il traffico taggato vid '42' viene reso al SoC su questo stesso vid. Quindi con riferimenti alle istruzioni precedenti, a proposito del/i device in cascata, non avrete più bisogno di spostare eth4 nel bridge lan (cosa che potrete comunque fare per recuperare una porta lan extra considerando però gli stessi limiti detti prima), e dovrete invece usare ethY, dove Y può essere da 0 a 3 e diverso da 4, al posto di eth4 ovunque lo vedete nominato nelle mie istruzioni (quindi "wan va su wanethY su ethY", e così via). Così facendo, i bridge 'cascatona' e le varie cascataethN configurate sui device intermedi, smettono di gestire il traffico in transito su vlan 42, dato che questa funzione verrebbe svolta internamente allo switch.
