Re: Openconnect e network manager

2024-01-15 Per discussione Gollum1
Il Lun 15 Gen 2024, 21:13 Leonardo Boselli  ha scritto:

> On Mon, 15 Jan 2024, Gollum1 wrote:
> > Purtroppo non vedo alcuna soluzione, a meno che non riesca ad inviare
> > i pacchetti della sola macchina virtuale attraverso la mia
> > connessione, invece che attraverso la VPN, dovrei provare con una
> > rotta statica, una volta che ho stabilito la prima connessione.
> >
> > Se non funziona neppure questo, me ne farò una ragione e cercherò di
> > lavorare in modo alternato sulle due macchine (alzando e abbassando
> > alla bisogna la connessione VPN).
>
> hai provato a mmettere una route specifica per queste macchine che hanno
> sia un indirizzo pubblico che uno privato, in modo che usino sempre lo
> stesso ?
>

No, sono due macchine diverse su due server VMware diversi, uno
raggiungibile da una rete e l'altro raggiungibile da un'altra rete, che tra
loro non parlano.

Sono due sezioni separate della rete 10.0.0.0/8


Re: Openconnect e network manager

2024-01-15 Per discussione Leonardo Boselli

On Mon, 15 Jan 2024, Gollum1 wrote:

Purtroppo non vedo alcuna soluzione, a meno che non riesca ad inviare
i pacchetti della sola macchina virtuale attraverso la mia
connessione, invece che attraverso la VPN, dovrei provare con una
rotta statica, una volta che ho stabilito la prima connessione.

Se non funziona neppure questo, me ne farò una ragione e cercherò di
lavorare in modo alternato sulle due macchine (alzando e abbassando
alla bisogna la connessione VPN).


hai provato a mmettere una route specifica per queste macchine che hanno 
sia un indirizzo pubblico che uno privato, in modo che usino sempre lo 
stesso ?


--
Leonardo Boselli
Firenze, Toscana, Europa
http://i.trail.it
tel:+393287329225

Re: Openconnect e network manager

2024-01-15 Per discussione Gollum1
Il giorno dom 14 gen 2024 alle ore 12:13 Davide Prina
 ha scritto:
>
> Gollum1 ha scritto:

[...]

> > Oltretutto, ricordo che quando facevo la connessione con network
> > manager, riuscivo a tenere contemporaneamente la disponibilità della
> > mia rete privata e di quella della VPN, ieri, provando il collegamento
> > da terminale con openconnect, non riuscivo più ad accedere alla mia
> > rete privata
>
> in teoria una VPN indirizza in automatico tutto il traffico di rete
> verso di essa.
> Però puoi modificare le rotte per avere il solo traffico verso la rete
> interna che devi raggiungere tramite VPN e lasciare il resto del
> traffico nella rete tua "normale".
>
> se la VPN crea l'interfaccia tun0, allora con i seguenti due comandi
> prima elimini tutte le rotte verso tun0 e poi abiliti solo le rotte
> verso la rete interna sulla VPN e tutto il resto viene risolto come
> se non fossi in VPN
>
> route del -net 0.0.0.0 dev tun0
> route add -net 10.0.0.0 netmask 255.0.0.0 dev tun0
>

ho fatto una verifica:

- prima dell'attivazione della vpn:
ip address show

3: wls1:  mtu 1500 qdisc noqueue
state UP group default qlen 1000
   altname wlp2s0
   inet 192.168.1.128/24 brd 192.168.1.255 scope global dynamic
noprefixroute wls1
  [...]

ip route show

default via 192.168.1.1 dev wls1 proto dhcp src 192.168.1.128 metric 600
192.168.1.0/24 dev wls1 proto kernel scope link src 192.168.1.128 metric 600

- dopo l'attivazione della vpn:
ip address show

3: wls1:  mtu 1500 qdisc noqueue
state UP group default qlen 1000
   altname wlp2s0
   inet 192.168.1.128/24 brd 192.168.1.255 scope global dynamic
noprefixroute wls1
  [...]
4: tun0:  mtu 1400 qdisc
fq_codel state UNKNOWN group default qlen 500
   link/none
   inet 10.110.163.137/32 scope global tun0
  valid_lft forever preferred_lft forever
   [...]

ip route show

default dev tun0 scope link
default via 192.168.1.1 dev wls1 proto dhcp src 192.168.1.128 metric 600
10.110.163.137 dev tun0 scope link
169.254.0.0/16 dev tun0 scope link metric 1000
192.168.1.0/24 dev wls1 proto kernel scope link src 192.168.1.128 metric 600
  via 192.168.1.1 dev wls1 src 192.168.1.128
metric 600

quindi, da quello che capisco, in questo modo tutto il traffico è
comunque attraverso la mia rete privata e non attraverso quella
aziendale.

