Sto cercando un provider FTTC 200 VULA che fornisca connettivita' IPv6 nativa residenziale e full MTU (1500 bytes, no clamping). Mi andrebbero bene sia IPoE che PPPoE purche' quest'ultima supporti i baby jumbo frames da 1508 bytes (RFC4638) cosi' da evitare il clamping. A breve distanza sono coperto da una rete business Dimensione FTTH 2500 Mbps con cui mi trovo molto bene, ma purtroppo gli aggiornamenti firmware che dovrebbero introdurre il supporto ai baby jumbo frames tardano ad arrivare (@giusgius ci sono novita' in merito?) e quindi sto cercando un'alternativa perlomeno per la linea residenziale (che purtroppo e' coperta solo da FTTC 200).
Ho letto che sia Navigabene (che supporta sia VULA che NGA sul mio indirizzo) che Spadhausen (prezzo piu' competitivo, ma a quanto ne so potrebbe essere un semplice EasyIP perche' sul loro sito non viene specificato) utilizzano entrambi IPoE, ma non avendolo mai utilizzato avrei alcune domande. Se volessi l'ip pubblico su un mio server piuttosto che sul modem dovrei configurare quest'ultimo in bridge mode similarmente a quanto si faceva con PPPoE? A quel punto con PPPoE era sufficiente tirare su una PPPoE separata per ogni ip pubblico di cui necessitavo, ma con IPoE? Devo configurare una vlan separata per ogni ip pubblico? E per mantenere anche il nat sul router principale? Con PPPoE si utilizzava PPPoE passthrough, immagino che con IPoE serva un'ulteriore vlan.
Provider IPv6 Dual Stack (static,PD) + IPoE o PPPoE 1508 bytes baby jumbo frames
- Dimensione
darkbasic Ciao!
Posso chiederti il vantaggio reale del supporto RFC4638 sulla tua linea residenziale?
darkbasic Se volessi l'ip pubblico su un mio server piuttosto che sul modem dovrei configurare quest'ultimo in bridge mode similarmente a quanto si faceva con PPPoE? A quel punto con PPPoE era sufficiente tirare su una PPPoE separata per ogni ip pubblico di cui necessitavo, ma con IPoE? Devo configurare una vlan separata per ogni ip pubblico? E per mantenere anche il nat sul router principale? Con PPPoE si utilizzava PPPoE passthrough, immagino che con IPoE serva un'ulteriore vlan.
L'ideale è prendere una subnet /30 così da avere un IP in più disponibile per l'uso sulla LAN.
- Modificato
giusgius i vantaggi sono molteplici:
- Possibilita' di essere raggiunti da client mal configurati in cui la pMTU discovery non funziona perche' bloccano ICMP.
- Minore overhead, specialmente in combinazione con layer aggiuntivi come tunnel vpn dove gli 8 bytes del pppoe si fanno sentire in aggiunta all'overhead del tunnel.
- openvpn3 client non supporta fragment
- Anche qualora si utilizzi openvpn 2 la dimensione del pacchetto oltre la quale si inizia a frammentare va decisa in anticipo e quindi se si vogliono supportare clienti "zoppi" con MTU a 1492 si penalizzano anche quelli con MTU a 1500 che si beccano overhead inutile.
- Sono incappato in applicativi che testano la trasmissione di frammenti a massima dimensione (che passano solo con MTU 1500) per discernere il fatto che la comunicazione avvenga in una rete locale piuttosto che pubblica.
- Sono incappato in bug nell'implementazione del clamping mtu in firewalld che mi hanno fatto diventare matto a debuggare.
A mio parere una connessione che si rispetti non dovrebbe mai avere MTU inferiore a 1500 e quest'intera categoria di problematiche non dovrebbe nemmeno esistere nel 2025. Ero fiducioso che prima o poi Dimensione avrebbe implementato RFC4638 (e' sufficiente un semplice firmware upgrade a detta dei vostri tecnici) ma sto cominciando a ricredermi.
- Dimensione
Grazie per la panoramica!
darkbasic Ero fiducioso che prima o poi Dimensione avrebbe implementato RFC4638 (e' sufficiente un semplice firmware upgrade a detta dei vostri tecnici) ma sto cominciando a ricredermi.
Si tratta di una funzionalità che deve essere supportata lato BRAS (quindi lato nostro oltre che lato cliente), con un upgrade del software che dovrebbe aggiungere tale funzionalità, ma al momento non è ancora disponibile, e dipende dal produttore, noi non possiamo intervenire in questo senso, provo a fare un'indagine ulteriore per capire.
- Modificato
darkbasic vantaggi sono molteplici:
Sulle reti mobili di mezzo mondo sei sui 1400-1300 byte di MTU, a seconda del gestore. Ben sotto i 1500 e non ci sono tutti questi problemi e applicativi mal funzionanti.
OpenVPN è quasi sempre configurato in maniera conservativa, proprio per non avere questi problemi.
darkbasic Sono incappato in applicativi
Mai successo, quali ad esempio?
Non che non ti creda ma è curiosità.
8 byte di overhead mi sembrano risibili.
Poi certo che sia meglio è ovvio, non lo vedo così limitante personalmente.
gandalf2016 ti stupiresti di quanti problemi legati all'MTU ho avuto con openvpn in passato, eccone un esempio con Tiscali:
https://forum.fibra.click/d/44630-lista-nera-dei-provider-che-multiplexano-le-sessioni-ppp-via-tunnel-l2tp
https://www.mail-archive.com/openvpn-users@lists.sourceforge.net/msg06744.html
gandalf2016 Mai successo, quali ad esempio?
Non che non ti creda ma è curiosità.
Il primo che mi viene in mente e' Sky Q, ma non e' l'unico caso che mi e' capitato. Quando gli Sky Q Mini fanno il pairing con il decoder che fa da media server provano a forzare un pacchetto alla massima dimensione per scongiurare la presenza di tunneling L2. In verita' da tempo hanno aggiunto (se non addirittura sostituito completamente il controllo, vado a memoria) un controllo della latenza, tanto che pur facendolo lavorare sulla stessa rete fisica ma aumentando artificalmente la latenza l'handshake fra mini e media server fallisce ugualmente. Una volta fatto l'handshake iniziale puoi introdurre tutta la latenza che vuoi (e frammentare quanto vuoi) senza che gliene importi piu' nulla.
- Modificato
darkbasic
Tutti casi limite quindi..
Per OpenVPN basta abbassare l’MTU nelle impostazioni. Personalmente ho sempre impostato MTU a 1300 e di conseguenza MSS a 1260. Proprio per assicurarmi il corretto funzionamento su qualsiasi rete mobile. Che senso avrebbe altrimenti la VPN se non posso usarla da una rete mobile verso casa ? Ok baratti l’efficienza… ma PMTUD funzionante è un po’ utopia.
Diverso il caso di una lan to lan tra due reti fisse.
Per Sky, c’è esplicita volontà da parte loro di evitare il Tunnel L2.
Però qui non capisco il punto:
Anche con un MTU di 1500 byte lato provider avresti lo stesso problema oltre alla latenza.
gandalf2016 Per Sky, c’è esplicita volontà da parte loro di evitare il Tunnel L2.
Però qui non capisco il punto:
Anche con un MTU di 1500 byte lato provider avresti lo stesso problema oltre alla latenza.
Non mi interessa particolarmente far funzionare SKy, la parte divertente era capire che controlli avessero messo in atto. Nel farlo ho scoperto per caso una vulnerabilita' di tipo denial of service in openvpn quindi posso ritenermi soddisfatto.
La cosa che mi interessa veramente e' che i miei server siano sempre raggiungibili anche dai client con PMTUD non funzionante e per quello bisogna avere MTU 1500.
La seconda cosa che mi interessa e' avere una variabile in meno da debuggare: mi sono imbattuto troppe volte in problemi legati all'MTU per non tenere in considerazione questa variabile nella scelta del provider.
darkbasic Il primo che mi viene in mente e' Sky Q, ma non e' l'unico caso che mi e' capitato. Quando gli Sky Q Mini fanno il pairing con il decoder che fa da media server provano a forzare un pacchetto alla massima dimensione per scongiurare la presenza di tunneling L2. In verita' da tempo hanno aggiunto (se non addirittura sostituito completamente il controllo, vado a memoria) un controllo della latenza, tanto che pur facendolo lavorare sulla stessa rete fisica ma aumentando artificalmente la latenza l'handshake fra mini e media server fallisce ugualmente. Una volta fatto l'handshake iniziale puoi introdurre tutta la latenza che vuoi (e frammentare quanto vuoi) senza che gliene importi piu' nulla.
Non c'è alcun check basato sull'MTU nell'handshake tra Sky Q Platinum (master) e Mini/Go (slave), né altre ipotesi fantasiose tipo powerline di cui ho letto in giro. Il check è soltanto sulla latenza, se <8 ms fallisce. Ed è lo stesso identico introdotto anche su Sky Stream con Multiscreen attivo. Per capire quello che fa basta Wireshark. Ero anche riuscito ad ingannare l'app (Sky Go) alterando i pacchetti TCP tramite attacco MitM, infatti risultava "Sincronizzato a Sky Q" e mi faceva vedere la lista delle registrazioni anche in VPN, ma poi i video non partivano perché il master non forniva le chiavi di decodifica se il latency test per lui era fallito. Purtroppo alcune risposte sono criptate (anche se con una roba molto basic), il latency test è embedded nella piattaforma VideoGuard Connect. E' stato bello smanettarci tutte le sere per un mesetto circa, alla fine problema risolto efficacemente con un encoderino HDMI cinese come questo e app telecomando come questa. Comunque se vuoi approfondire la cosa puoi contattarmi su Telegram con lo stesso nick. /OT
- Modificato
dariuccio83 Non c'è alcun check basato sull'MTU nell'handshake tra Sky Q Platinum (master) e Mini/Go (slave)
Sospetto che la piattaforma sia passata attraverso diverse iterazioni nel tempo perche' lessi di persone che sono riuscite a completare l'handshake semplicemente frammentando i pacchetti a livello vpn (senza usare pmtud per intenderci). L'unica cosa che ricordo per certo e' che quella che avevo io faceva il controllo sulla latenza.
dariuccio83 alterando i pacchetti TCP tramite attacco MitM, infatti risultava "Sincronizzato a Sky Q" e mi faceva vedere la lista delle registrazioni anche in VPN, ma poi i video non partivano perché il master non forniva le chiavi di decodifica se il latency test per lui era fallito
In compenso una volta scambiata la chiave puoi spostarlo in qualsiasi rete e fino al prossimo power cycle non ti da noie (anche se non ho mai aspettato a sufficienza per vedere se le chiavi avessero una qualche scadenza temporale).
dariuccio83 e app telecomando
Io avevo optato per un repeater a infrarossi perche' trovo il telecomando sky molto ergonomico, ma la realta' dei fatti e' che Sky non lo guardo quasi mai e quindi era piu' divertente provare a bypassare il blocco che averlo funzionante.
Gabri Non è così scontato, dipende molto dall'operatore, non tutti sono così permissivi come TIM
Beh Tim gli ip aggiuntivi te li regalava, io sono disposto a pagarli.
darkbasic Se volessi l'ip pubblico su un mio server piuttosto che sul modem dovrei configurare quest'ultimo in bridge mode similarmente a quanto si faceva con PPPoE? A quel punto con PPPoE era sufficiente tirare su una PPPoE separata per ogni ip pubblico di cui necessitavo, ma con IPoE? Devo configurare una vlan separata per ogni ip pubblico? E per mantenere anche il nat sul router principale? Con PPPoE si utilizzava PPPoE passthrough, immagino che con IPoE serva un'ulteriore vlan.
@pioccd so che utilizzate IPoE, posso farti alcune domande sul suo funzionamento?
- Modificato
darkbasic La cosa che mi interessa veramente e' che i miei server siano sempre raggiungibili anche dai client con PMTUD non funzionante e per quello bisogna avere MTU 1500
Ma non è affatto garantito.
Se tiri su un server OpenVPN o wireguard e l’altro end ha un MTU più basso hai comunque il problema.
Devi semplicemente considerarlo tu quando tiri su il server VPN e usare una opzione più conservativa barattando efficienza. Se PMTUD non funziona non hai alternativa.
Il mondo è vario, non tutti hanno MTU 1500 byte. Ti facevo l’esempio delle reti mobili dove non è quasi mai 1500 per esempio.
Quindi una volta che hai risolto la tua connessione ce ne saranno mille altrettante che lo hanno più basso da cui potenzialmente ti connetterai.
gandalf2016 Ma non è affatto garantito.
Se tiri su un server OpenVPN o wireguard e l’altro end ha un MTU più basso hai comunque il problema.
Non mi riferivo alle vpn ma a un qualsiasi generico servizio che hosti (email, webserver, etc.).
Se hai MTU 1500 non avrai mai problemi con i client che hanno PMTUD rotto perche' avrai sempre un MTU maggiore o uguale al loro.
- Navigabene
Si certo, se preferisci un riscontro "diretto" contattami sui recapiti che ho in bio e vediamo se riusciamo a soddisfare le tue esigenze.
Ti anticipo che da parte nostra la rete supporta MTU maggiore di 1500, da vedere poi lato trasporto Fibercop/Vula se la situazione è la medesima (spesso da centrale a centrale cambia)
gandalf2016 dove non è quasi mai 1500
Pensa che iliad dichiara 1540...
ordex Su OpenVPN si suggerisce di ripiegare su --mssfix piuttosto che --fragment o ridurre l'MTU.
Di base con quello non dovresti avere grossi problemi.
Peccato che in questo modo devi avere PMTUD funzionante, cosa che non sempre avviene (vedi l'esempio che ho postato prima).
darkbasic Peccato che in questo modo devi avere PMTUD funzionante
Il problema del pppoe a 1492 ce l’hai solo sulle nuove connessioni in ingresso non stateful, tipo udp. Tutti i vari client/server vpn prevedono la possibilità’ aggiustarsi l’mtu e risolvi in questo modo. In caso di nuova connessionr tcp in ingresso con icmp off, negoziano l’mtu corretto con il tcp syn l’mtu grazie a mss. In uscita non ti crea problemi, puoi tenere mss off se il tuo router/firewall lo prevede.
Il problema a gestire mtu 1492 esposto di casa con icmp off é vero c’é ma solo sulle nuove connesioni che non sono stateful, ma é gestibile tranquillamente nella maggior parte dei casi.