edofullo Eh lo so... Ma le aziende ragionano con il soldo. Non con l'etica o l'ecologia purtroppo.
Dovrebbero più che altro dare la possibilità agli utenti smaliziati di sbloccare il firmware dietro manleva per problemi che dovessero emergere dalle configurazioni avanzate, ma di nuovo è un costo aziendale, sono procedure da implementare e complica i flussi di assistenza dei call center sottopagati che non fanno altro che seguire le checklist. 
[cancellato] che non fanno altro che seguire le checklist.
Quando capiscono a grandi linee che check-list imbroccare
, altrimenti è la fine.
edofullo
Il mio modem TIM TG789vac v2.. uno dei primi che distribuivano allora. In versione 1.0.0 che superato il mese di uptime faceva reboot, menomale che è stato aggiornato poi..
Pagato 5*48 mesi interamente è in box a prendere polvere.
[cancellato] non basta tipo mettere la sezione "avanzate"? con un avviso tipo: Attenzione! Le impostazioni in questa modalità se modificate erroneamente, possono portare al cattivo funzionamento del dispositivo e l'assenza parziale o totale delle connessione internet. Cliccando " AVANTI " la responsabilità delle azioni sarà solo tua.
Un messaggio del genere e via, poi se il tizio fa danni, quando chiama, vedi se ha modificato una di quelle impostazioni e gli dici che per sistemare deve rivolgersi all'assistenza tecnica "avanzata" a pagamento ed hai risolto, TIM in parte lo fa, con quella cavolata di TIM DOCTOR o una roba del genere.
In tutto questo c'è windtre che su alcune business da un aethra tutto bloccato, che ogni cosa che vuoi modificare, devi mandare un modulo...
[cancellato] Perché più roba metti più l'utonto ci mette le manine piene di ditine dove non sa e più crea disservizi... che essendo su apparato venduto dal provider si traducono in chiamate al call center.
Meno roba c'è meno l'utonto può rompere.
Però con tutti gli zyxel di wind puoi fare di tutto e di più* (salvo bug) e non sembra questo crei particolari problemi.
Addirittura nella guida del VMG8823 spiegavano come modificare le soglie (SINR, RSSI) del band steering. E oggi ho scoperto come "ingannare" il modem e fargli vedere la /64 del tunnel di HE come 6RD, cosa impensabile con i modem (non fritz) degli altri BIG
* Limitazioni rispetto al firmware ufficiale ci sono, ma non sono eccessive, mancano un paio di funzioni e un paio di menu (tra cui il tr-069)
Il tunnel funziona bene ma non mi è chiara una cosa: dovrebbe rimaner su indefinitamente o viene chiuso se non c'è scambio dati / ogni x minuti?
Perchè non ho mai visto l'uptime oltre i 45 minuti
edofullo A logica, sta su. A meno che non ci sia incompatibilità sugli intervalli di refresh delle chiavi e una delle due parti chiuda la connessione se l'altra non le rinnova in tempo...
Prova con un CHR e ti togli il dubbio, ma a logica dovrebbe rimanere UP.
Update: il tunnel che cadeva era (probabilmente) dovuto a un mismatch dei tempi di rekeying sui due peers... un bel casino sto protocollo...
Domandina: ma se volessi mendare nel tunnel più subnet che non possono essere supernettate?
Perchè provando a creare due policy sul mikrotik e due connessioni su strongswan solo una sembra andare su correttamente (ovviamente mantenendo lo stesso peer), per l'altra esce un bel NO_PROPOSAL_CHOSEN (ovviamente la proposal è identica tra le due)
handymenny E oggi ho scoperto come "ingannare" il modem e fargli vedere la /64 del tunnel di HE come 6RD
racconta racconta…
eutampieri
Praticamente su he.net ho questo:
Server IPv4 Address: A
Server IPv6 Address: B/64
Client IPv4 Address: C
Client IPv6 Address: D/64Sul modem ho quindi configurato questo:
Service Provider IPv6 Prefix: D/64
IPv4 Mask Length: 0
Border Relay IPv4 Address: AIn realtà funzionava anche mettendo B/64 al posto di D/64, non ho capito quale dei due fosse il più corretto.
Ovviamente C devi aggiornarlo ogni volta che cambia il tuo ipv4
handymenny Adesso provo con lo ZTE
handymenny Wow funziona!
edofullo ma se volessi mendare nel tunnel più subnet che non possono essere supernettate?
Tunnel in routed mode con i due indirizzi della punto-punto e rotte statiche da entrambe le parti? 
edofullo provando a creare due policy sul mikrotik e due connessioni su strongswan solo una sembra andare su correttamente (ovviamente mantenendo lo stesso peer), per l'altra esce un bel NO_PROPOSAL_CHOSEN (ovviamente la proposal è identica tra le due)
Se vuoi farlo con le policy mode devi creare due diverse phase 2 nella stessa asserzione di fase 1.
Te l'ho detto che chi l'ha pensato era veramente un contorto...
[cancellato] Tunnel in routed mode
Sul Mikrotik mi sa non si può usare la versione con le interfacce virtuali, anche in questo si spera in ROS 7 
Dovrei usare GRE over IPSEC ma ho il problema dell'IP dinamico che a GRE mi sa non piace per nulla 
[cancellato] Se vuoi farlo con le policy mode devi creare due diverse phase 2 nella stessa asserzione di fase 1.
Ci ho provato... me ne va su solo una e sono tre ore che cerco di capire il perchè (IKE2)
edofullo None, in quel caso i due ip di tunnel sono gli indirizzi privati degli endpoint, non i pubblici 
Ma a quel punto ti bastano delle rotte non ti serve il tunnel... O no?
[cancellato] None, in quel caso i due ip di tunnel sono gli indirizzi privati degli endpoint, non i pubblici
E se da una parte avessi più di una LAN (ho la principale, iot, guest e vpn) devo perforza scegliere l'ip come interno a una di queste lan?
edofullo Eh scusa ho risposto senza connettere il cervello e ti ho mandato fuori strada. Senza le VTI in policy mode IPSec cattura e cifra solo i pacchetti destinati alle subnet del target.
Con una leggera penalità di overhead puoi allora crearti la punto-punto con il GREoIPSec come da esempio mikrotik. In pratica, dai alle reti "left" e "right" da convogliare nel tunnel solo gli indirizzi di loopback dei due dispositivi; tra i due loopback vai a costruire un GRE (che a questo punto ha sorgente e destinazione statici), che ti diventa una interfaccia a tutti gli effetti su cui puoi applicare regole di routing o addirittura usare protocolli di routing dinamico tipo OSPF e ISIS (qualcuno ha detto SD-WAN? 
).
In alternativa devi creare più policy (SA Phase 2) ognuna con le varie combinazioni delle subnet L<-->R che vuoi far vedere nell'IPSec. Ma se sono più di due o tre diventa uno sbatti, meglio convogliarle in un GRE.
[cancellato] Ti ringrazio per la spiegazione, mi mancava la parte sul loopback.
Penso che andrò per la opzione 3: cambiare gli indirizzi alle varie VLAN ed aggregarle in una /22... se in futuro avrò bisogno mi adopererò per il GRE.
Ma se uno ha 3 sub da una parte e 3 dall'altra deve teoricamente tirare su 9 policy (e quindi 9 tunnel)? Ma non ci hanno pensato che c'era questa possibilità?
Grazie ancora, domani sistemo e vi aggiorno
edofullo Ma non ci hanno pensato che c'era questa possibilità?
Eh, chettedevodì...
Comunque dai non è così complessa la parte con il GRE. Oddio, bisogna vedere se lato scolapasta si può fare...
Informativa privacy
-
Informativa cookie
-
Termini e condizioni
-
Regolamento
-
Disclaimer
-
🏳️🌈
P.I. IT16712091004 - info@fibraclick.it
♻️ Il server di questo sito è alimentato al 100% con energia rinnovabile