Il problema è che io vorrei attivare due sessioni vmware su due
macchine virtuali diverse, che stanno su due sezioni di rete diverse
dell'azienda, la prima la posso raggiungere solo se sono nella mia
rete privata, la seconda solo se sono nella VPN. purtroppo dalla rete
VPN non posso raggiungere la rete in cui si trova la prima macchina
virtuale, e riconoscendo che la prima macchina virtuale è interna
all'azienda, cerca di farla passare nella vpn (con nslookup mi risolve
l'indirizzo della prima macchina come indirizzo interno, quindi lo
manda dentro la VPN).

Prima di attivare la VPN, ho visto con nslookup l'IP pubblico del
server vmaware, attivo la vpn e poi faccio puntare vmaware all'IP
pubblico, lo raggiungo e mi autentico, ma poi rimane bloccato e non
riesce a carcare la macchina virtuale...

Credo che poi la macchina virtuale abbia comunque un indirizzo
interno, e quindi cerca di far passare (dopo l'autenticazione) i dati
della macchina virtuale attraverso la VPN, a questo punto mi trovo con
una connessione che cerca di entrare da una parte e uscire dall'altra,
cosa che manda tutto a scatafascio.
(i firewall intercettano e interrompono queste connessioni sbilanciate).

Purtroppo non vedo alcuna soluzione, a meno che non riesca ad inviare
i pacchetti della sola macchina virtuale attraverso la mia
connessione, invece che attraverso la VPN, dovrei provare con una
rotta statica, una volta che ho stabilito la prima connessione.

Se non funziona neppure questo, me ne farò una ragione e cercherò di
lavorare in modo alternato sulle due macchine (alzando e abbassando
alla bisogna la connessione VPN).

Grazie
> Ciao
> Davide
>
> --
> La mia privacy non è affar tuo
> https://noyb.eu/it
> - You do not have my permission to use this email to train an AI -
> If you use this to train your AI than you accept to distribute under AGPL
> license >= 3.0 all the model trained, all the source you have used to
> training your model and all the source of the program that use that model
>


-- 
Byez
-- 
Gollum1 - http://www.gollumone.it
Tesoro, dov'é il mio teoro...



Re: Frigorifero e Decoder Wi-Fi

2024-01-15 Per discussione pinguino

Il 21/12/23 11:21, pinguino ha scritto:

Buon giorno Lista,
In questo periodo di switch-off, per passare al nuovo digitale terrestre 
con i nuovi standard DVB-T2 sto valutando l'acquisto di un nuovo decoder.

La mia TV ha già un dispositivo per vedere i nuovi canali.
Ma ho saputo che ci sono dei decoder wi-fi con il sistema linux.
La prima domanda è quali sono i modelli migliori ?
Perché dalla newsletter di Fastweb ho visto che consigliano questo :
Il Dreambox DM525 HD, che monta un sistema operativo basato su Linux e 
offre all’utente moltissime possibilità di personalizzazione.

Questo è il più avanzato e costoso.
Ma c'è anche il modello base:
Edision Picco T265, che non ha linux. Ma costa meno.

La seconda domanda è più tecnica. Siccome ho in casa il Wi-fi di 
Fastweb, per l'installazione e la configurazione funziona come un tablet 
o uno smartphone ?
Cioè da una parte si collega alla porta USB della TV poi accedo con le 
credenziali del mio Wi-Fi di Fastweb ? E la TV può andare su Internet, 
in teoria.


Grazie
Saluti
Claudio



Buon giorno Lista,
Ora mi sto concentrando sul frigorifero.
Cercando qua e là ho trovato per caso un modello di frigorifero che ha 
la connessione Wi-Fi, per monitorare i consumi con una App di Samsung 
per Android. Dicono che si può anche risparmiare il 15%.
Poi sembra che si possano anche inserire le scadenze dei vari cibi, per 
ricevere delle notifiche, tramite email o sullo smartphone.

La domanda è questa :
Esistono anche dei modelli di frigoriferi Open Source ?

Grazie
Saluti
Claudio

--
https://www.linkedin.com/in/claudio-sandrone



Re: Debian 12.4 Kernel Panic durante spegnimeto

2024-01-15 Per discussione Alessandro Baggi




Il 14/01/24 12:00, Davide Prina ha scritto:


ma hai lo stesso problema anche con i driver liberi?
Io userei quelli.


Ho provato con nouveau e con quelli il problema si presenta di più.



Tieni conto che versioni nuove di Linux possono far cambiare le API
esposte rendendo il tutto incompatibile con quelle delle versioni
precedenti. Se tu hai una vecchia scheda può essere che i driver
proprietari non vengano più aggiornati per quella tua scheda e questo
potrebbe essere la causa del problema.



Per essere sincero, il problema mi si presenta con Debian 12. Ho provato 
anche altre distro tra cui Ubuntu (sempre driver sito Nvidia) e anche 
AlmaLinux e il problema non si presenta. A questo punto sembra 
riconducibile ad una problematica del kernel di Debian.



Altro caso potrebbe essere che c'è un bug nella nuova versione di
Linux... puoi cercare nei bug report se trovi qualcosa.



Cercherò.

Grazie per la risposta.

Un saluto Alessandro.