[vega]

Salve,

OVH mi ha risposto ma non mi ha dato nessun parere né positivo né negativo sulla configurazione: sostanzialmente han "non abbiamo modo di confermare la vostra configurazione come VALIDA".

BTW: una cosa che centra poco. Sulla eth0 di uno dei miei server intercetto traffico taggato con vlan8. Sono per lo più brodcast ARP di request e pacchetti "hello" HSRP, quindi parliamo di Cisco (del resto è confermato dal mac address). Le richieste fanno riferimento ad ip di classe privata del tipo 10.Y.Z.K
Sul secondo server invece nessun traffico taggato.
Avevo chiesto info al supporto OVH ma non mi hanno saputo dare una spiegazione, anzi mi han chiesto di poter verificare (beh, è un semplice tcpdump -i eth0 vlan). Ero curioso di sapere se succede anche a qualche altro (sul mio secondo server ad esempio non succede).

Da quì sorge una curiosità: l'infrastruttura è gestita da persone diverse rispetto quelle che rispondono ai ticket o si occupano dei server ?
La richiesta di verificare quando avevo indicato sebbene sia legttima mi è parsa strana: sarebbe bastato controllare la configurazione
della porta dello switch in cui è collegato il mio server o comunque immagino che ovh sappia ce ci sono dei cisco con hsrp nello stesso
mio switch. con quegli ip. Specifico che non c'è alcuna vena polemica ma l.a mia è pura curiosità magari certe domande vanno poste ad altre figure o comunque conoscendo meglio come funziona l'infrastruttura uno può far sì di sfruttarla a pieno senza però causare problemi.

[vega]

Salve,

Vorrei condividere con voi una configurazione inusuale che ho fatto sulle mie macchine dedicate su OVH (classe enterprise del 2016 classe ed vecchio SP 2012 con supporto VIP) che fanno parte di offerte per cui non è attiva la VRACK.

In realtà ho anche aperto un ticket al supporto per chiedere conferma che la configurazione non dia problemi. Sono in attesa di risposta, nel caso vi aggiornerò. Ho deciso di condividere con voi la configurazione per sapere cosa ne pensate ed anche perché rispetto al quesito inviato al supporto su OVH ci sono delle cose che non ho testato e volevo prima un vostro parere.

Praticamente sui sever virtuali ospito macchine virtuali con XEN (sotto una distribuzione linux standard), ed uso OpenSWitch al posto del classico bridge.

Vi descrivo la configurazione (funzionante) e di cui ho chiesto la validazione al supporto OVH.

Server di partenza:

interfaccia eth0 con IP A.A.A.1. Gateway OVH A.A.A.254
ho anche un ip failover F.F.F.F ed una classe RIPE R.R.R.0/29

lì'ip failover FFFF ha un mac virtuale associato: mm-mm-mm-mm-mm-00

Gli IP della classe RIPE non hanno mac virtuali associati a parte
R.R.R.0 che ha associato mm-mm-mm-mm-mm-01
ed
R.R.R.7 che ha associato mm-mm-mm-mm-mm-02

Ovviamente i virtual mac li ha generati OVH.

Ho proceduto in questo modo

1. Ho creato un fakebrdige OVS0 con OpenVSwitch
2. ho cambiato il MAC address della eth0 inserendo mm-mm-mm-mm-mm-01
3. ho aggiunto la eth0 al fakebrdige OVS0 con tag 802.1Q 1 (praticamente è una porta access. Quello che entra viene taggato 1 ed esce solo quello che ha tag 1 una volta rimosso il tag)
4. ho creato una porta interna sul fakebrdige OVS0 con tag 802.1Q 1, chiamadola wan0
5. ho impostato il mac addressi di wan0 il mac originale che aveva la eth0
6. ho riportato la configurazione originale sia IPV4 che IPV6 usando wan0 invece che eth0

Il server è raggiungibile e la configurazione funziona. [nota: il fatto di aver utilizzato mm-mm-mm-mm-mm-01 come mac address alla eth0,
era per non avere un mac address duplicato (eth0 vs wan0) utilizzando per eth0 un mac address che di sicuro non creasse problemi alla rete ovh. Essendo mm-mm-mm-mm-mm-01 generato da ovh stesso, sono sicuro di questo. So che in questo scenario avere un mac duplicato nel mio fakebridge non crea problemi, ma ho preferito fare così]

Ho provato a configurare una macchina virtuale con XEN assegnando all'interfaccia IP F.F.F.F/32 MAC mm-mm-mm-mm-mm-00
e mettendo la relativa interfaccia nel fakebridge OVS0 con tag 802.1Q 1.

Anche stavolta tutto ha funzionato alla perfezione.

Ora, nella mia infrastruttura mi servono delle macchine che siano su un dominio di broadcast indipendente e su classe privata 169.254.100.0/24.
Quindi ho creato una seconda porta interna al fakebrdige OVS0, chiamandola vla100 e taggandola con tag 802.1Q 100
a cui ho assegnato l'ip 169.254.100.1/24

Ho creato due macchine virtuali aggiungendole come vlan100. VM1 e VM2, assegnando come IP 169.254.100.2/24 e 169.254.100.3/24.
Le macchine comunicano tra loro. Ho anche provato ad attivare sul server fisico l'ip-forwarding ed se imposto l' ip masquerading
e imposto come gateway delle macchine 169.254.100.1 vanno anche su internet. Ma questo ora non mi occorre. Così ho disabilitato
l' ip masquerading.

Se sul secondo server ripeto la configurazione e configuro i due OpenVSwitch con un tunnel posso creare una ipotetica VM3 sul
secondo server con IP 169.254.100.4/24 che raggiunge le prime due.

Lato OVH non dovrebbero esserci problemi. I frame con tag 802.1Q 100 non dovrebbero proprio arrivare. Quindi non dovrei causare nessun problema alla rete OVH.

Andiamo avanti.:

Ho creato un ulteriore porta interna al fakebdrige OVS0 chiamandola vlan200 con tag 802.1Q 200.
Ho assegnato a quest'ultima l'ip R.R.R.1/29 (ovvero il 1° utile della classe RIPE a me assegnata).

Ho creato qindi una macchina virtuale VM4 assegnando l'ip R.R.R.4/29 e ho usato come gateway R.R.R.1. Questa macchina è stata
aggiunta nel brdige OVS0 con tag 200.

Anche quì nessun problema. La macchina raggiunge l'esterno ed è raggiungibile dall'esterno.

Quì finisce la configuraizione che adesso funziona e di cui ho chiesto validazione ad OVH.

Quello che non mi piace è che sulla macchina fisica deve essere attivo l'ip forwarding. Allora ho pensato di procedere in questo modo.

Creo una nuova macchina virtuale VM6 aggiunta come trunk ad OVS0.
Su questa VM6 ho instalalto VyOS che è una distribuzione con funzioni di routing che userò anche come firewall.
Diciamo che questa VM6 ha interfaccia eth1 da cui ricavo

eth1.1 che mi gestisce la VLAN1
eh1.200 che mi gestisce la VLAN200

Alla eth1 ho assegnato come MAC address mm-mm-mm-mm-mm-02 (che era uno dei vmac generati da ovh).

sulla eth1.200 ho impostato come indirizzo R.R.R.6/29
sulla eth1.1 non ho messo nessun ip

Ho proceduto quindi con questa configurazione:

[CODE
]ip route add A.A.A.254 dev eth1.1
ip route add default via A.A.A.254/32 dev eth1.1
[/CODE]

in questo modo posso disabilitare il port-forwarding dalla macchina fisica ed utilizzare X.X.X.7 come gateway per la macchina VM4 (che aveva IP
R.R.R.4/29)

Per il traffico in uscita non dovrebbero esserci problemi. VM4 usa come gateway VM7 e quest'ultima con la configurazione di routing consigliata da OVH butta tutto sul default gateway di OVH (A.A.A.254). L'unico scoglio potrebbe essere un meccanismo di port-security ma siccome ho utilizzato un MAC Address trust non dovrei aver problemi. Quest'ultima è un'ipotesi dettata dal fatto che in passato ho utilizzato un IP failover
assegnato ad una interfaccia che aveva un virtual mac sì generato da ovh, ma correalto ad un altro IP.

Per il traffico in ingresso la situazione si fa più oscura. Credo (e quì posso sbagliare) che OVH quando non sono configurati MAC virtuali sugli IP delle classi RIPE instradi tutto direttamente all'interfaccia della macchina fisica (senza fare routing su ip).
In questo caso i frame ethernet in ingresso (per esempio diretti all'ip R.R.R.4) sarebbero visti anche dalla mia macchina VM7 sulla eth1.1 (che non ha IP) e poiché questa macchina ha sulla interfaccia eth1.200 la R.R.R.0/24 dovrebbe instradare correttamente i pacchetti.
Se invece fossero instradati verso l'ip della macchina virtuale al quale sono assegnati allora questo ultimo discorso cadrebbe.

Che ne pensate ? Qualcuno che conosce bene l'infrastruttura di OVH può segnalarmi se ci sono possibili problemi ?
Io al momento non ne vedo.


Perchè questa configurazione ? Mi da questi vantaggi:
1) la ethernet per le macchine virtuali è tutto più pulito (es. se faccio tcpdump)
2) lato ovh non dovrei causare nessun problema
3) posso avere più server con VM nella stessa classe con VLAN dedicate.
4) ho maggiore controllo del traffico e della infrastuttura mia interna grazie a OpenVSWitch
5) posso utilizzare VyOS Come router e firewall interno.