Re: VPN

[Diego Zuccato]

Chiudi sempre l'accesso alle telecamere: i server web embedded sono 
famigerati per la mole di bug a disposizione degli attaccanti e per la 
mancanza di aggiornamenti.
Se hai una VPN (o un forward SSH, o un reverse proxy autenticante, o 
MotionEye, o...) allora i forward a te non servono.


Diego

Il 28/12/2023 19:13, Giuliano Curti ha scritto:
Il gio 28 dic 2023, 18:18 Leonardo Boselli <mailto:leo-stre...@trail.it>> ha scritto:


Ciao Leonardo, grazie;

Una domanda importantissima: gli utenti predefiniti si collegano sempre
dallo stesso indirizzo, e lo usano solo loro ? perché se così fosse
basterebbe un allow e a quel punto non ti chiede neppure la
utenticazione.


Sì, gli utenti sarebbero sempre gli stessi; riguardo l'indirizzo non 
saprei, si collegano da fuori quindi con indirizzi dinamici; scusa, 
forse non ho capito bene.






Aggiungo ancora un (o dei tanti) dubbio.
In questo momento ho aperto sul router la porta 22 per l'amministrazione 
SSH e le porte 8080+ per la trasmissione web delle telecamere (1 per 
ogni telecamera + 1 per l'applicativo).


Se instauro il tunnel SSH le porte 8080+ devono cmq rimanere aperte? In 
tal caso il discorso risulterebbe vanificato perché il sistema 
continuerebbe a trasmettere in chiaro su quelle porte; sono protette da 
user: password e da fail2ban, ma il tunneling non mi porterebbe 
vantaggi, mentre ne avrebbe parecchi se potessi chiuderle (come ho detto 
i dati non sono per nulla sensibili, per me è semplicemente un'occasione 
per capire di più di reti e sicurezza).


--
Leonardo Boselli
Firenze, Toscana, Europa


Grazie della vostra infinita pazienza, un saluto,
Giuliano



--
Diego Zuccato
DIFA - Dip. di Fisica e Astronomia
Servizi Informatici
Alma Mater Studiorum - Università di Bologna
V.le Berti-Pichat 6/2 - 40127 Bologna - Italy
tel.: +39 051 20 95786

Re: VPN

[Giuliano Curti]

Il dom 31 dic 2023, 11:28 Davide Prina  ha scritto:

Ciao Davide,

Giuliano Curti ha scritto:
>
> > Purtroppo il port forwarding fatto sul router interno alla rete, pur
> consentendo l'accesso alla home dello stesso, perde tutta l'impostazione
> grafica rendendo praticamente illeggibile il contenuto.
>
> > ...
>
> ma che desktop environment usi?
> Con wayland il l'X forwarding non dovrebbe più funzionare.
>

Purtroppo non sono sulla macchina e non lo so; presumo X, quello standard
della Ubuntu 22.04, ma succede lo stesso su mobile Android 14

>
> Per poter avere qualcosa di simile ho visto che c'è
> waypipe
>
> Mi sono un po' perso nel thread e non me ne intendo su
> questo argomento... ma se si devono trasmettere le immagini
> di telecamere non si potrebbe usare uno screencast e accedere
> ..
>

Però il mio problema è l'opposto: le telecamere trasmesse su diverse da
motion le vedo bene, mentre non vedo bene la trasmissione del web server
del router, pur tunnellizzato allo stesso modo :-(

Ciao
> Davide
>

Grazie, ciao,
Giuliano

Re: VPN

[Davide Prina]

Giuliano Curti ha scritto:

> Purtroppo il port forwarding fatto sul router interno alla rete, pur 
> consentendo l'accesso alla home dello stesso, perde tutta l'impostazione 
> grafica rendendo praticamente illeggibile il contenuto.

> Anche l'opzione -X non da miglioramenti (non ho provato la -Y): sapete se c'è 
> qualche opzione ovvero qualche altro browser graficamente meno avido di 
> Chromium, che renda possibile l'operazione?

ma che desktop environment usi?
Con wayland il l'X forwarding non dovrebbe più funzionare.

Per poter avere qualcosa di simile ho visto che c'è
waypipe

Mi sono un po' perso nel thread e non me ne intendo su
questo argomento... ma se si devono trasmettere le immagini
di telecamere non si potrebbe usare uno screencast e accedere
allo stream con un semplice programma come mpv?
Ad esempio ho visto che c'è questo:
ustreamer

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

Re: VPN

[Giuliano Curti]

VPN aggiornamento

Ciao a tutti,

a seguito dello scambio intervenuto sull'argomento, ho verificato che la
soluzione ipotizzata è tale, cioè il port forwarding SSH consente di
accedere ad una risorsa dell'host remoto. Qui sta la parte mezza o 3/4
piena del bicchiere, ora arriva il quarto vuoto :-)

Volevo completare l'operazione con
1) la chiusura delle porte, non più necessarie, sul router
2) la eliminazione delle password di accesso a quella risorsa, ormai
tunnellizzata
3) la eliminazione della jail di fail2ban relativa a motion, non più
necessaria,
cioè , primo passo, accedere al router.

Purtroppo il port forwarding fatto sul router interno alla rete, pur
consentendo l'accesso alla home dello stesso, perde tutta l'impostazione
grafica rendendo praticamente illeggibile il contenuto.

Anche l'opzione -X non da miglioramenti (non ho provato la -Y): sapete se
c'è qualche opzione ovvero qualche altro browser graficamente meno avido di
Chromium, che renda possibile l'operazione?

Con questa procedura avrei tentato anche di modificare la porta SSH con
qualche ragionevole speranza di non rimanere chiuso fuori dalla porta, ma
mi sa che devo rinviare a quando sarò in presenza fisica delle
apparecchiature.

Grazie in ogni caso a tutti, ho imparato una cosa nuova. Saluti,
Giuliano

Re: VPN

[mauro]

28 dicembre 2023 alle ore 22:18, "Giuliano Curti"  scrive:



> 
> > 
> > 2: la porta 22 e' bersagliata continuamente da scriptkiddies che tentanto 
> > tutte le possibili combinazioni pur di indovinare gli accessi. Suggerisco 
> > di cambiare la porta di default del servizio ssh, adeguare ovviamente le 
> > impostazioni di eventuali firewall, file2ban e soci in modo da togliere di 
> > mezzo gli script automatici. Non si tratta di un vero e' proprio metodo di 
> > sicurezza, ma evita l'affollamento di tentativi di accesso automatici che 
> > riempono i log.
> > 
> 
> Si, ho visto l'avvertenza in molti post e interverrò, però, come info 
> generale, l'accesso con chiave e la protezione fail2ban non sono una solida 
> protezione?
> 

fail2ban analizza il log e blocca gli accessi agli ip che esagerano sulla 
porta 22 in breve tempo ti ritrovi delle liste lunghe una quaresima.
l'accesso con chiave o certificato danno sicuramente la garanzia che cerchi. Il 
discorso di cambiare la porta e' quella di bloccare sul nascere il tentativo. 
Il risultato e' avere un log pulito, risparmio di cicli macchina nel 
controllare chi si collega da parte di fail2ban, meno utilizzo di banda (non e' 
che rubano chissa' quanto, ma onestamente vedere un log pulito ti risparmia la 
perdita di tempo - e lo risparmia pure a fail2ban - alla ricerca di eventuali 
attaccanti). Cambiare la porta non è assolutamente un presidio di sicurezza 
come lo sono chiavi, password e fail2ban, ma aiuta a tenere meglio sotto 
controllo la situazione proprio perche' c'e' meno monnezza da controllare.


M.

Re: VPN

[Giuliano Curti]

Il gio 28 dic 2023, 22:11  ha scritto:

Ciao Mauro,

> 28 dicembre 2023 alle ore 19:13, "Giuliano Curti"  >
> scrive:
>
>
>
> Aggiungo ancora un (o dei tanti) dubbio.
> In questo momento ho aperto sul router la porta 22 per l'amministrazione
> SSH e le porte 8080+ per la trasmissione web delle telecamere (1 per ogni
> telecamera + 1 per l'applicativo).
>
> Se ...
>
> --
>
>
> ci sono due punti:
> 1: puoi chiudere tutte le porte ad accezione della ssh. tutti gli accessi
> passerebbero via ssh e non ci sarebbe piu' necessita' di avere le ulteriori
> porte aperte.
>

Bene, adesso questo mi è  chiaro :-)

2: la porta 22 e' bersagliata continuamente da scriptkiddies che tentanto
> tutte le possibili combinazioni pur di indovinare gli accessi. Suggerisco
> di cambiare la porta di default del servizio ssh, adeguare ovviamente le
> impostazioni di eventuali firewall, file2ban e soci in modo da togliere di
> mezzo gli script automatici. Non si tratta di un vero e' proprio metodo di
> sicurezza, ma evita l'affollamento di tentativi di accesso automatici che
> riempono i log.
>

Si, ho visto l'avvertenza in molti post e interverrò, però, come info
generale, l'accesso con chiave e la protezione fail2ban non sono una solida
protezione?

Grazie infinite, ciao,
Giuliano

Re: VPN

[mauro]

28 dicembre 2023 alle ore 19:13, "Giuliano Curti"  scrive:



> 
> Aggiungo ancora un (o dei tanti) dubbio.
> In questo momento ho aperto sul router la porta 22 per l'amministrazione SSH 
> e le porte 8080+ per la trasmissione web delle telecamere (1 per ogni 
> telecamera + 1 per l'applicativo).
> 
> Se instauro il tunnel SSH le porte 8080+ devono cmq rimanere aperte? In tal 
> caso il discorso risulterebbe vanificato perché il sistema continuerebbe a 
> trasmettere in chiaro su quelle porte; sono protette da user: password e da 
> fail2ban, ma il tunneling non mi porterebbe vantaggi, mentre ne avrebbe 
> parecchi se potessi chiuderle (come ho detto i dati non sono per nulla 
> sensibili, per me è semplicemente un'occasione per capire di più di reti e 
> sicurezza).
> 
> > 
> > --
> >
> 

ci sono due punti:
1: puoi chiudere tutte le porte ad accezione della ssh. tutti gli accessi 
passerebbero via ssh e non ci sarebbe piu' necessita' di avere le ulteriori 
porte aperte.
2: la porta 22 e' bersagliata continuamente da scriptkiddies che tentanto tutte 
le possibili combinazioni pur di indovinare gli accessi. Suggerisco di cambiare 
la porta di default del servizio ssh, adeguare ovviamente le impostazioni di 
eventuali firewall, file2ban e soci in modo da togliere di mezzo gli script 
automatici. Non si tratta di un vero e' proprio metodo di sicurezza, ma evita 
l'affollamento di tentativi di accesso automatici che riempono i log.

> 
> 
>

Re: VPN

[Giuliano Curti]

Il gio 28 dic 2023, 18:56 gerlos  ha scritto:

Ciao Gerlo,

Il 26/12/23 18:57, Giuliano Curti ha scritto:
>
> Ciao a tutti,
>
> ho 
>
>
> Per questo tipo di applicazioni al momento sto usando Tailscale (vedi
> https://tailscale.com/).
>
> È un'implementazione di una rete mesh Wireguard, semplicissima da usare e
> ottimamente documentata. I client sono open source ed esistono per
> qualsiasi OS. Il backend server predefinito è closed, ma ne esiste
> un'implementazione open source che puoi mettere su un tuo sistema - ma se
> vuoi ottenere rapidamente risultati la cosa migliore è appoggiarti ai loro
> server.
>
> Una volta che un tuo dispositivo si collega alla tua rete tailscale (in
> gergo "tailnet"), puoi raggiungerlo tramite un IP statico tipo 100.x.y.z.
> Ti viene fornito anche un servizio dns interno, quindi puoi sempre
> raggiungere un dispositivo anche tramite un nome dns simile a
> miopc.colorful-beluga.ts.net. Le connessioni sono peer-to-peer, come
> sarebbero in lan, quindi le prestazioni sono piuttosto buone.
>
> Per usarlo non ti serve aprire porte sul firewall.
>
> L'uso è gratuito per reti fino a 100 dispositivi e 3 utenti separati, non
> so se si applica al tuo caso. Il prezzo per una rete con più di 3 utenti è
> 6$ per utente al mese (ma i primi 3 utenti sono sempre gratis, quindi se ad
> esempio siete in 5 pagate 12$ al mese).
>
Credo di averla intravista, ma probabilmente non ho capito bene; la
riguarderò con più attenzione.

> saluti,
>
> gerlos
>
Grazie della segnalazione, ciao,
Giuliano

Re: VPN

[Giuliano Curti]

Il gio 28 dic 2023, 18:18 Leonardo Boselli  ha
scritto:

Ciao Leonardo, grazie;

Una domanda importantissima: gli utenti predefiniti si collegano sempre
> dallo stesso indirizzo, e lo usano solo loro ? perché se così fosse
> basterebbe un allow e a quel punto non ti chiede neppure la utenticazione.
>

Sì, gli utenti sarebbero sempre gli stessi; riguardo l'indirizzo non
saprei, si collegano da fuori quindi con indirizzi dinamici; scusa, forse
non ho capito bene.

>
> 
>

Aggiungo ancora un (o dei tanti) dubbio.
In questo momento ho aperto sul router la porta 22 per l'amministrazione
SSH e le porte 8080+ per la trasmissione web delle telecamere (1 per ogni
telecamera + 1 per l'applicativo).

Se instauro il tunnel SSH le porte 8080+ devono cmq rimanere aperte? In tal
caso il discorso risulterebbe vanificato perché il sistema continuerebbe a
trasmettere in chiaro su quelle porte; sono protette da user: password e da
fail2ban, ma il tunneling non mi porterebbe vantaggi, mentre ne avrebbe
parecchi se potessi chiuderle (come ho detto i dati non sono per nulla
sensibili, per me è semplicemente un'occasione per capire di più di reti e
sicurezza).

--
> Leonardo Boselli
> Firenze, Toscana, Europa


Grazie della vostra infinita pazienza, un saluto,
Giuliano

Re: VPN

[gerlos]

Il 26/12/23 18:57, Giuliano Curti ha scritto:

Ciao a tutti,

ho allestito, come credo di aver scritto tempo fa, un server per la 
gestione di videosorveglianza remota con motion su un rpi4B 
(raspberryPiOS32).

Il sistema trasmette in HTTP, protetto da FAIL2BAN, e sembra funzionare.

Poiché il servizio non ha funzionalità pubbliche volevo restringerne 
l'uso ai soli utenti abilitati.
Già ora la connessione è autorizzata con user:password, però pensavo 
che una trasmissione criptata a chiave asimmetrica potrebbe essere 
meglio (ad es. mi libererebbe dal digitare ad ogni connessione le 
credenziali per l'applicativo e per ogni telecamera).
Forse però  lo stimolo principale è l'occasione di conoscere ed 
applicare qualcosa di più avanzato in tema di sicurezza.



Per questo tipo di applicazioni al momento sto usando Tailscale (vedi 
https://tailscale.com/).


È un'implementazione di una rete mesh Wireguard, semplicissima da usare 
e ottimamente documentata. I client sono open source ed esistono per 
qualsiasi OS. Il backend server predefinito è closed, ma ne esiste 
un'implementazione open source che puoi mettere su un tuo sistema - ma 
se vuoi ottenere rapidamente risultati la cosa migliore è appoggiarti ai 
loro server.


Una volta che un tuo dispositivo si collega alla tua rete tailscale (in 
gergo "tailnet"), puoi raggiungerlo tramite un IP statico tipo 
100.x.y.z. Ti viene fornito anche un servizio dns interno, quindi puoi 
sempre raggiungere un dispositivo anche tramite un nome dns simile a 
miopc.colorful-beluga.ts.net. Le connessioni sono peer-to-peer, come 
sarebbero in lan, quindi le prestazioni sono piuttosto buone.


Per usarlo non ti serve aprire porte sul firewall.

L'uso è gratuito per reti fino a 100 dispositivi e 3 utenti separati, 
non so se si applica al tuo caso. Il prezzo per una rete con più di 3 
utenti è 6$ per utente al mese (ma i primi 3 utenti sono sempre gratis, 
quindi se ad esempio siete in 5 pagate 12$ al mese).


saluti,

gerlos

Re: VPN

[Leonardo Boselli]

Una domanda importantissima: gli utenti predefiniti si collegano sempre 
dallo stesso indirizzo, e lo usano solo loro ? perché se così fosse 
basterebbe un allow e a quel punto non ti chiede neppure la utenticazione.


On Wed, 27 Dec 2023, Giuliano Curti wrote:

Azzeccato, hai ragione :-)) uno degli "utenti predefiniti" sono io e posso 
presumere che, risolto la
prima volta, posso reiterare correttamente la stringa di connessione, ma 
dovessi autenticare moglie o
figlia per una cosa che riguarda anche loro il problema si porrebbe, a meno di 
risolvere con uno
script. Valuterò, grazie dell'avvertimento.


--
Leonardo Boselli
Firenze, Toscana, Europa

Re: VPN

[Giuliano Curti]

Il mer 27 dic 2023, 20:32  ha scritto:

> 27 dicembre 2023 alle ore 18:05, "Giuliano Curti"  >
> scrive:
>
>
> 
>
> Non sbagli pero' mi domando: chi deve usare l'http e' uno in grado di
> aprire una shell, digitare un ssh -L etc etc o preferisce qualcosa di piu'
> automatico: avvio connessione cliccando su una qualche icona, aprire il
> browser e accedere?
>

Azzeccato, hai ragione :-)) uno degli "utenti predefiniti" sono io e posso
presumere che, risolto la prima volta, posso reiterare correttamente la
stringa di connessione, ma dovessi autenticare moglie o figlia per una cosa
che riguarda anche loro il problema si porrebbe, a meno di risolvere con
uno script. Valuterò, grazie dell'avvertimento.

>
> Mauro
>

Ciao,
Giuliano

Re: VPN

[mauro]

27 dicembre 2023 alle ore 18:05, "Giuliano Curti"  scrive:



> 
> Ti ringrazio infinitamente per il tuo consiglio che valuterò; aggiungo però, 
> rettificando forse il tiro, che per i miei usi (criptare una trasmissione 
> HTTP per renderla fruibile solo ad utente/i predefinito/i) potrebbe bastare 
> un SSH Port forwarding.
> 
> Settando qualcosa tipo "SSH -L porta_locale remote.host:porta_remota" dovrei, 
> aprendo il browser su http:://localhost:porta_locale, vedere quello che il 
> web server del remote.host trasmette sulla porta_remota, o sbaglio?
> 
Non sbagli pero' mi domando: chi deve usare l'http e' uno in grado di aprire 
una shell, digitare un ssh -L etc etc o preferisce qualcosa di piu' automatico: 
avvio connessione cliccando su una qualche icona, aprire il browser e accedere?

> 
> 
> 

Mauro

> 
> 
>

Re: VPN

[Sergio Vi]

Uso wireguard per connettere piudispositivi in vpn (android, pc, nas) posso
scegliere per ogni utente se usare la pwd o meno e la creazione di un
qrcode per copiare la configuraxione per ognuno di loro

Il Mer 27 Dic 2023, 18:05 Giuliano Curti  ha scritto:

> Il mer 27 dic 2023, 17:04 mauro morichi  ha scritto:
>
> Ciao Mauro,
>
>>
>> Il 26/12/23 18:57, Giuliano Curti ha scritto:
>> > Fra le varie opzioni possibili mi è sembrato di individuare WIREGUARD
>> > .
>>
>>
>> Personalmente uso openvpn.
>>
>> .
>>
>> Rispetto a wireguard sicuramente lo studio e' un po' piu' complesso, ma
>> i risultati sono decisamente validi.
>>
>> my 5 cents
>>
>
> Ti ringrazio infinitamente per il tuo consiglio che valuterò; aggiungo
> però, rettificando forse il tiro, che per i miei usi (criptare una
> trasmissione HTTP per renderla fruibile solo ad utente/i predefinito/i)
> potrebbe bastare un SSH Port forwarding.
>
> Settando qualcosa tipo "SSH -L porta_locale remote.host:porta_remota"
> dovrei, aprendo il browser su http:://localhost:porta_locale, vedere quello
> che il web server del remote.host trasmette sulla porta_remota, o sbaglio?
>
> Mauro.
>>
>
> Grazie ancora, ciao,
> Giuliano
>
>

Re: VPN

[Giuliano Curti]

Il mer 27 dic 2023, 17:04 mauro morichi  ha scritto:

Ciao Mauro,

>
> Il 26/12/23 18:57, Giuliano Curti ha scritto:
> > Fra le varie opzioni possibili mi è sembrato di individuare WIREGUARD
> > .
>
>
> Personalmente uso openvpn.
>
> .
>
> Rispetto a wireguard sicuramente lo studio e' un po' piu' complesso, ma
> i risultati sono decisamente validi.
>
> my 5 cents
>

Ti ringrazio infinitamente per il tuo consiglio che valuterò; aggiungo
però, rettificando forse il tiro, che per i miei usi (criptare una
trasmissione HTTP per renderla fruibile solo ad utente/i predefinito/i)
potrebbe bastare un SSH Port forwarding.

Settando qualcosa tipo "SSH -L porta_locale remote.host:porta_remota"
dovrei, aprendo il browser su http:://localhost:porta_locale, vedere quello
che il web server del remote.host trasmette sulla porta_remota, o sbaglio?

Mauro.
>

Grazie ancora, ciao,
Giuliano

Re: VPN

[mauro morichi]

Il 26/12/23 18:57, Giuliano Curti ha scritto:
Fra le varie opzioni possibili mi è sembrato di individuare WIREGUARD 
come lo strumento adatto.
Prima di tuffarmi nella lettura e nella configurazione mi piaceva 
avere il conforto della vostra opinione (che tornerò a sollecitare per 
i dettagli pratici).



Personalmente uso openvpn.

in primo luogo puoi configurare la connessione sia per computer che per 
altri device (android,osx, iphone) di client ce ne sono a iosa,


inoltre, oltre a poter configurare il tutto fornendo un file di 
configurazione con dentro tutto (quindi basta attivare la connessione 
dal pc e la connessione va da se), puoi anche optare per la richiesta 
username e password.


inoltre, cosa comoda, aggiungendo un dns come dnsmasq (molto semplice da 
configurare) puoi offrire al client la possibilita' di digitare un nome 
anziche' un indirizzo ip per collegarsi al tuo server http.


Rispetto a wireguard sicuramente lo studio e' un po' piu' complesso, ma 
i risultati sono decisamente validi.


my 5 cents

Mauro.

VPN

[Giuliano Curti]

Ciao a tutti,

ho allestito, come credo di aver scritto tempo fa, un server per la
gestione di videosorveglianza remota con motion su un rpi4B
(raspberryPiOS32).
Il sistema trasmette in HTTP, protetto da FAIL2BAN, e sembra funzionare.

Poiché il servizio non ha funzionalità pubbliche volevo restringerne l'uso
ai soli utenti abilitati.
Già ora la connessione è autorizzata con user:password, però pensavo che
una trasmissione criptata a chiave asimmetrica potrebbe essere meglio (ad
es. mi libererebbe dal digitare ad ogni connessione le credenziali per
l'applicativo e per ogni telecamera).
Forse però  lo stimolo principale è l'occasione di conoscere ed applicare
qualcosa di più avanzato in tema di sicurezza.

Fra le varie opzioni possibili mi è sembrato di individuare WIREGUARD come
lo strumento adatto.
Prima di tuffarmi nella lettura e nella configurazione mi piaceva avere il
conforto della vostra opinione (che tornerò a sollecitare per i dettagli
pratici).

Grazie, saluti ed auguri per le correnti festività,
Giuliano

Re: Fail2ban e Openssl (era: Vlan, debian, VPN, zoneminder)

[Giuliano Curti]

Il dom 17 ott 2021, 00:04 Paride Desimone  ha scritto:

Ciao Paride, grazie del suggerimento;

Il 05-10-2021 10:23 Giuliano Curti ha scritto:
> > Il lun 4 ott 2021, 22:04 Mauro  ha scritto:
> >
> >> .
> >
> > Riassumo, senza ripetere, le domande che avevo posto:
> > 1) la disabilitazione dell'accesso per password rende SSH
> > .
>
> Te la butto lì. E se a ssh ci affiancassi una VPN?
>

Francamente era l'idea di partenza, ma la rete per me è un terreno
sconosciuto ed ogni passo in più è terribilmente faticoso.
Dovrei aver chiuso SSH accettando solo connessioni con chiave; ho messo
fail2ban a guardia con le regole di default su SSHD e con una regola
autocostruita per MOTION che mi dovrebbero tenere al riparo da attacchi
brute force.
Al momento ho rinunciato ad attivare OpenSSL perché l'impressione che ho
avuto è che MOTION se ne serve solo per autenticare il server, non il
client (studierò il reverse proxy tramite apache/nginxcome suggerito da
qualcuno).
Se non ci sono problemi particolarmente critici sperimenterei così, senza
disdegnare ovviamente miglioramenti futuri quando avrò una maggiore
padronanza della rete.


Paride


Grazie, ciao,
Giuliano


>

Re: Fail2ban e Openssl (era: Vlan, debian, VPN, zoneminder)

[Paride Desimone]

Il 05-10-2021 10:23 Giuliano Curti ha scritto:

Il lun 4 ott 2021, 22:04 Mauro  ha scritto:


.


Riassumo, senza ripetere, le domande che avevo posto:
1) la disabilitazione dell'accesso per password rende SSH 
ragionevolmente

sicuro?
2) l'uso di SSL/TLS rende ragionevolmente sicura la connessione alle 
porte

di pmotion e telecamerep?
con "ragionevolmente sicuro" intendo che possa fare a meno di 
fail2ban-)


Te la butto lì. E se a ssh ci affiancassi una VPN?

Paride

--
http://keys.gnupg.net/pks/lookup?op=get=0xCC6CA35C690431D3

Chi e' pronto a rinunciare alle proprie liberta' fondamentali per 
comprarsi briciole di temporanea sicurezza non merita ne' la liberta' 
ne' la sicurezza.(Benjamin Franklin - dalla Risposta al Governatore, 
Assemblea della Pennsylvania, 11 novembre 1755)

Re: Fail2ban e Openssl (era: Vlan, debian, VPN, zoneminder)

[Giuliano Curti]

..oopss sul primo punto mi rispondo da solo

Il ven 8 ott 2021, 23:11 Giuliano Curti  ha scritto:

> ...
>
> On 10/6/21, Diego Zuccato  wrote:
> > Il 06/10/2021 11:16, Giuliano Curti ha scritto:
> > 
>
> ho fatto una prova (in locale) e sembra funzionare, solo però per la porta
> del webcontrol di motion, non riesco a reindirizzare le porte delle
> telecamere, ammesso sia possibile;
>

ho visto che nella stessa istruzione si possono reindirizzare più porte;
vedrò se questo risolve il problema.

Chiedo scusa dell'inutile disturbo, grazie, saluti,
Giuliano

Re: Fail2ban e Openssl (era: Vlan, debian, VPN, zoneminder)

[Giuliano Curti]

Ciao a tutti,

scusate se riprendo questo discorso, ma nel mio faticoso viaggio nelle reti
ogni tanto mi imbatto in qualche ostacolo ostico;

ho deciso di sperimentare, prima di approcciare il reverse proxy, il
tunneling SSH, come suggerito da

On 10/6/21, Diego Zuccato  wrote:
> Il 06/10/2021 11:16, Giuliano Curti ha scritto:
>
> ...
>
> . Inizia quindi pensando a cosa ti serve fare e a quanto
> vuoi che sia comodo. P.e. se devi solo poter accedere *tu* da remoto
> alle telecamere, ti conviene esporre solo il servizio SSH. Quando vuoi
> vedere qualcosa, ti colleghi via SSH (che ti autentica con la tua
> chiave) e apri un tunnel ("-L localport:remotehost:remoteport") per
> poter accedere a remotehost:remoteport collegandoti a localhost:localport.
> Non è il massimo della comodità, però un malintenzionato dovrebbe poter
> bucare ssh, che è molto più blindato (credo e spero :) ) di ogni altro
> servizio che si possa far girare...

ho fatto una prova (in locale) e sembra funzionare, solo però per la porta
del webcontrol di motion, non riesco a reindirizzare le porte delle
telecamere, ammesso sia possibile;

ho provato anche a reindirizzare le porte delle una camere una alla volta,
ma purtroppo qui il metodo fallisce, non riesco a visualizzare lo stream
della camera: non capisco quale sia la differenza che rende possibile uno e
impossibile l'altro.

Ho fatto anche un altro esperimento: ho fatto l'X forwarding e riesco a
lanciare il browser di rPi4 e vedo tutto (finora ho sperimentato in
locale); per metterlo a regime dovrò installare un X server su Android e
iOS; pensate sia una soluzione praticabile? Avete suggerimenti su Xserver
da installare nei due casi?

O forse è meglio che mi oriento subito sul reverse proxy che suggeriva
qualcuno?

spero di aver formulato con chiarezza contesto e quesiti; grazie
dell'attenzione, saluti,
giuliano

Re: Fail2ban e Openssl (era: Vlan, debian, VPN, zoneminder)

[Piviul]

Il 08/10/21 09:31, Diego Zuccato ha scritto:
Neanche io ho mai fatto particolari modifiche, se non le poche 
necessarie per l'installazione di ISPConfig.


Un problema che può essere grosso col setup di default è se si deve 
dare accesso ad un server "pubblico" da un laboratorio nattato. Se ci 
sono diversi utenti correttamente collegati e qualche studente 
ritardatario sbaglia la pass (anche se non è sempre lo stesso), 
vengono tutti butati fuori. E se non si pensa al NAT si perdono ore a 
cercare un problema inesistente. Chissà come l'ho scoperto... :)


Capisco il problema ma diciamo che sia un caso moolto particolare; certo 
lui banna l'ip e se molti utenti accedono con lo stesso ip basta che 
venga bannato uno perché siano bannati tutti... è coerente.


Comunque grazie Diego per aver chiarito e ribadisco che fail2ban sia un 
bel progetto, semplice ed efficace.


Un saluto

Piviul

Re: Fail2ban e Openssl (era: Vlan, debian, VPN, zoneminder)

[Diego Zuccato]

Neanche io ho mai fatto particolari modifiche, se non le poche 
necessarie per l'installazione di ISPConfig.


Un problema che può essere grosso col setup di default è se si deve dare 
accesso ad un server "pubblico" da un laboratorio nattato. Se ci sono 
diversi utenti correttamente collegati e qualche studente ritardatario 
sbaglia la pass (anche se non è sempre lo stesso), vengono tutti butati 
fuori. E se non si pensa al NAT si perdono ore a cercare un problema 
inesistente. Chissà come l'ho scoperto... :)


Il 07/10/2021 20:42, Piviul ha scritto:

Il 04/10/21 22:04, Mauro ha scritto:
non esattamente. Fail2ban si presenta con una sfilza di filtri da 
paura, ma poi va tarato per le proprie necessita', altrimenti 
garantisco che le rogne sono superiori ai benefici.
io l'ho sempre usato e non ho mai toccato nulla se non creato alcune 
jail per servizi non gestiti da fail2ban e non ho mai avuto alcun minimo 
problema. Certo, se uno sbaglia la password per non ricordo quante volte 
(3/5?) viene bannato per un certo numero di minuti (5/10?) che aumentano 
mano a mano che vengono aumentati i fails log. Ad esser sincero non vedo 
nemmeno quali rogne si debbano incontrare...


Piviul



--
Diego Zuccato
DIFA - Dip. di Fisica e Astronomia
Servizi Informatici
Alma Mater Studiorum - Università di Bologna
V.le Berti-Pichat 6/2 - 40127 Bologna - Italy
tel.: +39 051 20 95786

Re: Fail2ban e Openssl (era: Vlan, debian, VPN, zoneminder)

[Piviul]

Il 07/10/21 20:48, Davide Prina ha scritto:

dipende da cosa intendi per esporre
# netstat -putan
mi dice che non c'è nulla in ascolto su quella porta

Se faccio partire sshd
# systemctl start ssh

poi la c'è sshd in ascolto sulla porta 22

Ma comunque non doveva indicarmi anche quali IP aveva bloccato? Invece 
non c'è nessun IP con il comando:

# fail2ban-client status sshd
esposto intendo se la porta 22 è raggiungibile da Internet. Se non è 
raggiungibile ovviamente non ci possono nemmeno essere tentativi di 
accesso e ip bloccati... a meno di avere qualcuno in LAN di poco 
affidabile...


Piviul

Re: Fail2ban e Openssl (era: Vlan, debian, VPN, zoneminder)

[Piviul]

Il 04/10/21 22:04, Mauro ha scritto:
non esattamente. Fail2ban si presenta con una sfilza di filtri da 
paura, ma poi va tarato per le proprie necessita', altrimenti 
garantisco che le rogne sono superiori ai benefici.
io l'ho sempre usato e non ho mai toccato nulla se non creato alcune 
jail per servizi non gestiti da fail2ban e non ho mai avuto alcun minimo 
problema. Certo, se uno sbaglia la password per non ricordo quante volte 
(3/5?) viene bannato per un certo numero di minuti (5/10?) che aumentano 
mano a mano che vengono aumentati i fails log. Ad esser sincero non vedo 
nemmeno quali rogne si debbano incontrare...


Piviul

Re: Fail2ban e Openssl (era: Vlan, debian, VPN, zoneminder)

[Davide Prina]

On 07/10/21 20:36, Piviul wrote:

Il 07/10/21 20:10, Davide Prina ha scritto:

[...]
ma in /var/log/auth.log non vi è neanche una riga relativa ad un 
accesso ssh alla macchina...

ma il pc espone la porta 22 in internet?


dipende da cosa intendi per esporre
# netstat -putan
mi dice che non c'è nulla in ascolto su quella porta

Se faccio partire sshd
# systemctl start ssh

poi la c'è sshd in ascolto sulla porta 22

Ma comunque non doveva indicarmi anche quali IP aveva bloccato? Invece 
non c'è nessun IP con il comando:

# fail2ban-client status sshd

Ciao
Davide
--
Esci dall'illegalità: utilizza LibreOffice/OpenOffice:
http://linguistico.sf.net/wiki/doku.php?id=usaooo
Non autorizzo la memorizzazione del mio indirizzo su outlook

Re: Fail2ban e Openssl (era: Vlan, debian, VPN, zoneminder)

[Piviul]

Il 07/10/21 20:10, Davide Prina ha scritto:

[...]
ma in /var/log/auth.log non vi è neanche una riga relativa ad un 
accesso ssh alla macchina...

ma il pc espone la porta 22 in internet?

Piviul

Re: Fail2ban e Openssl (era: Vlan, debian, VPN, zoneminder)

[Davide Prina]

On 04/10/21 22:04, Mauro wrote:


On 04/10/21 21:37, Davide Prina wrote:


ma file2ban dovrebbe essere sufficiente installarlo



non esattamente. Fail2ban si presenta con una sfilza di filtri da paura, 
ma poi va tarato per le proprie necessita', altrimenti garantisco che le 
rogne sono superiori ai benefici.


io lo sto usando su PC ad uso desktop, per ora non ho notato problemi, o 
per lo meno, non mi sono accorto che eventuali problematiche avute erano 
causa sua. Per questo avevo detto così...


guardando ora (ho guardato il man/l'help in questo momento)
$ zgrep Jail /var/log/fail2ban.log*
[...]
[...] fail2ban.jail [762]: INFOJail 'sshd' uses pyinotify {}
[...] fail2ban.jail [762]: INFOJail 'sshd' started
[...] fail2ban.jail [762]: INFOJail 'sshd' stopped
[...]

se interpreto correttamente sembra che mi metta costantemente in jail sshd

Strano perché io mi ricordavo di averlo disabilitato, in modo da averlo 
installato e poterlo avviare alla bisogna.


Infatti
$ systemctl status ssh
mi dice che è disabilitato

# fail2ban-client status
Status
|- Number of jail:  1
`- Jail list:   sshd

# fail2ban-client status sshd
Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  |- Total failed: 0
|  `- File list:/var/log/auth.log
`- Actions
   |- Currently banned: 0
   |- Total banned: 0
   `- Banned IP list:   

ma in /var/log/auth.log non vi è neanche una riga relativa ad un accesso 
ssh alla macchina...


Ma i comandi che ho dato sono corretti per verificare ciò che è stato 
messo in ban?


Appena posso proverò a guardare l'altro PC su cui l'ho installato

Ciao
Davide
--
Database: http://www.postgresql.org
GNU/Linux User: 302090: http://counter.li.org
Non autorizzo la memorizzazione del mio indirizzo su outlook

Re: Fail2ban e Openssl (era: Vlan, debian, VPN, zoneminder)

[Giuliano Curti]

Il gio 7 ott 2021, 08:16 MAURIZI Lorenzo  ha
scritto:

>  ...
>
> È proprio l'autenticazione del client che mi interessa; non hai qualche
> hint per poter indirizzare in modo produttivo la mia lettura?
>
>
>
> Su questo punto non sono molto preparato, non mi è mai capitato di dover
> implementare una autenticazione del genere.
>
> Però qui, secondo me, esce anche un’altra questione: l’autenticazione deve
> anche arrivare all’applicazione, in modo da rilevare chi è che si collega e
> dare le giuste autorizzazioni a quel tale utente.
> ..
>
> si mette davanti a Motion un server web (Apache, nginx) che fa da reverse
> proxy, si configura per fare autenticazione con certificato, poi viene
> presentata l’autenticazione di motion e lì si dovrà fare un altro login con
> user e password.
>
..azz... L'affare si complica; verrebbe da dire "piatto ricco, mi ci
ficco", ma non sono un pockerista 

 Questa potrebbe essere una guida per configurare l’autenticazione SSL in
> Apache:
> http://www.stefanocapitanio.com/configuring-two-way-authentication-ssl-with-apache/
>
> Oppure per nginx:
> https://www.ssltrust.com.au/help/setup-guides/client-certificate-authentication
>
>  Ciao da Lorenzo
>

Grazie infinite Lorenzo; appena in grado seguirò le tue indicazioni, ciao,
Giuliano

>

R: Fail2ban e Openssl (era: Vlan, debian, VPN, zoneminder)

[MAURIZI Lorenzo]

Ciao Lorenzo, grazie;



 ...

• Autenticazione del client più crittografia della comunicazione con il 
server web

.

Spero di aver risposto al tuo dubbio e di non avere detto inesattezze e/o cose 
inutili, o già note, il che significherebbe che non ho capito la domanda :-P

È proprio l'autenticazione del client che mi interessa; non hai qualche hint 
per poter indirizzare in modo produttivo la mia lettura?

Su questo punto non sono molto preparato, non mi è mai capitato di dover 
implementare una autenticazione del genere.
Però qui, secondo me, esce anche un’altra questione: l’autenticazione deve 
anche arrivare all’applicazione, in modo da rilevare chi è che si collega e 
dare le giuste autorizzazioni a quel tale utente.
Quindi significa che l’autenticazione basata su certificati deve essere 
supportata anche dall’applicazione. Se Motion supporta solo l’autenticazione 
tramite user e password, lo scenario potrebbe essere:
si mette davanti a Motion un server web (Apache, nginx) che fa da reverse 
proxy, si configura per fare autenticazione con certificato, poi viene 
presentata l’autenticazione di motion e lì si dovrà fare un altro login con 
user e password.

Questa potrebbe essere una guida per configurare l’autenticazione SSL in 
Apache: 
http://www.stefanocapitanio.com/configuring-two-way-authentication-ssl-with-apache/
Oppure per nginx: 
https://www.ssltrust.com.au/help/setup-guides/client-certificate-authentication

Ciao da Lorenzo

Re: Fail2ban e Openssl (era: Vlan, debian, VPN, zoneminder)

[Giuliano Curti]

Il mer 6 ott 2021, 13:29 Diego Zuccato  ha scritto:

Ciao Diego, grazie;

Il 06/10/2021 11:16, Giuliano Curti ha scritto:
>
> ...
> > user:passwd o con TLS.
> Opinione personale: lascia perdere user+pass e punta solo su TLS.
>

Bene, terrò presente.
Aggiungo, correggendo quando detto prima, che MOTION consente anche
l'autenticazione MD5 Digest;

> . fosse così
> > lascerei perdere perché non è questo il mio obbiettivo e un
> > malintenzionato non sarebbe assolutamente interessato a sapere se il mio
> > server è autenticato o meno.
> Dipende cosa intendi per sicurezza. SSL cripta le connessioni, permette
> di garantire che le parti sono chi dicono di essere e che i pacchetti
> non sono stati alterati in transito.
>

Penso sia la prima parte che mi interessa: la garanzia che le parti, in
particolare il client, sono chi dicono di essere mi dovrebbe mettere al
sicuro da malintenzionati; mi sembra quello che diceva Lorenzo, devo capire
dove approfondire;

Chiaramente, se esponi un servizio insicuro (p.e. che permette
> esecuzione di codice arbitrario da parte di un utente non autenticato)
> questo rimarrà insicuro.
>

Questi lo capisco, ma questo dipende dalla qualità dell'applicativo
(MOTION); io temo di poter fare poco;

. Inizia quindi pensando a cosa ti serve fare e a quanto
> vuoi che sia comodo. P.e. se devi solo poter accedere *tu* da remoto
> alle telecamere, ti conviene esporre solo il servizio SSH. Quando vuoi
> vedere qualcosa, ti colleghi via SSH (che ti autentica con la tua
> chiave) e apri un tunnel ("-L localport:remotehost:remoteport") per
> poter accedere a remotehost:remoteport collegandoti a localhost:localport.
> Non è il massimo della comodità, però un malintenzionato dovrebbe poter
> bucare ssh, che è molto più blindato (credo e spero :) ) di ogni altro
> servizio che si possa far girare...
>

Grazie di questa indicazione; non la conosco, cercherò di approfondire.
Intanto ho disabilitato la connessione con password;


Diego Zuccato


Grazie, ciao,
Giuliano

>
>

Re: Fail2ban e Openssl (era: Vlan, debian, VPN, zoneminder)

[Giuliano Curti]

Il mer 6 ott 2021, 12:05 MAURIZI Lorenzo  ha
scritto:

Ciao Lorenzo, grazie;


 ...

· Autenticazione del client più crittografia della comunicazione
con il server web

.

Spero di aver risposto al tuo dubbio e di non avere detto inesattezze e/o
cose inutili, o già note, il che significherebbe che non ho capito la
domanda :-P

È proprio l'autenticazione del client che mi interessa; non hai qualche
hint per poter indirizzare in modo produttivo la mia lettura?

Grazie infinite, ciao,
Giuliano

Re: Fail2ban e Openssl (era: Vlan, debian, VPN, zoneminder)

[Diego Zuccato]

Il 06/10/2021 11:16, Giuliano Curti ha scritto:

Arrivo solo ora, ma spero di poter essere utile.

L'autenticazione può essere fatta in due modi: o con la copia 
user:passwd o con TLS.

Opinione personale: lascia perdere user+pass e punta solo su TLS.

Approfitto per una domanda su openSSL che era il mio oggetto di studio 
attuale; dal poco che ho letto ho il dubbio che openSSL miri a garantire 
l'autenticità del server, non alla sicurezza del sistema; fosse così 
lascerei perdere perché non è questo il mio obbiettivo e un 
malintenzionato non sarebbe assolutamente interessato a sapere se il mio 
server è autenticato o meno.
Dipende cosa intendi per sicurezza. SSL cripta le connessioni, permette 
di garantire che le parti sono chi dicono di essere e che i pacchetti 
non sono stati alterati in transito.
Chiaramente, se esponi un servizio insicuro (p.e. che permette 
esecuzione di codice arbitrario da parte di un utente non autenticato) 
questo rimarrà insicuro.
Se invece l'unica vulnerabilità (nota) del servizio è relativa al 
passaggio delle credenziali o alla possibilità che qualcuno modifichi i 
dati in transito, allora SSL ti aiuta molto.


Sono cresciuto con il "personal" computer, nel vero senso della parola; 
ora mi trovo spaesato con le reti, che non conosco, e soprattutto la 
sicurezza;

Sei in ottima compagnia :)

tutto il thread è la traccia del mio tentativo di risalire la china.
I miei dati, immagini e foto di una casa di campagna non sono 
importanti, quindi sono poco interessato a soluzioni di crittografia del 
traffico; sono piuttosto interessato a far si che il mio sistema non 
possa essere utilizzato per attività malevole da terzi.
Una possibilità, molto drastica ma sicura, è non esporre nulla: tieni il 
sistema isolato e non sarà utile per attività malevole. Ma probabilmente 
neppure a te... Inizia quindi pensando a cosa ti serve fare e a quanto 
vuoi che sia comodo. P.e. se devi solo poter accedere *tu* da remoto 
alle telecamere, ti conviene esporre solo il servizio SSH. Quando vuoi 
vedere qualcosa, ti colleghi via SSH (che ti autentica con la tua 
chiave) e apri un tunnel ("-L localport:remotehost:remoteport") per 
poter accedere a remotehost:remoteport collegandoti a localhost:localport.
Non è il massimo della comodità, però un malintenzionato dovrebbe poter 
bucare ssh, che è molto più blindato (credo e spero :) ) di ogni altro 
servizio che si possa far girare...


--
Diego Zuccato
DIFA - Dip. di Fisica e Astronomia
Servizi Informatici
Alma Mater Studiorum - Università di Bologna
V.le Berti-Pichat 6/2 - 40127 Bologna - Italy
tel.: +39 051 20 95786

R: Fail2ban e Openssl (era: Vlan, debian, VPN, zoneminder)

[MAURIZI Lorenzo]

Approfitto per una domanda su openSSL che era il mio oggetto di studio attuale; 
dal poco che ho letto ho il dubbio che openSSL miri a garantire l'autenticità 
del server, non alla sicurezza del sistema; fosse così lascerei perdere perché 
non è questo il mio obbiettivo e un malintenzionato non sarebbe assolutamente 
interessato a sapere se il mio server è autenticato o meno.

In teoria SSL/TLS over http (quindi HTTPS) può essere usato in due modi:

· Solo crittografia della comunicazione tra client e server web

· Autenticazione del client più crittografia della comunicazione con il 
server web

Per evitare che regni l’anarchia, i certificati “ufficiali” sono rilasciati da 
delle autorità di certificazione note e inserite nel “truststore” dei browser 
web. Questo per evitare che chiunque, con openssl, possa creare un certificato 
fasullo di un sito noto e lo usi per truffare la gente (ad esempio con DNS 
poisoning). Quindi sì, oltre alla crittografia il certificato SSL, rilasciato 
da una Certification Authority nota e “trustata”, garantisce che il server è 
chi dice di essere.
Nulla vieta, comunque, per cose fatte in casa, di autogenerarsi un certificato 
con OpenSSL e inserirlo nella configurazione del webserver (vedi il certificato 
snakeoil presente in Debian). Avrai dei warning da parte del browser di 
certificato rilasciato da fonte non autorevole, che ignorerai bellamente. Al 
limite puoi “trustare” nel tuo browser la Certification Authority casalinga che 
rilascia il certificato autogenerato, evitando il warning di sicurezza.

Spero di aver risposto al tuo dubbio e di non avere detto inesattezze e/o cose 
inutili, o già note, il che significherebbe che non ho capito la domanda :-P

Saluti da Lorenzo

Re: Fail2ban e Openssl (era: Vlan, debian, VPN, zoneminder)

[Giuliano Curti]

Il mar 5 ott 2021, 18:47 Piviul  ha scritto:

Ciao Piviul,
grazie della risposta (in coda un chiarimento del contesto).

Il 04/10/21 19:19, Giuliano Curti ha scritto:
> > Potrei risolvere la parte motion / telecamere con openssl perché
> > motion gestisce sia il webcontrol che le stream con modalità TLS: vi
> > sembra una soluzione adatta?
> > Su openssl ...
> >
> Ciao Giuliano, non conosco l'argomento motion, cam ip ecc...


Se vuoi ti dico brevemente cosa fa motion, poi cmq saltare a piè pari.
Motion contiene un mini server web che trasmette una pagina di controllo
(default porta 8080) ed il flusso video di ogni telecamera su una porta
dedicata (tipicamente 8081, 8082, ecc.).

 ma fail2ban
> un po' si. Il problema è l'autenticazione: chi si occupa
> dell'autenticazione? Motion tramite TLS? Ma se un utente fallisce
> l'autenticazione in quale file di log, motion o chi per lui, scrive il
> tentativo fallito? Una volta che lo hai

..
> Più o meno il processo è quello quindi come prima cosa devi scoprire in
> quale file di log vengono scritti i failing auth.
>

L'autenticazione può essere fatta in due modi: o con la copia user:passwd o
con TLS.
MOTION ha un file di log (/bar/log/motion.log) e dovrò controllare lì
quello che dici.

Approfitto per una domanda su openSSL che era il mio oggetto di studio
attuale; dal poco che ho letto ho il dubbio che openSSL miri a garantire
l'autenticità del server, non alla sicurezza del sistema; fosse così
lascerei perdere perché non è questo il mio obbiettivo e un malintenzionato
non sarebbe assolutamente interessato a sapere se il mio server è
autenticato o meno.

Spero di esser stato chiaro


Piviul


Sei stato chiarissimo e ti ringrazio, ciao,
Giuliano
---
Sono cresciuto con il "personal" computer, nel vero senso della parola; ora
mi trovo spaesato con le reti, che non conosco, e soprattutto la sicurezza;
tutto il thread è la traccia del mio tentativo di risalire la china.
I miei dati, immagini e foto di una casa di campagna non sono importanti,
quindi sono poco interessato a soluzioni di crittografia del traffico; sono
piuttosto interessato a far si che il mio sistema non possa essere
utilizzato per attività malevole da terzi.

Re: Fail2ban e Openssl (era: Vlan, debian, VPN, zoneminder)

[Piviul]

Il 04/10/21 19:19, Giuliano Curti ha scritto:
Potrei risolvere la parte motion / telecamere con openssl perché 
motion gestisce sia il webcontrol che le stream con modalità TLS: vi 
sembra una soluzione adatta?
Su openssl devo studiare tutto, quindi tornerò a chiedere consigli, ma 
intanto mi chiedevo se è una strada ragionevole da percorrere o una 
cavolata.


Ciao Giuliano, non conosco l'argomento motion, cam ip ecc... ma fail2ban 
un po' si. Il problema è l'autenticazione: chi si occupa 
dell'autenticazione? Motion tramite TLS? Ma se un utente fallisce 
l'autenticazione in quale file di log, motion o chi per lui, scrive il 
tentativo fallito? Una volta che lo hai scoperto poi devi analizzare la 
riga relativa al failing log e devi trovare una espressione regolare per 
riconoscerla e per identificare l'ip del pc da cui è partita 
l'autenticazione; se non ricordo male quando hai queste informazioni 
devi creare una nuova jail con questi valori e a questo punto fail2ban 
sa contare quanti tentativi sono stati fatti e banna dopo un certo 
numero di tentativi falliti l'ip che li ha prodotti per un certo periodo 
di tempo.


Più o meno il processo è quello quindi come prima cosa devi scoprire in 
quale file di log vengono scritti i failing auth.


Spero di esser stato chiaro

Piviul

Re: Fail2ban e Openssl (era: Vlan, debian, VPN, zoneminder)

[Giuliano Curti]

Il mar 5 ott 2021, 15:58 Mario Vittorio Guenzi  ha
scritto:

> Buongiorno
>
> ..


Lorenzo e Mario Vittorio, grazie dei vostri suggerimenti, mi serviranno per
approfondire l'argomento.

Ciao,
Giuliano

R: Fail2ban e Openssl (era: Vlan, debian, VPN, zoneminder)

[MAURIZI Lorenzo]

Ciao,
fail2ban su SSH lo lascerei solo per bloccare chi fa tentativi e quindi, una 
volta bannato, rifiutare le connessioni da quell’IP senza neanche fare attivare 
la risposta del daemon SSH.

Capisco che implementare fail2ban sul collegamento https potrebbe essere 
difficoltoso. Però se il log dell’applicativo web che gestisce l’autenticazione 
è facile da interpretare, una regular expression che becchi il fallimento si 
può inventare.
Pare che Motion abbia implementato i log sul failed logon un po’ di tempo fa:
https://github.com/Motion-Project/motion/issues/348
https://github.com/Motion-Project/motion/pull/434

Chiedo scusa se queste cose sono state già dette, mi sono sicuramente perso dei 
pezzi.
Ciao da Lorenzo



Da: Giuliano Curti 
Inviato: martedì 5 ottobre 2021 12:24
A: debian-italian 
Oggetto: Re: Fail2ban e Openssl (era: Vlan, debian, VPN, zoneminder)

Il lun 4 ott 2021, 22:04 Mauro mailto:ma...@teppisti.it>> ha 
scritto:

On 04/10/21 21:37, Davide Prina wrote:
>
> ma file2ban dovrebbe essere sufficiente installarlo


non esattamente. Fail2ban si presenta con una sfilza di filtri da paura,


Ciao Davide e Mauro,

grazie delle risposte;

Mauro ha chiarito i limiti e le difficoltà di fail2ban.

Aggiungo per Davide che l'oggetto è la sicurezza di un sistema di 
videosorveglianza (abbastanza naif e basato sul solo motion);
ho previsto l'apertura della porta 22 per l'amministrazione del sistema via 
SSH, occorre poi aprire le porte per l'uso di motion, una per il webcontrol (un 
controllo limitato dei parametri di motion) ed una per ogni telecamera.

Ovviamente i dati (visualizzazione di un paio di prati) non hanno alcuna 
importanza e segretezza, sono più che altro un pretesto per farmi approfondire 
i temi della rete e della sicurezza; l'unica cosa fastidiosa sarebbe l'uso 
della mia macchina per attività criminose.

Riassumo, senza ripetere, le domande che avevo posto:
1) la disabilitazione dell'accesso per password rende SSH ragionevolmente 
sicuro?
2) l'uso di SSL/TLS rende ragionevolmente sicura la connessione alle porte di 
pmotion e telecamerep?
con "ragionevolmente sicuro" intendo che possa fare a meno di fail2ban.

Grazie, ciao,
Giuliano

PS: ho qualche problema su openssl; mi sa che tornerò all'attacco :-)

Re: Fail2ban e Openssl (era: Vlan, debian, VPN, zoneminder)

[Giuliano Curti]

Il lun 4 ott 2021, 22:04 Mauro  ha scritto:

>
> On 04/10/21 21:37, Davide Prina wrote:
> >
> > ma file2ban dovrebbe essere sufficiente installarlo
>
>
> non esattamente. Fail2ban si presenta con una sfilza di filtri da paura,
> 


Ciao Davide e Mauro,

grazie delle risposte;

Mauro ha chiarito i limiti e le difficoltà di fail2ban.

Aggiungo per Davide che l'oggetto è la sicurezza di un sistema di
videosorveglianza (abbastanza naif e basato sul solo motion);
ho previsto l'apertura della porta 22 per l'amministrazione del sistema via
SSH, occorre poi aprire le porte per l'uso di motion, una per il webcontrol
(un controllo limitato dei parametri di motion) ed una per ogni telecamera.

Ovviamente i dati (visualizzazione di un paio di prati) non hanno alcuna
importanza e segretezza, sono più che altro un pretesto per farmi
approfondire i temi della rete e della sicurezza; l'unica cosa fastidiosa
sarebbe l'uso della mia macchina per attività criminose.

Riassumo, senza ripetere, le domande che avevo posto:
1) la disabilitazione dell'accesso per password rende SSH ragionevolmente
sicuro?
2) l'uso di SSL/TLS rende ragionevolmente sicura la connessione alle porte
di pmotion e telecamerep?
con "ragionevolmente sicuro" intendo che possa fare a meno di fail2ban.

Grazie, ciao,
Giuliano

PS: ho qualche problema su openssl; mi sa che tornerò all'attacco :-)

Re: Fail2ban e Openssl (era: Vlan, debian, VPN, zoneminder)

[Mauro]

On 04/10/21 21:37, Davide Prina wrote:


ma file2ban dovrebbe essere sufficiente installarlo



non esattamente. Fail2ban si presenta con una sfilza di filtri da paura, 
ma poi va tarato per le proprie necessita', altrimenti garantisco che le 
rogne sono superiori ai benefici.


il suo funzionamento e' semplice: controlla che che passa nei log, in 
base a una serie di regex  verifica chi fa il cattivo e superata la 
soglia indicata lo mette in punizione, bannandolo o segnalandolo.


Proprio il passaggio delle regole di filtro insieme al tempo di ban sono 
critiche perche' se iniziano i falsi positivi o se le maglie sono troppo 
strette le soprese diventano interessanti.



M.

Re: Fail2ban e Openssl (era: Vlan, debian, VPN, zoneminder)

[Davide Prina]

On 04/10/21 19:19, Giuliano Curti wrote:


come da consiglio di Giancarlo ho installato fail2ban; mi sto documentando
un po' e spero di configurarlo quanto prima;


ma file2ban dovrebbe essere sufficiente installarlo, poi si occupa lui 
di chiudere fuori, temporaneamente, gli indirizzi che fanno troppi tentativi



Ho pensato però un'altra soluzione e volevo sentire i vostri consigli: la
configurazione di SSH per lavorare con chiavi senza password non
risolverebbe il problema?


non ho seguito tutto il discorso e forse non ho capito quale sia il 
problema.
Usando una coppia di chiavi pubblica/privata puoi impostarlo per avere, 
ad esempio, l'accesso da remoto direttamente.



reputo difficile per un eventuale malintenzionato
scoprire la chiave o sbaglio?


se entrambi i sistemi sono sicuri e non accessibili dall'attaccante è 
difficile indovinare la chiave privata... naturalmente dipende 
dall'algoritmo usato, dalla lunghezza della chiave, di come viene 
utilizzato, ...


Se l'attaccante fa tentativi da remoto, hai installato file2ban e 
l'attaccante usa sempre lo stesso IP di partenza, allora riesce a fare 
pochi tentativi.



le stream con modalità TLS


ripeto non ho seguito il discorso e non sono pratico dei sistemi di 
telecamere.
Ma in generale se espone lo stream in TLS, cioè penso tu voglia dire TLS 
over HTTP == HTTPS, allora dipende dal metodo di autenticazione usato e 
dall'algoritmo utilizzato per creare il canale cifrato.
Tieni presente che l'HTTPS non è eccezionalmente intrinsecamente sicuro. 
Dovresti usare l'ultima versione TLS 1.3, impedire che si possa 
rinegoziare verso versioni precedenti, ...


Forse, se è una cosa ad hoc, sarebbe più sicuro crearsi due coppie di 
chiavi pubblica/privata, ognuna per un end point. Usi queste coppie di 
chiavi per autenticare i due end point. Cifri da un end point con la 
chiave pubblica dell'altro e gli invii il flusso cifrato e l'altro 
decifra con la sua chiave privata.


In questo modo decidi tu lunghezza chiavi (naturalmente dipende anche 
dalle prestazioni), quando rigenerarle, ..., su che porta esporre, ... 
evitare l'hanshake e la negoziazione, ...


E tutto questo presupponendo che i due end point non abbiano altri 
problemi di sicurezza che potrebbero rendere vane queste misure.


Ciao
Davide
--
Sistema operativo: http://www.debian.org
GNU/Linux User: 302090: http://counter.li.org
Non autorizzo la memorizzazione del mio indirizzo su outlook

Fail2ban e Openssl (era: Vlan, debian, VPN, zoneminder)

[Giuliano Curti]

Ciao a tutti,

come da consiglio di Giancarlo ho installato fail2ban; mi sto documentando
un po' e spero di configurarlo quanto prima; per SSH non dovrebbero esserci
eccessivi problemi vista la mole di documentazione esistente, diverso sarà
configurare la jail per motion e le telecamere di cui non trovo
documentazione.

Ho pensato però un'altra soluzione e volevo sentire i vostri consigli: la
configurazione di SSH per lavorare con chiavi senza password non
risolverebbe il problema? reputo difficile per un eventuale malintenzionato
scoprire la chiave o sbaglio?

Potrei risolvere la parte motion / telecamere con openssl perché motion
gestisce sia il webcontrol che le stream con modalità TLS: vi sembra una
soluzione adatta?
Su openssl devo studiare tutto, quindi tornerò a chiedere consigli, ma
intanto mi chiedevo se è una strada ragionevole da percorrere o una
cavolata.

Grazie, ciao,
Giuliano

Re: Risolto (era: Vlan, Debian, VPN, zoneminder...)

[Giuliano Curti]

Il dom 26 set 2021, 16:20 Giancarlo Martini  ha
scritto:

Scusa Giancarlo, mi era sfuggito il msg :-(

In che senso quale suggerimento?
> Quanti tentativi e/o quale intervallo?
>
> Fail2ban credo usi iptables per impostare le regole di accesso/non accesso
>

Si, fail2ban utilizza iptables, però lo usa con istruzioni molto selettive,
mirate a bannare i comportamenti dolosi (i singoli ip).

Sulla mia rPi4 per default le policy di iptables sono tutte "ACCEPT", forse
si potrebbe immaginare qualcosa di meno permissivo.

È vero che il router dovrebbe fare passare solo le chiamate SSH (porta 22)
e MOTION+TELECAMERE (5 porte) quindi l'intervento di fail2ban potrebbe
bastare, però chiedevo, da newby delle reti, se serviva maggior protezione.

--
> Giancarlo Martini
> (Replace 'AAA' con '@')
> mailto:giancarlo.firAAAgmail.com 
>

Grazie, saluti,
Giuliano

PS: per SSH ho visto istruzioni per fail2ban, ma per MOTION ancora nulla;
nessuno per caso ha già affrontato il problema?

Re: Risolto (era: Vlan, Debian, VPN, zoneminder...)

[Piviul]

Il 26/09/21 13:59, Giuliano Curti ha scritto:
Il sab 25 set 2021, 07:45 Giuliano Curti > ha scritto:


Il sab 25 set 2021, 07:03 Giancarlo Martini
mailto:giancarlo@gmail.com>> ha scritto:

.

Se esponi delle porte con un ip pubblico ti consiglio di usare
fail2ban e pw adatte. Le suddette porte saranno sicuramente
oggetto di tentativi di accesso.


ecco che si apre un nuovo capitolo di studio :-)  :-) :-)


Ho guardato la documentazione di fail2ban, sembrerebbe non 
complicatissimo e quasi tutto già fatto; questo almeno per la SSH, ma 
per Motion e le telecamere quale comportamento suggerite?


fail2ban, se non ricordo male, si basa sul fatto che ogni failed access 
sicuramente viene memorizzato in qualche log. Per creare un plugin 
fail2ban per un certo servizio (motion? motioneye? zoneminder?) mi 
sembra di ricordare che sia sufficiente dirgli quale file di log 
monitorare (dipende il servizio dove memorizza l'auth failed) e una 
regular expression per estrapolare il failed auth... comunque ricordo 
che era piuttosto semplice e ben documentato; prova a dare un'occhiata.


Piviul

Re: Risolto (era: Vlan, Debian, VPN, zoneminder...)

[Giancarlo Martini]

In che senso quale suggerimento?
Quanti tentativi e/o quale intervallo?

Fail2ban credo usi iptables per impostare le regole di accesso/non accesso


Il giorno dom 26 set 2021 alle ore 14:00 Giuliano Curti <
giulian...@gmail.com> ha scritto:

> Il sab 25 set 2021, 07:45 Giuliano Curti  ha
> scritto:
>
>> Il sab 25 set 2021, 07:03 Giancarlo Martini  ha
>> scritto:
>>
>> .
>>
>> Se esponi delle porte con un ip pubblico ti consiglio di usare fail2ban e
>>> pw adatte. Le suddette porte saranno sicuramente oggetto di tentativi di
>>> accesso.
>>>
>>
>> ecco che si apre un nuovo capitolo di studio :-)  :-) :-)
>>
>
> Ho guardato la documentazione di fail2ban, sembrerebbe non complicatissimo
> e quasi tutto già fatto; questo almeno per la SSH, ma per Motion e le
> telecamere quale comportamento suggerite?
>
> Domanda collegata: quale policy adottare per iptables o basta lasciar
> tutto libero che ci pensa il router?
>
> Grazie, saluti,
> Giuliano
>
>

-- 
Giancarlo Martini
(Replace 'AAA' con '@')
mailto:giancarlo.firAAAgmail.com 

Re: Risolto (era: Vlan, Debian, VPN, zoneminder...)

[Giuliano Curti]

Il sab 25 set 2021, 07:45 Giuliano Curti  ha scritto:

> Il sab 25 set 2021, 07:03 Giancarlo Martini  ha
> scritto:
>
> .
>
> Se esponi delle porte con un ip pubblico ti consiglio di usare fail2ban e
>> pw adatte. Le suddette porte saranno sicuramente oggetto di tentativi di
>> accesso.
>>
>
> ecco che si apre un nuovo capitolo di studio :-)  :-) :-)
>

Ho guardato la documentazione di fail2ban, sembrerebbe non complicatissimo
e quasi tutto già fatto; questo almeno per la SSH, ma per Motion e le
telecamere quale comportamento suggerite?

Domanda collegata: quale policy adottare per iptables o basta lasciar tutto
libero che ci pensa il router?

Grazie, saluti,
Giuliano

Re: Risolto (era: Vlan, Debian, VPN, zoneminder...)

[Giancarlo Martini]

Se esponi delle porte con un ip pubblico ti consiglio di usare fail2ban e
pw adatte. Le suddette porte saranno sicuramente oggetto di tentativi di
accesso.

--
Giancarlo Martini
http://www.giancarlomartini.it
http://www.linkedin.com/in/giancarlo-martini

Il ven 24 set 2021, 21:37 Giuliano Curti  ha scritto:

> Ciao a tutti,
>
> finalmente ho portato a termine la mia intenzione ed il mio sistema di
> videosorveglianza remota è funzionante.
>
> Ovviamente "termine" e "funzionante" sono termini eccessivi poiché ho
> ancora molto da affinare e prima ancora da imparare, però riesco a
> connettermi dal telefono al mio sistema ed a vedere le telecamere connesse
> quindi almeno il primo passo è stato fatto.
>
> Il sistema di videosorveglianza si basa essenzialmente su "motion" senza
> bisogno di altre sovrastrutture; probabilmente non è il massimo, però gli
> elementi fondamentali ci sono; devo solo definire e perfezionare alcuni
> dettagli, ma sono gli stessi che dovrei definire anche su altri applicativi
> (motioneye e zoneminder).
>
> La fase di connessione remota si è semplificata; non c'è stato bisogno di
> attivare VPN o altro perché motion emula un mini server web per cui sia la
> gestione che la visione delle telecamere sono dirottate su alcune porte del
> rPi4 che sovrintende il tutto e quindi basta reindirizzare quelle porte
> (oltre alla 22 per consentire anche la connessione SSH) sul router e il
> gioco è fatto.
>
> Il problema più spinoso in realtà è stato ottenere un indirizzo pubblico
> per il router; ho attivato una sim presso un provider nazionale destinata
> al telecontrollo; purtroppo l'indirizzo pubblico non è stato automatico; ci
> sono volute un po' di chiamate (nelle quali ho raccolto tutto lo spettro
> dello scibile: si può, attenda qualche giorno, già fatto, non si può fare),
> ma alla fine, dopo una settimana di stenti, l'ip pubblico è arrivato; NoIp
> sembra comportarsi bene per cui riesco nel mio intento.
>
> Ringrazio tutti dei consigli e soprattutto della pazienza; l'unico modo
> che mi rimane di sdebitarmi è quello di fornire tutte le informazioni sulle
> soluzioni che ho adottato; sono quindi a disposizione per qualsiasi
> informazione in mio possesso che possa risultare utile.
>
> Grazie, un saluto,
> Giuliano
>
>

Risolto (era: Vlan, Debian, VPN, zoneminder...)

[Giuliano Curti]

Ciao a tutti,

finalmente ho portato a termine la mia intenzione ed il mio sistema di
videosorveglianza remota è funzionante.

Ovviamente "termine" e "funzionante" sono termini eccessivi poiché ho
ancora molto da affinare e prima ancora da imparare, però riesco a
connettermi dal telefono al mio sistema ed a vedere le telecamere connesse
quindi almeno il primo passo è stato fatto.

Il sistema di videosorveglianza si basa essenzialmente su "motion" senza
bisogno di altre sovrastrutture; probabilmente non è il massimo, però gli
elementi fondamentali ci sono; devo solo definire e perfezionare alcuni
dettagli, ma sono gli stessi che dovrei definire anche su altri applicativi
(motioneye e zoneminder).

La fase di connessione remota si è semplificata; non c'è stato bisogno di
attivare VPN o altro perché motion emula un mini server web per cui sia la
gestione che la visione delle telecamere sono dirottate su alcune porte del
rPi4 che sovrintende il tutto e quindi basta reindirizzare quelle porte
(oltre alla 22 per consentire anche la connessione SSH) sul router e il
gioco è fatto.

Il problema più spinoso in realtà è stato ottenere un indirizzo pubblico
per il router; ho attivato una sim presso un provider nazionale destinata
al telecontrollo; purtroppo l'indirizzo pubblico non è stato automatico; ci
sono volute un po' di chiamate (nelle quali ho raccolto tutto lo spettro
dello scibile: si può, attenda qualche giorno, già fatto, non si può fare),
ma alla fine, dopo una settimana di stenti, l'ip pubblico è arrivato; NoIp
sembra comportarsi bene per cui riesco nel mio intento.

Ringrazio tutti dei consigli e soprattutto della pazienza; l'unico modo che
mi rimane di sdebitarmi è quello di fornire tutte le informazioni sulle
soluzioni che ho adottato; sono quindi a disposizione per qualsiasi
informazione in mio possesso che possa risultare utile.

Grazie, un saluto,
Giuliano

Re: Vlan, Debian, VPN, zoneminder,.....

[Giuliano Curti]

Il sab 28 ago 2021, 16:52 Giuliano Curti  ha scritto:

> Il sab 28 ago 2021, 10:44 Giuliano Curti  ha
> scritto:
>
>> Il ven 27 ago 2021, 13:48 Giuliano Curti  ha
>> scritto:
>>
>
>> 
>> .
>>
>
Ciao a tutti,
un aggiornamento.

1) mi sono accorto che l'hardware (raspberry Pi 2 B) non è adatto a gestire
zoneminder; il sistema diventa terribilmente lento, praticamente inusabile,
pertanto ho sospeso la sperimentazione in attesa di acquistare il nuovo
raspberry Pi4 4GB; devo considerare qualche altro hardware?

2) ho portato avanti la fase di networking e di accesso remoto; ho pensato
che forse la VPN da cui ero partito è eccessiva; potrebbe bastare il port
forwarding delle porte 80 (zoneminder agisce tramite apache) e 22 (ssh per
l'amministrazione); questa è ovviamente una ipotesi in attesa di conferma,
cmq mi sono mosso in questa direzione;

3) purtroppo ho scoperto che il router saponetta che uso non prevede la
gestione del port forwarding, pertanto devo anche qui sostituire
l'hardware; ho individuato il TP-link MR6400, ma accetto volentieri
suggerimenti;

4) mi è venuta anche una pazza idea; usare il raspberry come modem router
usando una internet key; dovrei avere un hardware comparabile ad un modem
router con il vantaggio (teorico) di essere gestibile totalmente; potrei
anche non aver bisogno del server dhcp visto che lavoro con ip statici; il
firewall è disponibile, l'unica complicazione (per me) potrebbe essere il
NAT dei device collegati (che poi è uno solo, il server zoneminder) e la
gestione del DNS; avrei anche il problema di indirizzare l'SSH su un'altra
porta in modo da avere raggiungibili entrambi i Raspberry, router e server.

La vostra opinione?

Grazie, saluti,
Giuliano

Re: Vlan, Debian, VPN, zoneminder,.....

[Giuliano Curti]

Il sab 28 ago 2021, 10:44 Giuliano Curti  ha scritto:

> Il ven 27 ago 2021, 13:48 Giuliano Curti  ha
> scritto:
>

> 
> Ho provato la seconda riuscendo a settare gli indirizzi statici, e quindi
> la rete interna funziona, ma la wlan0, che finalmente prende un indirizzo
> fisso coerente, non si collega al router; ..
>

Rettifica.

Chiedo scusa della precedente segnalazione: la configurazione che esclude
dhcpcd e usa /etc/network/interfaces funziona.
Mi aveva ingannato l'icona dello stato delle interfacce (in alto a destra)
che indicava una connessione rotta.
Un ultimo tentativo prima di provare una soluzione diversa mi ha fatto
capire che invece gli indirizzi erano statici e la connessione al router
funzionava, quello che volevo (evidentemente la gestione dell'icona in
questione ha problemi; non saprei a chi e come segnalare).

Chiedo scusa dell'inutile rumore ed ora passo al punto successivo.

Grazie, saluti,
giuliano

Re: Vlan, Debian, VPN, zoneminder,.....

[Giuliano Curti]

Il gio 26 ago 2021, 16:38 Giancarlo Martini  ha
scritto:

> hai provato l'opzione nodhcp
> https://manpages.debian.org/testing/dhcpcd5/dhcpcd.conf.5.en.html#dhcp
>

Ciao,
qui dice:
"nodhcp
Don't start DHCP or listen to DHCP messages. This is only useful when
allowing IPv4LL."
io non prevedo l'uso dell'opzione IPv4ALL anche perché non la vedo definita
(guarderò meglio).

Pensavo al contrario di provare
  "DenyInterfaces {eth0, wlan0}"
poi farò sapere.

Ciao,
G.

Re: Vlan, Debian, VPN, zoneminder,.....

[Giuliano Curti]

Il ven 27 ago 2021, 13:48 Giuliano Curti  ha scritto:

> Il gio 26 ago 2021, 16:30 Giancarlo Martini  ha
> scritto:
>
>> ...
>>
> 
>
> Ho fatto qualche prova contradditoria (ivi compresi impallare il sistema
> che non boota più), ma non ho ancora avuto il tempo di rendicontare..
>

Eccomi qui, a mo' di gambero, due passi avanti ed uno indietro :-)

Consultando la rete qui (1) e qui (2) ho visto due metodi alternativi:
a) configurazione statica in /etc/dhcpcd.conf e istruzione "iface 
inet manual" in /etc/network/interfaces
b) configurazione statica in /etc/network/interfaces con blocco e
dusabilitazione del demone dhcpcd.

Con la prima non sono riuscito a settare gli allegati indirizzi statici;
conservavo la connessione ad internet, cioè funziona la rete wifi (senza
però l'indirizzo statico che volevo), ma non riuscivo a creare la rete
interna.
Ho provato la seconda riuscendo a settare gli indirizzi statici, e quindi
la rete interna funziona, ma la wlan0, che finalmente prende un indirizzo
fisso coerente, non si collega al router; penso sia il mancato
accreditamento alla rete.
Ho provato anche a copiare il file wpa_supplicant.conf nella cartella /boot
come riportato in alcune guide, ma senza risultato

Ho praticamente due opzione
 complementari, ognuna contiene metà della soluzione; devo capire cone
fonderle insieme.

Grazie (spero non disturbi il resoconto), saluti,
giuliano


(1)
www.ionos.it/digitalguide/server/configurazione/raspberry-pi-assegnazione-di-un-indirizzo-fisso/
(2) www.raspberrypi.org/forums/viewtopic.php?t=275261

Re: Vlan, Debian, VPN, zoneminder,.....

[Giuliano Curti]

Il gio 26 ago 2021, 16:30 Giancarlo Martini  ha
scritto:

> ma sai che potresti aver ragione ... devo dire a mia discolpa che la
> configurazione di rete mi è sempre stata un pò ostica, sia perchè non mi è
> mai stato
> chiaro il ruolo dei vari script che l'abilitano, if-up con la
> descrizione delle interfacce in /etc/network/interfaces , il network
> manager e il dhcpcd.service.
>

Ciao Giancarlo, non te la prendere, io di rete non ci capisco proprio nulla
e i tuoi (vostri) consigli mi sono sempre d'aiuto, almeno mi fanno pensare.


Comunque se fossi in te una prova la farei lo stesso non escluderei a
> priori che possa funzionare.
>

Ho fatto qualche prova contradditoria (ivi compresi impallare il sistema
che non boota più), ma non ho ancora avuto il tempo di rendicontare; farò
ancora qualche esperimento, anche quello che mi dici nel post successivo;
ti farò sapere.

Grazie, saluti,
Giuliano

Re: Vlan, Debian, VPN, zoneminder,.....

[Giancarlo Martini]

hai provato l'opzione nodhcp
https://manpages.debian.org/testing/dhcpcd5/dhcpcd.conf.5.en.html#dhcp

Il giorno mer 25 ago 2021 alle ore 20:47 Giuliano Curti <
giulian...@gmail.com> ha scritto:

> Il mer 25 ago 2021, 10:24 Giancarlo Martini  ha
> scritto:
>
>> no, sono due cose distinte, credo che la configurazione statica delle
>> interfacce possa stare dove è ora, visto che per il wifi funziona, si
>> tratta di disabilitare la richiesta dell'ip.
>> Prova a dare questo comando
>> *sudo systemctl status dhcpcd.service*
>> per verificare lo stato del servizio
>> se è attivo dai
>> *sudo systemctl disable dhcpcd.service*
>> ed eventualmente, dopo aver riavviato ricontrolli con status e verifichi
>> che ip ci sono
>> *ip address show*
>> se è ancora attivo prova questo
>> *sudo systemctl mask dhcpcd.service*
>> e ricontrolli
>>
>
> Ciao Giancarlo, grazie;
>
> Fammi capire (chiedo volendo conoscere meglio le reti); la configurazione
> ora è in /etc/dhcpcd.conf, file di configurazione del demone dhcpcd; se lo
> disattivo chi legge quel file?
>
> Ciao
>>
>
> Grazie ancora, ciao,
> Giuliano
>
>

-- 
Giancarlo Martini
(Replace 'AAA' con '@')
mailto:giancarlo.firAAAgmail.com 

Re: Vlan, Debian, VPN, zoneminder,.....

[Giancarlo Martini]

ma sai che potresti aver ragione ... devo dire a mia discolpa che la
configurazione di rete mi è sempre stata un pò ostica, sia perchè non mi è
mai stato
chiaro il ruolo dei vari script che l'abilitano, if-up con la
descrizione delle interfacce in /etc/network/interfaces , il network
manager e il dhcpcd.service.
Comunque se fossi in te una prova la farei lo stesso non escluderei a
priori che possa funzionare.


Il giorno mer 25 ago 2021 alle ore 20:47 Giuliano Curti <
giulian...@gmail.com> ha scritto:

> Il mer 25 ago 2021, 10:24 Giancarlo Martini  ha
> scritto:
>
>> no, sono due cose distinte, credo che la configurazione statica delle
>> interfacce possa stare dove è ora, visto che per il wifi funziona, si
>> tratta di disabilitare la richiesta dell'ip.
>> Prova a dare questo comando
>> *sudo systemctl status dhcpcd.service*
>> per verificare lo stato del servizio
>> se è attivo dai
>> *sudo systemctl disable dhcpcd.service*
>> ed eventualmente, dopo aver riavviato ricontrolli con status e verifichi
>> che ip ci sono
>> *ip address show*
>> se è ancora attivo prova questo
>> *sudo systemctl mask dhcpcd.service*
>> e ricontrolli
>>
>
> Ciao Giancarlo, grazie;
>
> Fammi capire (chiedo volendo conoscere meglio le reti); la configurazione
> ora è in /etc/dhcpcd.conf, file di configurazione del demone dhcpcd; se lo
> disattivo chi legge quel file?
>
> Ciao
>>
>
> Grazie ancora, ciao,
> Giuliano
>
>

-- 
Giancarlo Martini
(Replace 'AAA' con '@')
mailto:giancarlo.firAAAgmail.com 

Re: Vlan, Debian, VPN, zoneminder,.....

[Giuliano Curti]

Il mer 25 ago 2021, 10:24 Giancarlo Martini  ha
scritto:

> no, sono due cose distinte, credo che la configurazione statica delle
> interfacce possa stare dove è ora, visto che per il wifi funziona, si
> tratta di disabilitare la richiesta dell'ip.
> Prova a dare questo comando
> *sudo systemctl status dhcpcd.service*
> per verificare lo stato del servizio
> se è attivo dai
> *sudo systemctl disable dhcpcd.service*
> ed eventualmente, dopo aver riavviato ricontrolli con status e verifichi
> che ip ci sono
> *ip address show*
> se è ancora attivo prova questo
> *sudo systemctl mask dhcpcd.service*
> e ricontrolli
>

Ciao Giancarlo, grazie;

Fammi capire (chiedo volendo conoscere meglio le reti); la configurazione
ora è in /etc/dhcpcd.conf, file di configurazione del demone dhcpcd; se lo
disattivo chi legge quel file?

Ciao
>

Grazie ancora, ciao,
Giuliano

Re: Vlan, Debian, VPN, zoneminder,.....

[Giancarlo Martini]

no, sono due cose distinte, credo che la configurazione statica delle
interfacce possa stare dove è ora, visto che per il wifi funziona, si
tratta di disabilitare la richiesta dell'ip.
Prova a dare questo comando
*sudo systemctl status dhcpcd.service*
per verificare lo stato del servizio
se è attivo dai
*sudo systemctl disable dhcpcd.service*
ed eventualmente, dopo aver riavviato ricontrolli con status e verifichi
che ip ci sono
*ip address show*
se è ancora attivo prova questo
*sudo systemctl mask dhcpcd.service*
e ricontrolli
Ciao




Il giorno mer 25 ago 2021 alle ore 08:56 Giuliano Curti <
giulian...@gmail.com> ha scritto:

> Il lun 23 ago 2021, 21:49 Giancarlo Martini  ha
> scritto:
>
>> Devi disabilitare il client DHCP, devi usare systems, il comando è
>> qualcosa di simile:
>> Sudo systemctl disable dhcp_qualcosa
>> Controlla la sintassi, vado a memoria
>>
>
> Quindi mi consigli di spostare la configurazione statica delle interfacce
> in /etc/network/interfaces (per poter disabilitare dhcpcd) ?
>
> --
>> Giancarlo Martini
>>
>
> Grazie, ciao,
> Giuliano
>
>

-- 
Giancarlo Martini
(Replace 'AAA' con '@')
mailto:giancarlo.firAAAgmail.com 

Re: Vlan, Debian, VPN, zoneminder,.....

[Giuliano Curti]

Il lun 23 ago 2021, 21:49 Giancarlo Martini  ha
scritto:

> Devi disabilitare il client DHCP, devi usare systems, il comando è
> qualcosa di simile:
> Sudo systemctl disable dhcp_qualcosa
> Controlla la sintassi, vado a memoria
>

Quindi mi consigli di spostare la configurazione statica delle interfacce
in /etc/network/interfaces (per poter disabilitare dhcpcd) ?

--
> Giancarlo Martini
>

Grazie, ciao,
Giuliano

Re: Vlan, Debian, VPN, zoneminder,.....

[Giancarlo Martini]

Devi disabilitare il client DHCP, devi usare systems, il comando è qualcosa
di simile:
Sudo systemctl disable dhcp_qualcosa
Controlla la sintassi, vado a memoria

--
Giancarlo Martini
http://www.giancarlomartini.it
http://www.linkedin.com/in/giancarlo-martini

Il lun 23 ago 2021, 21:23 Giuliano Curti  ha scritto:

> Il lun 23 ago 2021, 15:25 Giancarlo Martini  ha
> scritto:
>
>> Ciao Giuliano, l'indirizzo 169. ... sta a significare che non è stato
>> trovato il server dhcp, l'host se lo 'auto assegna'.
>>
>
> Ciao Giancarlo,
>
> grazie, questa è una di quelle info che la mia ignoranza delle reti mi
> preclude (mi sforzo però di correre ai ripari :-))
>
> Però io ho in /etc/dhcpcd.conf le istruzioni:
> interfacce eth0
> static address=192.168.0.1/24
> static routers=192.168.0.1
> Le analoghe istruzioni per la wlan0 vanno a bersaglio, perché queste no?
>
> Grazie, ciao,
> Giuliano
>
>

Re: Vlan, Debian, VPN, zoneminder,.....

[Giuliano Curti]

Il lun 23 ago 2021, 15:25 Giancarlo Martini  ha
scritto:

> Ciao Giuliano, l'indirizzo 169. ... sta a significare che non è stato
> trovato il server dhcp, l'host se lo 'auto assegna'.
>

Ciao Giancarlo,

grazie, questa è una di quelle info che la mia ignoranza delle reti mi
preclude (mi sforzo però di correre ai ripari :-))

Però io ho in /etc/dhcpcd.conf le istruzioni:
interfacce eth0
static address=192.168.0.1/24
static routers=192.168.0.1
Le analoghe istruzioni per la wlan0 vanno a bersaglio, perché queste no?

Grazie, ciao,
Giuliano

Re: Vlan, Debian, VPN, zoneminder,.....

[Giancarlo Martini]

Ciao Giuliano, l'indirizzo 169. ... sta a significare che non è stato
trovato il server dhcp, l'host se lo 'auto assegna'.

Il giorno lun 23 ago 2021 alle ore 14:41 Giuliano Curti <
giulian...@gmail.com> ha scritto:

> Ciao a tutti,
> eccomi di nuovo a chiedere il vs aiuto.
>
> Ho approfittato del periodo feriale per aggiornare il s.o., ora sono su
> Raspberry OS 32 bit (la ripartenza daccapo potrà comportare qualche errore
> già contemplato, me ne scuso in anticipo).
>
> Ricordo che il mio obbiettivo sono una rete wifi per la connessione al
> router saponetta ed una rete cablata per connettere uno switch POE e da qui
> le telecamere con tutti gli indirizzi statici.
>
> Ho fatto qualche prova con risultati alterni, positivi per la gestione
> delle telecamere, negativi per la gestione della rete.
>
> RETE.
> Ho eseguito il settaggio statico sia di eth0 che wlan0 in
> /etc/dhcpcd.conf; wlan0 funziona, eth0 no.
> Collegando lo switch all'avvio di rPi la eth0 prende un inaspettato
> 169.254.244.221; sembrerebbe che lo switch, anziché essere trasparente come
> pensavo, ha un dhcp a bordo e attiva una rete di classe B.
> Se avvio rPi senza connetterlo allo switch, l'interfaccia eth0 rimane
> senza configurazione, nonostante le istruzioni in dhcpcd.conf; non prende
> l'indirizzo nemmeno con "dhclient eth0" dopo averla connessa allo switch
> come invece dovrebbe.
> Non riesco a fare ulteriori indagini perché non riesco ad individuale
> l'indirizzo dello switch (non risultano pingabili né lo 169.254.0.1 né lo
> 169.254.244.1) quindi non so che pesci pigliare.
>
> POSSIBILE SOLUZIONE.
> È probabile qui agisca il client dhcpcd come suggerito da Simone; potrei
> disattivarlo ma dovrei portare la configurazione statica delle interfacce
> in /etc/network/interfaces: voi cosa consigliate?
>
> SOLUZIONE PROVVISORIA.
> In modo del tutto casuale, ho provato ad inserire un'altro switch fra rPi
> e lo switch poe con il risultato che lo switch poe si comporta questa volta
> in modo trasparente e rPi e telecamere prendono indirizzi univoci e
> coerenti.
> Potrei assegnare gli indirizzi fissi definitivi settando opportunamente il
> nuovo switch, ma non dispero di poter eliminare questo strato superfluo; il
> problema è che non ho ancora individuato come: qualche suggerimento?
>
> NOTE POSITIVE.
> Le note positive riguardano l'aver individuato le stringhe di connessione
> delle 4 telecamere che ho, tutte diverse; purtroppo le telecamere non hanno
> alcuna documentazione ed anche la rete non è stata così ricca e precisa, ad
> es. le indicazioni di ispyconnect sono state incomplete e non sempre
> risolutive.
> Al contrario si è dimostrata un'ottima risorsa l'app Onvier per Android
> con la quale ho individuato le stringhe di connessione.
> Al momento le ho provate solo con VLC, appena installo sul nuovo sistema
> zoneminder le verifico.
> Pensavo di pubblicarle sulla lista di zoneminder appena ho fatto la
> verifica, ma le posso anticipare qui, insieme al mac delle diverse
> telecamere, se qualcuno è interessato.
>
> Grazie della pazienza e dell'aiuto.
> Saluti,
> Giuliano
>
>

-- 
Giancarlo Martini
(Replace 'AAA' con '@')
mailto:giancarlo.firAAAgmail.com 

Re: Vlan, Debian, VPN, zoneminder,.....

[Giuliano Curti]

Ciao a tutti,
eccomi di nuovo a chiedere il vs aiuto.

Ho approfittato del periodo feriale per aggiornare il s.o., ora sono su
Raspberry OS 32 bit (la ripartenza daccapo potrà comportare qualche errore
già contemplato, me ne scuso in anticipo).

Ricordo che il mio obbiettivo sono una rete wifi per la connessione al
router saponetta ed una rete cablata per connettere uno switch POE e da qui
le telecamere con tutti gli indirizzi statici.

Ho fatto qualche prova con risultati alterni, positivi per la gestione
delle telecamere, negativi per la gestione della rete.

RETE.
Ho eseguito il settaggio statico sia di eth0 che wlan0 in /etc/dhcpcd.conf;
wlan0 funziona, eth0 no.
Collegando lo switch all'avvio di rPi la eth0 prende un inaspettato
169.254.244.221; sembrerebbe che lo switch, anziché essere trasparente come
pensavo, ha un dhcp a bordo e attiva una rete di classe B.
Se avvio rPi senza connetterlo allo switch, l'interfaccia eth0 rimane senza
configurazione, nonostante le istruzioni in dhcpcd.conf; non prende
l'indirizzo nemmeno con "dhclient eth0" dopo averla connessa allo switch
come invece dovrebbe.
Non riesco a fare ulteriori indagini perché non riesco ad individuale
l'indirizzo dello switch (non risultano pingabili né lo 169.254.0.1 né lo
169.254.244.1) quindi non so che pesci pigliare.

POSSIBILE SOLUZIONE.
È probabile qui agisca il client dhcpcd come suggerito da Simone; potrei
disattivarlo ma dovrei portare la configurazione statica delle interfacce
in /etc/network/interfaces: voi cosa consigliate?

SOLUZIONE PROVVISORIA.
In modo del tutto casuale, ho provato ad inserire un'altro switch fra rPi e
lo switch poe con il risultato che lo switch poe si comporta questa volta
in modo trasparente e rPi e telecamere prendono indirizzi univoci e
coerenti.
Potrei assegnare gli indirizzi fissi definitivi settando opportunamente il
nuovo switch, ma non dispero di poter eliminare questo strato superfluo; il
problema è che non ho ancora individuato come: qualche suggerimento?

NOTE POSITIVE.
Le note positive riguardano l'aver individuato le stringhe di connessione
delle 4 telecamere che ho, tutte diverse; purtroppo le telecamere non hanno
alcuna documentazione ed anche la rete non è stata così ricca e precisa, ad
es. le indicazioni di ispyconnect sono state incomplete e non sempre
risolutive.
Al contrario si è dimostrata un'ottima risorsa l'app Onvier per Android con
la quale ho individuato le stringhe di connessione.
Al momento le ho provate solo con VLC, appena installo sul nuovo sistema
zoneminder le verifico.
Pensavo di pubblicarle sulla lista di zoneminder appena ho fatto la
verifica, ma le posso anticipare qui, insieme al mac delle diverse
telecamere, se qualcuno è interessato.

Grazie della pazienza e dell'aiuto.
Saluti,
Giuliano

Re: Vlan, Debian, VPN, zoneminder,.....

[Giuliano Curti]

Ciao Simone,
scusa, devo andare di top quoting perché non riesco a spezzare il tuo msg
:-)

Grazie intanto; si, userò il tuo consiglio in fondo però devo un po'
rettificare il problema perché ha connotazioni che mi sono sfuggite nel mio
primo approccio al server DHCP.

Dunque, ieri potrei aver installato ed avviato il server DHCP avendo già
collegato il Raspberry allo switch e due telecamere; le due telecamere
hanno preso l'indirizzo ed anche il Raspberry che pure doveva avere un ip
statico.

Oggi, collegando lo switch e due telecamere a server DHCP avviato, la
sostituzione dell'indirizzo del Raspberry non si è verificato; verrebbe da
dire "problema risolto"; monitorerò il problema.

Si è però verificato un altro problema; una telecamera ha preso l'IP
correttamente, l'altra no, come non avesse una procedura di richiesta
dell'indirizzo: possibile che una IP camera non preveda questa procedura a
bordo?

Intanto sto spostando l'attenzione sulla configurazione di zoneminder, in
particolare alla connessione delle telecamere; devo vedere ancora bene,
però trovo difficoltà superiori alle attese (tipico del profano?);
protocolli di connessioni funzionanti su Onvier (app x android) non
funzionano su ZM; pensavo di essere in arrivo ed invece.

Pazienza, intanto grazie a tutti, ciao,
Giuliano

Il mar 10 ago 2021, 17:09 Simone Rossetto  ha scritto:

> Ciao


> > 5) PROBLEMA
> > 
>
> Se hai impostato un ip fisso e poi il dhcp lo sovrascrive vuol dire
> che c'è un client dhcp che chiede l'indirizzo al server. Quindi la
> soluzione corretta sarebbe disattivare quel client che potrebbe essere
> dhcpcd o anche il gestore delle connessioni (tipo network-manager).
>
> In alternativa sul file di config di isc-dhcp-server definisci l'ip
> per quel mac address con
> host NomeHost { hardware ethernet 11:22:33:44:55:66; fixed-address
> 192.168.0.1; }
>
> Ciao
> Simone

Re: Vlan, Debian, VPN, zoneminder,.....

[Simone Rossetto]

Ciao

> 5) PROBLEMA
> Ho settato l'interfaccia della rete LAN cablata (eth0) in modo statico
> (192.168.0.1), ma il server DHCP sovrappone l'indirizzo 192.168.0.101
> all'originario: come evitarlo? Devo fare le assegnazioni statiche in
> dhcpd.conf sulla base del MAC?

Se hai impostato un ip fisso e poi il dhcp lo sovrascrive vuol dire
che c'è un client dhcp che chiede l'indirizzo al server. Quindi la
soluzione corretta sarebbe disattivare quel client che potrebbe essere
dhcpcd o anche il gestore delle connessioni (tipo network-manager).

In alternativa sul file di config di isc-dhcp-server definisci l'ip
per quel mac address con
host NomeHost { hardware ethernet 11:22:33:44:55:66; fixed-address
192.168.0.1; }


Ciao
Simone

Re: Vlan, Debian, VPN, zoneminder,.....

[Giuliano Curti]

Ciao a tutti,

qualche aggiornamento dopo alcuni esperimenti;

1) intanto ho messo in campo l'hardware di destinazione e non più PC e
router di casa presi a prestito, quindi Raspberry, saponetta, switch poe,
ecc.;

2) prima operazione, per me rischiosa, aggiornamento da raspbian wheezy a
Jessie, necessario per caricare zoneminder; con mia grande sorpresa tutto
sembra essere andato liscio;

2b) dovrò forse fare ulteriori aggiornamenti per poter usare versioni di
zoneminder più aggiornate; probabilmente mi farò una SD aggiornata a
Bullseye, ma intanto ho approfittato per fare qualche esperimento;

3) ho installato il DHCP server (isc-dhcp-server) e configurato per gestire
la rete 192.168.0.0/24 ed assegnare gli IP nel range 192.168.0.100 -
192.168.0.200

4) ho collegato il fatidico switch POE e sembra funzionare; oltre al
Raspberry ho collegato due camere e NMAP mi consente di vederle connesse
(tutti i led di controlli su Raspberry e switch accesi come di norma)

5) PROBLEMA
Ho settato l'interfaccia della rete LAN cablata (eth0) in modo statico
(192.168.0.1), ma il server DHCP sovrappone l'indirizzo 192.168.0.101
all'originario: come evitarlo? Devo fare le assegnazioni statiche in
dhcpd.conf sulla base del MAC?

6) ho provato a configurare le due telecamere con zoneminder senza
successo; non è facile trovare i parametri di connessione; quelli che avevo
trovato con Onvier (un'app per Android) purtroppo non funzionano con
zoneminder; devo studiarci un po';

È tutto, grazie, buonanotte,
Giuliano

Re: Vlan, Debian, VPN, zoneminder,.....

[Giuliano Curti]

Il gio 5 ago 2021, 16:40 Giancarlo Martini  ha
scritto:

> 1) per ciò che scrivi, a mio avviso, il problema potrebbe essere nello
> switch, sicuramente avrai
> provato a cambiare porta del medesimo ( e magari invertire i cavi)
>

Ho collegato la LinuxBox ad entrambe le porte non alimentate senza
successo; non sono ancora riuscito a provare con cavi cross;

2) non è che magari è uno switch layer 3 che deve essere cconfigurato
>

In che modo?

3) come con la 2 e/o la 1 + il fatto che potrebbe essere su una rete
> diversa e quindi con nmap,
> se non imposti i parametri giusti non te la va a cercare
>
> per le info dello switch devi leggere la documentazione, è nuovo? Funziona
> in altri contesti?
>

Non c'è praticamente documentazione (ricontrollerò per maggior sicurezza);
sì, nuovo, preso POE per alimentare le telecamere e mai provato in
precedenza.

Grazie, ciao,
Giuliano

Re: Vlan, Debian, VPN, zoneminder,.....

[Giancarlo Martini]

1) per ciò che scrivi, a mio avviso, il problema potrebbe essere nello
switch, sicuramente avrai
provato a cambiare porta del medesimo ( e magari invertire i cavi)

2) non è che magari è uno switch layer 3 che deve essere configurato?

3) come con la 2 e/o la 1 + il fatto che potrebbe essere su una rete
diversa e quindi con nmap,
se non imposti i parametri giusti non te la va a cercare

per le info dello switch devi leggere la documentazione, è nuovo? Funziona
in altri contesti?

Il giorno gio 5 ago 2021 alle ore 07:50 Giuliano Curti 
ha scritto:

> Il mer 4 ago 2021, 10:05 Giancarlo Martini  ha
> scritto:
>
>> ho riletto i vari messaggi della lista
>> --
>> ..
>> --
>> per ricapitolare ed individuare la causa
>> se colleghi la linux box tramite lo switch non funziona (la linux box non
>> tira su l'interfaccia di rete)
>> se colleghi la linux box direttamente al router funziona (la linux box
>> tira su l'interfaccia di rete con indirizzo ip del server dhcp)
>>
>> ho capito bene?
>>
>
> Si, se posso essere ancora più chiaro e completo:
>
> a) linuxBox -(cavo/wifi)- modemRouter: ok
>
> b) linuxBox -(cavo)- switch: non prende l'IP
>
> c) linuxBox -(wifi)- modemRouter -(cavo)- switch -(cavo)- telecamera:
> dalla linuxBox (correttamente connessa alla rete) non riesco a vedere (con
> NMAP) la telecamera come se lo switch impedisse la connessione di
> quest'ultima; mi aspetterei che lo switch, privo del server DHCP, lasci
> comunicare telecamera e modemRouter ed assegnare a quest'ultima un IP e
> invece no;
>
> spero sia più chiaro.
>
> Aggiungo una variabile: non è che le due porte siano da considerare uplink
> e quindi da usare con cavi cross (anche se dovrebbero essere
> autoconfigurabili)? Questa prova non l'ho fatta; appena mi caputa un cavo
> cross provo a farla.
>
> Grazie Giancarlo, ciao,
> Giuliano
>
>

-- 
Giancarlo Martini
(Replace 'AAA' con '@')
mailto:giancarlo.firAAAgmail.com 

Re: Vlan, Debian, VPN, zoneminder,.....

[Giuliano Curti]

Il mer 4 ago 2021, 10:05 Giancarlo Martini  ha
scritto:

> ho riletto i vari messaggi della lista
> --
> ..
> --
> per ricapitolare ed individuare la causa
> se colleghi la linux box tramite lo switch non funziona (la linux box non
> tira su l'interfaccia di rete)
> se colleghi la linux box direttamente al router funziona (la linux box
> tira su l'interfaccia di rete con indirizzo ip del server dhcp)
>
> ho capito bene?
>

Si, se posso essere ancora più chiaro e completo:

a) linuxBox -(cavo/wifi)- modemRouter: ok

b) linuxBox -(cavo)- switch: non prende l'IP

c) linuxBox -(wifi)- modemRouter -(cavo)- switch -(cavo)- telecamera: dalla
linuxBox (correttamente connessa alla rete) non riesco a vedere (con NMAP)
la telecamera come se lo switch impedisse la connessione di quest'ultima;
mi aspetterei che lo switch, privo del server DHCP, lasci comunicare
telecamera e modemRouter ed assegnare a quest'ultima un IP e invece no;

spero sia più chiaro.

Aggiungo una variabile: non è che le due porte siano da considerare uplink
e quindi da usare con cavi cross (anche se dovrebbero essere
autoconfigurabili)? Questa prova non l'ho fatta; appena mi caputa un cavo
cross provo a farla.

Grazie Giancarlo, ciao,
Giuliano

Re: Vlan, Debian, VPN, zoneminder,.....

[Giancarlo Martini]

ho riletto i vari messaggi della lista
--
Ho collegato una Linux box allo switch POE (ad una delle due porte non
alimentate) ma la scheda del PC non prende l'ip;
viene segnalato un errore "no IPv6 routers present" (lo stesso collegamento
cablato con il modem-router funziona perfettamente).
--
per ricapitolare ed individuare la causa
se colleghi la linux box tramite lo switch non funziona (la linux box non
tira su l'interfaccia di rete)
se colleghi la linux box direttamente al router funziona (la linux box tira
su l'interfaccia di rete con indirizzo ip del server dhcp)

ho capito bene?


Il giorno mar 3 ago 2021 alle ore 21:55 Giuliano Curti 
ha scritto:

> Il mar 3 ago 2021, 13:55 Giancarlo Martini  ha
> scritto:
>
>> Per la configurazione di un host (qualsiasi apparecchiatura sulla rete
>> che non sia uno switch o un hub) deve essere configurata ...
>>
>
> Ciao Giancarlo,
> scusa se per mia comodità scombussolo l'ordine delle cose che dici:
>
> NMAP
> Conosco il comando e lo uso;  quando ad es. sono connesso (wifi o cavo)
> con il modem-router vedi tutti gli host collegati; il suo uso presuppone
> (sbaglio?) la connessione in rete; io non riuscivo a tirar su l'interfaccia
> -> nessuna connessione -> nessuna possibilità di usare NMAP :-(
>
> DHCP server
> La situazione, compreso il problema riscontrato (mancata configurazione
> dell'interfaccia), è plausibile nella configurazione linuxBox - switch -
> telecamera, ma non lo è più quando ho connesso tutto al modem-router;
> quello il server DHCP a bordo c'è l'ha eppure non riuscivo a vedere la
> telecamera (appunto con NMAP). Cmq farò altre prove perché so che in queste
> cose è facile sbagliare qualcosa e quindi fare valutazioni errate.
>
> STRATEGIA
> Sono pervenuto alla convinzione che sarebbe meglio disporre di indirizzi
> fissi; questo ovvio per il Raspberry che dovrebbe ricevere le connessioni
> remote, ma anche per le camere che non dovrebbero così patire problemi per
> eventuali crash (blackout energetici).
>
> PROBLEMA
> Ammesso che sia possibile settare l'indirizzo statico, rimane il problema
> di accedere alle telecamere per farlo e, come detto sopra, questo al
> momento non mi riesce.
>
> Cioa
>>
>
> Grazie, ciao,
> Giuliano
>
>

-- 
Giancarlo Martini
(Replace 'AAA' con '@')
mailto:giancarlo.firAAAgmail.com 

Re: Vlan, Debian, VPN, zoneminder,.....

[Giuliano Curti]

Il mar 3 ago 2021, 13:55 Giancarlo Martini  ha
scritto:

> Per la configurazione di un host (qualsiasi apparecchiatura sulla rete che
> non sia uno switch o un hub) deve essere configurata ...
>

Ciao Giancarlo,
scusa se per mia comodità scombussolo l'ordine delle cose che dici:

NMAP
Conosco il comando e lo uso;  quando ad es. sono connesso (wifi o cavo) con
il modem-router vedi tutti gli host collegati; il suo uso presuppone
(sbaglio?) la connessione in rete; io non riuscivo a tirar su l'interfaccia
-> nessuna connessione -> nessuna possibilità di usare NMAP :-(

DHCP server
La situazione, compreso il problema riscontrato (mancata configurazione
dell'interfaccia), è plausibile nella configurazione linuxBox - switch -
telecamera, ma non lo è più quando ho connesso tutto al modem-router;
quello il server DHCP a bordo c'è l'ha eppure non riuscivo a vedere la
telecamera (appunto con NMAP). Cmq farò altre prove perché so che in queste
cose è facile sbagliare qualcosa e quindi fare valutazioni errate.

STRATEGIA
Sono pervenuto alla convinzione che sarebbe meglio disporre di indirizzi
fissi; questo ovvio per il Raspberry che dovrebbe ricevere le connessioni
remote, ma anche per le camere che non dovrebbero così patire problemi per
eventuali crash (blackout energetici).

PROBLEMA
Ammesso che sia possibile settare l'indirizzo statico, rimane il problema
di accedere alle telecamere per farlo e, come detto sopra, questo al
momento non mi riesce.

Cioa
>

Grazie, ciao,
Giuliano

Re: Vlan, Debian, VPN, zoneminder,.....

[Giancarlo Martini]

Per la configurazione di un host (qualsiasi apparecchiatura sulla rete che
non sia uno switch o un hub) deve essere configurata con indirizzo ip,
netmask, defaulf gateway ed eventualmente dns se si vogliono usare i nomi
di dominio.

Per configurare un host ci sono due possibilità, usare un server dhcp sulla
rete che distribuisce lui gli indirizzi, e tutto il resto (a chi glieli
richiede!!) oppure mettere tutte le info a mano.

Se non c'è un server dhcp e non si sono messi ip (etc. etc) manualmente gli
host non si vedono.

Quello che volevo dire è che prima si deve scegliere la strategia da
utilizzare (che potrebbe essere anche un misto dei due sistemi).

Per vedere chi c'è in rete, se hai almeno il pc linux configurato puoi
usare il comando nmap.

Io ti consiglierei di collegare sia il router, il pc con linux e la
telecamera allo switch e dopo dare i seguenti comandi

1) ip address show (dovrebbe mostrare l'ip della stazione linux e vedi se
hai un ip e qual'è)
2) dare il comando nmap ( e per i parametri dipende dal risultato del
comando precedente) qualcosa dtipo
nmap 192.168.1.*/24
mi sembra, comunque qui c'è la documentazione
https://nmap.org/man/it/man-briefoptions.html
Cioa











Il giorno mar 3 ago 2021 alle ore 10:26 Giuliano Curti 
ha scritto:

> Ciao a tutti,
> rieccomi con il primo problema HW che non so come risolvere.
>
> Volevo provare una nuova telecamera IP POE cablata (non wifi).
> Ho collegato una Linux box allo switch POE (ad una delle due porte non
> alimentate) ma la scheda del PC non prende l'ip;
> viene segnalato un errore "no IPv6 routers present" (lo stesso
> collegamento cablato con il modem-router funziona perfettamente).
>
> L'errore mi ha portato a disabilitare l'IPv6 nel file /etc/sysctl.conf, ma
> senza successo.
>
> In un video online ho sentito affermare che lo switch è trasparente agli
> indirizzi, cioè, arguisco, non monta un dispositivo DHCP.
> Per me tutto ciò è nebbia, pensavo che ogni scatolotto facesse le stesse
> cose e invece no.
> Da qui la prima domanda: vi torna la cosa? ho commesso qualche errore o
> c'è qualche passo che ho omesso? unica soluzione, nell'ottica del layout
> che avevo tratteggiato nel msg iniziale, è allestire il DHCP sul Raspberry?
>
> Sulla base di queste considerazioni ho collegato lo switch al modem-router
> sperando che la telecamera ricevesse l'ip da quest'ultimo; non è
> esattamente il layout che avevo in mente, ma mi interessava verificare la
> connessione con la telecamera, ma anche così niente.
> Da qui la seconda domanda: ho omesso qualche passaggio cruciale? c'è
> qualche accorgimento o tentativo che posso fare per superare il problema?
> come assegnare un indirizzo IP alla telecamera?
>
> Sottinteso: le apparecchiature, switch e telecamera, non dispongono di
> ALCUNA documentazione ed in rete non ho trovato nulla.
>
> Grazie infinite della pazienza, saluti,
> giuliano
>
>

-- 
Giancarlo Martini
(Replace 'AAA' con '@')
mailto:giancarlo.firAAAgmail.com 

Re: Vlan, Debian, VPN, zoneminder,.....

[Giuliano Curti]

Il mar 3 ago 2021, 11:18 Paolo Miotto  ha scritto:

>
> Il 03/08/21 10:26, Giuliano Curti ha scritto:
>
> unica soluzione, nell'ottica del layout che avevo tratteggiato nel msg
> iniziale, è allestire il DHCP sul Raspberry?
>
>
> Se sulle telecamere non puoi impostare l'ip, allora devi avere un server
> DHCP sulla loro lan; il posto più ovvio è il Raspberry.
>
> Però prima controlla sulla documentazione se la telecamera ha un IP di
> fallback a cui ti puoi collegare (impostando il pc sulla stessa rete) per
> riconfigurarla con un ip statico sulla tua rete.
>
Purtroppo, come avevo detto sopra, NESSUNA documentazione (forse vale la
pena di acquisire prodotti di fascia superiore se negli documentati).

> --
>
> Mandi.
>
> Paolo
>
> Grazie dei consigli, saluti,
Giuliano


>

Re: Vlan, Debian, VPN, zoneminder,.....

[Paolo Miotto]

Il 03/08/21 10:26, Giuliano Curti ha scritto:
unica soluzione, nell'ottica del layout che avevo tratteggiato nel msg 
iniziale, è allestire il DHCP sul Raspberry?



Se sulle telecamere non puoi impostare l'ip, allora devi avere un server 
DHCP sulla loro lan; il posto più ovvio è il Raspberry.


Però prima controlla sulla documentazione se la telecamera ha un IP di 
fallback a cui ti puoi collegare (impostando il pc sulla stessa rete) 
per riconfigurarla con un ip statico sulla tua rete.



--

Mandi.

Paolo

Re: Vlan, Debian, VPN, zoneminder,.....

[Giuliano Curti]

Il mar 3 ago 2021, 10:01 paolo gagini  ha scritto:

> Buongiorno a tutti,
>
> mi permetto di intervenire per segnalarvi
>

Ciao Paolo, il tuo intervento è assolutamente gradito

 che probabilmente l'IP pubblico sarà dinamico per cui servirà anche un
> sistema che avvisi dyndns o fornitore di servizio similare quando l'IP
> cambierà.
>
> Spesso i router casalinghi offrono la possibilità di registrare le
> credenziali di accesso a fornitori come dyndns.
>
> In questo modo anche se l'IP cambierà potrete accedere ai vostri servizi
> con lo stesso indirizzo letterale.
>

Si, era previsto; o il router o dei programmi che segnalano al provider il
cambio ip (avevo anni fa offerto un servizio web e avevo già affrontato il
problema con no-ip).


> Paolo
>

Grazie, ciao,
Giuliano

Re: Vlan, Debian, VPN, zoneminder,.....

[Giuliano Curti]

Ciao a tutti,
rieccomi con il primo problema HW che non so come risolvere.

Volevo provare una nuova telecamera IP POE cablata (non wifi).
Ho collegato una Linux box allo switch POE (ad una delle due porte non
alimentate) ma la scheda del PC non prende l'ip;
viene segnalato un errore "no IPv6 routers present" (lo stesso collegamento
cablato con il modem-router funziona perfettamente).

L'errore mi ha portato a disabilitare l'IPv6 nel file /etc/sysctl.conf, ma
senza successo.

In un video online ho sentito affermare che lo switch è trasparente agli
indirizzi, cioè, arguisco, non monta un dispositivo DHCP.
Per me tutto ciò è nebbia, pensavo che ogni scatolotto facesse le stesse
cose e invece no.
Da qui la prima domanda: vi torna la cosa? ho commesso qualche errore o c'è
qualche passo che ho omesso? unica soluzione, nell'ottica del layout che
avevo tratteggiato nel msg iniziale, è allestire il DHCP sul Raspberry?

Sulla base di queste considerazioni ho collegato lo switch al modem-router
sperando che la telecamera ricevesse l'ip da quest'ultimo; non è
esattamente il layout che avevo in mente, ma mi interessava verificare la
connessione con la telecamera, ma anche così niente.
Da qui la seconda domanda: ho omesso qualche passaggio cruciale? c'è
qualche accorgimento o tentativo che posso fare per superare il problema?
come assegnare un indirizzo IP alla telecamera?

Sottinteso: le apparecchiature, switch e telecamera, non dispongono di
ALCUNA documentazione ed in rete non ho trovato nulla.

Grazie infinite della pazienza, saluti,
giuliano

Re: Vlan, Debian, VPN, zoneminder,.....

[paolo gagini]

Buongiorno a tutti,

mi permetto di intervenire per segnalarvi che probabilmente l'IP pubblico
sarà dinamico per cui servirà anche un sistema che avvisi dyndns o
fornitore di servizio similare quando l'IP cambierà.

Spesso i router casalinghi offrono la possibilità di registrare le
credenziali di accesso a fornitori come dyndns.

In questo modo anche se l'IP cambierà potrete accedere ai vostri servizi
con lo stesso indirizzo letterale.

Paolo



Il mar 3 ago 2021, 08:54 Paolo Miotto  ha scritto:

> Il 02/08/21 13:45, Giuliano Curti ha scritto:
>
> Il lun 2 ago 2021, 08:06 Paolo Miotto  ha scritto:
>
> Scusa la pignoleria su un aspetto secondario, ma approfitto per esterndere
> la mia (scarsa) conoscenza della reti.
> A me non sembra la stessa cosa, a casa ho:
> Internet --- wan --- modem/router --- lan --- periferiche.
> Nel mio caso avrei:
> Internet --- wan --- modem/router --- lan1  Raspberry --- lan2 -
> periferiche.
> Mi sfugge qualcosa.
>
> E' vero, non è proprio la stessa cosa, ho semplificato un po'; nella LAN
> del router (wifi) rispetto al router ci sarà il raspberry, che avrà un
> piede nella rete privata che contiene le telecamere. Ho dato per scontato
> che queste non debbano avere accesso ad internet, in questo modo non devi
> attivare NAT o routing sul raspberry. Ovvaimente i 2 segmenti di rete
> dovranno avere indirizzamenti diversi.
>
> La parte
>
> -- lan2 - periferiche.
>
> diventa quindi ininfluente per quanto riguarda il collegamento ad internet.
>
> Poi bisogna capire come esporre il tuo servizio all'esterno, e qui tutto
> dipende dalle potenzialità della saponetta e del provider: se non sei
> dietro un nat e la saponetta ti permette di fare un port forwarding sei a
> cavallo, basta che registri il tuo ip su un dyndns. In caso contrario è un
> po' più dura, da questo punto vi vista vanno meglio le chiavette USB, visto
> che la terminazione della connessione viene fatta dal dispositivo utente
> (in questo caso il raspberry). In caso contrario devi optare per un relay
> esterno (vpn o proxy).
>
>
> --
>
> MAndi
>
> Paolo
>

Re: Vlan, Debian, VPN, zoneminder,.....

[Giuliano Curti]

Il mar 3 ago 2021, 08:19 Paolo Miotto  ha scritto:

> Il 02/08/21 13:45, Giuliano Curti ha scritto:
>
> Il lun 2 ago 2021, 08:06 Paolo Miotto  ha scritto:
>
> Scusa la pignoleria su un aspetto secondario, ma approfitto per esterndere
> la mia (scarsa) conoscenza della reti.
> A me non sembra la stessa cosa, a casa ho:
> Internet --- wan --- modem/router --- lan --- periferiche.
> Nel mio caso avrei:
> Internet --- wan --- modem/router --- lan1  Raspberry --- lan2 -
> periferiche.
> Mi sfugge qualcosa.
>
> E' vero, non è proprio la stessa cosa, ho semplificato un po'; nella LAN
> del router (wifi) rispetto al router ci sarà il raspberry, che avrà un
> piede nella rete privata che contiene le telecamere. Ho dato per scontato
> che queste non debbano avere accesso ad internet, in questo modo non devi
> attivare NAT o routing sul raspberry. Ovvaimente i 2 segmenti di rete
> dovranno avere indirizzamenti diversi.
>
Grazie del chiarimento.

La parte
>
> -- lan2 - periferiche.
>
> diventa quindi ininfluente per quanto riguarda il collegamento ad internet.
>
> Poi bisogna capire come esporre il tuo servizio all'esterno, e qui tutto
> dipende dalle potenzialità della saponetta e del provider: se non sei
> dietro un nat e la saponetta ti permette di fare un port forwarding sei a
> cavallo, basta che registri il tuo ip su un dyndns. In caso contrario è un
> po' più dura, da questo punto vi vista vanno meglio le chiavette USB, visto
> che la terminazione della connessione viene fatta dal dispositivo utente
> (in questo caso il raspberry). In caso contrario devi optare per un relay
> esterno (vpn o proxy).
>
Qui ci sono dettagli già più ostico; spero di arrivarci quanto prima; da
una prossima mail il tenore dei miei problemi attuali 

> MAndi
>
> Paolo
>
>
> Grazie, ciao,
Giuliano

>
>

Re: Vlan, Debian, VPN, zoneminder,.....

[Paolo Miotto]

Il 02/08/21 13:45, Giuliano Curti ha scritto:
Il lun 2 ago 2021, 08:06 Paolo Miotto <mailto:paolo.mio...@uniud.it>> ha scritto:


Scusa la pignoleria su un aspetto secondario, ma approfitto per 
esterndere la mia (scarsa) conoscenza della reti.

A me non sembra la stessa cosa, a casa ho:
Internet --- wan --- modem/router --- lan --- periferiche.
Nel mio caso avrei:
Internet --- wan --- modem/router --- lan1  Raspberry --- lan2 - 
periferiche.

Mi sfugge qualcosa.


E' vero, non è proprio la stessa cosa, ho semplificato un po'; nella LAN 
del router (wifi) rispetto al router ci sarà il raspberry, che avrà un 
piede nella rete privata che contiene le telecamere. Ho dato per 
scontato che queste non debbano avere accesso ad internet, in questo 
modo non devi attivare NAT o routing sul raspberry. Ovvaimente i 2 
segmenti di rete dovranno avere indirizzamenti diversi.


La parte

-- lan2 - periferiche.

diventa quindi ininfluente per quanto riguarda il collegamento ad internet.

Poi bisogna capire comeesporre il tuo servizio all'esterno, e qui tutto 
dipende dalle potenzialità della saponetta e del provider: se non sei 
dietro un nat e la saponetta ti permette di fare un port forwarding sei 
a cavallo, basta che registri il tuo ip su un dyndns. In caso contrario 
è un po' più dura, da questo punto vi vista vanno meglio le chiavette 
USB, visto che la terminazione della connessione viene fatta dal 
dispositivo utente (in questo caso il raspberry). In caso contrario devi 
optare per un relay esterno (vpn o proxy).



--

MAndi

Paolo

Re: Vlan, Debian, VPN, zoneminder,.....

[Giuliano Curti]

Ciao Simone,
scusa il topquoting ma per qualche motivo che non capisco, non riesco a
spezzare il tuo msg ed inserire i miei commenti e così non si capirebbe più
nulla .

Per quanto riguarda Http/Https non so ancora; so che ZM si appoggia ad
Apache, però la prerogativa che dici non l'ho ancora studiata (avrò ancora
bisogno pesante del vs aiuto sulla parte SW).

Per il Raspberry condivido l'utilità di fissare l'IP; spero la saponetta me
lo consenta, altrimenti dovrò valutare la sostituzione.

Per quanto riguarda lo switch non l'ho ancora provato e quindi non saprei
dirti se monta o meno il DHCP; nell'ipotesi peggiore dovrò (sempre con il
vs aiuto) adibire il Raspberry allo scopo.
Cmq intanto guardo la guida che mi hai gentilmente indicato.

Grazie, ciao,
Giuliano


Il lun 2 ago 2021, 14:45 Simone Rossetto  ha scritto:

> Ciao


> > In teoria Zm opera tutto dall'interfaccia http quindi non dovrei
> > necessitare di altro salvo gestire le credenziali dei vari utenti.
>
> Dato che passi da internet io userei httpS, non so se zm da solo lo
> supporta. Se non lo supporta mettici davanti un webserver con
> connessione cifrata.
>
> > qui pensavo di usare i DHCP della saponetta per la lan1 e di uno switch
> per
> > la lan2, anche se forse è preferibile utilizzare ip fissi al di fuori
> > dei range DHCP e disabilitare questi ultimi.
>
> Per l'ip del raspi sulla lan1 non ti consiglio di usare dhcp perché se
> per qualche motivo un giorno dovesse cambiare ip poi l'inoltro della
> connessione dalla saponetta non funzionerebbe più. O fai in modo dalla
> saponetta di assegnare un ip fisso al raspi oppure lo configuri
> direttamente nel sistema.
> Per la lan2 ti serve necessariamente un dhcp perché uno switch puro
> (passami il termine) non assegna ip. Guarda questa guida [1],
> configurare isc-dhcp-server è abbastanza semplice.
>
>
> Ciao
> Simone
>
> [1] https://wiki.debian.org/it/DHCP_Server
>

Re: Vlan, Debian, VPN, zoneminder,.....

[Paolo Miotto]

Il 01/08/21 15:22, Giuliano Curti ha scritto:

Il tutto si traduce in un host (raspberry) collegato:
a) in wifi (prima rete lan) con la saponetta per l'accesso ad internet 
(su cui far viaggiare la VPN)
b) in rete cablata (seconda rete lan) con uno switch POE al quale 
attaccare le telecamere IP.


Ecco la prima domanda: si può fare? ha senso oppure esistono soluzioni 
migliori?



Certo che si può fare, anzi, si fa così, come per la tua *DSL di casa.

Il raspberry diventa il tuo "router", l'interfaccia WiFi è la WAN, 
l'interfaccia ethernet è la LAN.



Visto che accederai alle telecamere attraverso ZoneMinder, non è neppure 
necessario attivare il routing/NAT sul Raspberry, se prelevi i flussi 
RTSP direttamente dalla telecamera senza passare per i vari cloud.



--

Mandi.

Paolo

Re: Vlan, Debian, VPN, zoneminder,.....

[Simone Rossetto]

Ciao

> In teoria Zm opera tutto dall'interfaccia http quindi non dovrei
> necessitare di altro salvo gestire le credenziali dei vari utenti.

Dato che passi da internet io userei httpS, non so se zm da solo lo
supporta. Se non lo supporta mettici davanti un webserver con
connessione cifrata.

> qui pensavo di usare i DHCP della saponetta per la lan1 e di uno switch per
> la lan2, anche se forse è preferibile utilizzare ip fissi al di fuori
> dei range DHCP e disabilitare questi ultimi.

Per l'ip del raspi sulla lan1 non ti consiglio di usare dhcp perché se
per qualche motivo un giorno dovesse cambiare ip poi l'inoltro della
connessione dalla saponetta non funzionerebbe più. O fai in modo dalla
saponetta di assegnare un ip fisso al raspi oppure lo configuri
direttamente nel sistema.
Per la lan2 ti serve necessariamente un dhcp perché uno switch puro
(passami il termine) non assegna ip. Guarda questa guida [1],
configurare isc-dhcp-server è abbastanza semplice.


Ciao
Simone

[1] https://wiki.debian.org/it/DHCP_Server

Re: Vlan, Debian, VPN, zoneminder,.....

[Giuliano Curti]

Il lun 2 ago 2021, 09:08 Simone Rossetto  ha scritto:
> Ciao Giuliano

ciao Simone,
grazie della risposta

>> ..
>> Ecco la prima domanda: si può fare?

> Sì, si può fare, però la saponetta deve avere un IP pubblico a quale
> si può accedere da internet e devi configurarla per inoltrare le
> connessioni sulla porta della vpn verso il raspi.

Si; sarei arrivato successivamente, risolta la parte HW.
Do per scontato che devo creare un dominio (pensavo a DynDns o no-ip);
abilitare il firewall per accettare le connessioni alla porta 80
(la saponetta non so cosa monta esattamente) e indirizzarle
al Raspberry su cui gira Zm + Apache.
In teoria Zm opera tutto dall'interfaccia http quindi non dovrei
necessitare di altro salvo gestire le credenziali dei vari utenti.

> 
>  o un server dhcp per assegnare gli ip alle periferiche della lan
> (a meno che tu non usi un dhcp esterno o tu assegni gli ip fissi ad
> ogni periferica)

qui pensavo di usare i DHCP della saponetta per la lan1 e di uno switch per
la lan2, anche se forse è preferibile utilizzare ip fissi al di fuori
dei range DHCP e disabilitare questi ultimi.

>  o firewall configurato per fare il routing del traffico dalla vpn
> alla rete interna e per bloccare tutte le connessioni da internet che
> non siano sulla  della vpn
>   ...

dalla mail di Paolo ho intuito che forse la VPN non è necessaria, quindi
un passo in meno, come peraltro dici sotto anche tu.

> Ciao
> Simone

grazie, ciao,
giuliano

PS: chiedo scusa della formattazione che ho fatto manualmente perché mi
dava problemi il tuo msg 

Re: Vlan, Debian, VPN, zoneminder,.....

[Giuliano Curti]

Il lun 2 ago 2021, 08:06 Paolo Miotto  ha scritto:

Ciao Paolo,
grazie della risposta

Il 01/08/21 15:22, Giuliano Curti ha scritto:
> > .

> Ecco la prima domanda: si può fare? ha senso oppure esistono soluzioni
> > migliori?
>
>
> Certo che si può fare, anzi, si fa così, come per la tua *DSL di casa.
>

Scusa la pignoleria su un aspetto secondario, ma approfitto per esterndere
la mia (scarsa) conoscenza della reti.
A me non sembra la stessa cosa, a casa ho:
Internet --- wan --- modem/router --- lan --- periferiche.
Nel mio caso avrei:
Internet --- wan --- modem/router --- lan1  Raspberry --- lan2 -
periferiche.
Mi sfugge qualcosa.


Il raspberry diventa il tuo "router", l'interfaccia WiFi è la WAN,
> l'interfaccia ethernet è la LAN.
>
>
> Visto che accederai alle telecamere attraverso ZoneMinder, non è neppure
> necessario attivare il routing/NAT sul Raspberry, se prelevi i flussi
> RTSP direttamente dalla telecamera senza passare per i vari cloud.
>

Se capisco bene, mi stai dicendo che esponendo un servizio http (zoneminder
opera con apache + PHP) mi basta abilitare le chiamate in ingresso ed
indirizzarle al Raspberry (cioè dove gira zoneminder + apache); è così?

--

Mandi


Paolo


Grazie, ciao,
Giuliano

Re: Vlan, Debian, VPN, zoneminder,.....

[Simone Rossetto]

Ciao Giuliano

> Il tutto si traduce in un host (raspberry) collegato:
> a) in wifi (prima rete lan) con la saponetta per l'accesso ad internet (su
> cui far viaggiare la VPN)
> b) in rete cablata (seconda rete lan) con uno switch POE al quale attaccare
> le telecamere IP.
>
> Ecco la prima domanda: si può fare?

Sì, si può fare, però la saponetta deve avere un IP pubblico a quale
si può accedere da internet e devi configurarla per inoltrare le
connessioni sulla porta della vpn verso il raspi.

Ti scrivo una configurazione di esempio:
 - rete 192.168.1.0/24 per internet: ip fisso su wlan0 192.168.1.1 del
raspi a cui inoltrare le connessioni dalla saponetta sulla porta, ad
esempio,  per la vpn)
 - rete 10.2.2.0/24 per la lan locale
 - vpn su 172.16.3.0/24
 - sul raspi ti serve:
 o un server dhcp per assegnare gli ip alle periferiche della lan
(a meno che tu non usi un dhcp esterno o tu assegni gli ip fissi ad
ogni periferica)
 o firewall configurato per fare il routing del traffico dalla vpn
alla rete interna e per bloccare tutte le connessioni da internet che
non siano sulla  della vpn
 o wireguard (o altro server vpn) in ascolto sulla 
 o zoneminder in ascolto sulla rete lan e sulla vpn

A questo punto dal client devi collegarti alla vpn e poi con il
borwser puoi accedere all'ip vpn del raspi. Realmente non è neppure
necessario configurare il firewall per fare routing perché zoneminder
già ascolta sulla vpn, diciamo che quello ti serve se dal client
esterno vuoi raggiungere direttamente le altre periferiche della rete
lan (che poi forse sarebbe lo scopo reale di una vpn).

> ha senso oppure esistono soluzioni migliori?

La doppia rete isola le periferiche della lan da internet, quindi puoi
controllare tramite raspi (con firewall, dhcp, dns, proxy, ecc) in che
modo tali periferiche raggiungono internet; questo sicuramente può
aumentare la sicurezza delle rete interna.
Però se la vpn ti serve solo per zoneminder senza necessità di accesso
diretto alle altre periferiche forse ti può convenire mettere
zoneminder dietro un webserver (apache, lighttpd, ecc) e accedere
direttamente con il browser (se l'autenticazione con user+pwd non ti
sembra sufficiente aggiungi il certificato client). Non mi pronuncio
sulla sicurezza di vpn contro user+pwd+certificato, non sono esperto
in materia, ma è una possibile soluzione alternativa.


Ciao
Simone

Re: Vlan, Debian, VPN, zoneminder,.....

[Giuliano Curti]

Il dom 1 ago 2021, 20:47 Giancarlo Martini  ha
scritto:

Ciao Giancarlo, grazie della risposta;

Si, credo si possa fare, non so come vuoi accedere alle telecamere, penso
> con il browser.
>

Pensavo di utilizzare Zoneminder per la gestione delle telecamere, per gli
allarmi e per il salvataggio di immagini/video (devo ancora studiarlo).
Peraltro agisce come server HTTP mi dovrò preoccupare di costruire una VPN
(altro mio terribile scoglio si cui vi romperò l'anima) per potervi
accedere da remoto.

Io, sempre con la Raspberry, ho fatto in modo di fare scaricare con FTP le
> immagini delle telecamere. Poi a certi intervalli inviarmele per email
>

Avevo coltivato per un po' di tempo un'idea fatta in casa con telecamere
costituite da singoli Raspberry + scheda video + motion + SD; le
"telecamere" scaricavano su SD locale le tracce video ed un Raspberry
centrale faceva il polling delle varie SD periferiche, copiava i video e
segnalava via mail eventuali allarmi, ma la difficoltà a gestire
l'illuminazione notturna, le difficoltà di assemblaggio delle "telecamere"
e soprattutto il ribasso dei costi delle camere IP mi ha consigliato di
cambiare strada :-)

>
--
> Giancarlo Martini
>

Grazie ancora, ciao,
Giuliano

Re: Vlan, Debian, VPN, zoneminder,.....

[Giancarlo Martini]

Si, credo si possa fare, non so come vuoi accedere alle telecamere, penso
con il browser.
Io, sempre con la Raspberry, ho fatto in modo di fare scaricare con FTP le
immagini delle telecamere. Poi a certi intervalli inviarmele per email

--
Giancarlo Martini
http://www.giancarlomartini.it
http://www.linkedin.com/in/giancarlo-martini

Il dom 1 ago 2021, 15:23 Giuliano Curti  ha scritto:

> Ciao a tutti,
>
> volevo riprendere una vecchia idea che richiede un allestimento di rete;
> essendomi formato (si fa per dire) nell'epoca del "personal" computer, la
> rete mi è ostica ed ho bisogno del vs aiuto.
>
> L'ambiente software sarà Debian, o meglio Raspbian perché ho intenzione di
> usare il Raspberry (+ ZoneMinder + OpenVPN / WireGuard) però i primi
> problemi riguardano l'hardware, OT rispetto all'argomento della lista.
> Provo a formulare i miei dubbi, nel caso non graditi bloccherò subito la
> discussione :-) grazie della pazienza.
>
> Il mio obiettivo è quello di costruire una rete locale che vede un host
> (raspberry) e diverse periferiche (telecamere IP) cui intendo accedere da
> remoto (PC e Mobile) tramite una VPN.
>
> Per l'host pensavo di gestire una doppia lan per una serie di motivi:
> 1) credo di aver intravisto in rete che una lan non direttamente
> affacciata all'esterno è più sicura (il problema sicurezza per i miei dati
> non è un tabù, quindi diciamo che la questione è quasi accademica)
> 2) possibilità di usare l'hardware disponibile (dispongo di una saponetta
> con sim dati).
>
> Il tutto si traduce in un host (raspberry) collegato:
> a) in wifi (prima rete lan) con la saponetta per l'accesso ad internet (su
> cui far viaggiare la VPN)
> b) in rete cablata (seconda rete lan) con uno switch POE al quale
> attaccare le telecamere IP.
>
> Ecco la prima domanda: si può fare? ha senso oppure esistono soluzioni
> migliori?
>
> Grazie a tutti, saluti,
> Giuliano
>
>

Vlan, Debian, VPN, zoneminder,.....

[Giuliano Curti]

Ciao a tutti,

volevo riprendere una vecchia idea che richiede un allestimento di rete;
essendomi formato (si fa per dire) nell'epoca del "personal" computer, la
rete mi è ostica ed ho bisogno del vs aiuto.

L'ambiente software sarà Debian, o meglio Raspbian perché ho intenzione di
usare il Raspberry (+ ZoneMinder + OpenVPN / WireGuard) però i primi
problemi riguardano l'hardware, OT rispetto all'argomento della lista.
Provo a formulare i miei dubbi, nel caso non graditi bloccherò subito la
discussione :-) grazie della pazienza.

Il mio obiettivo è quello di costruire una rete locale che vede un host
(raspberry) e diverse periferiche (telecamere IP) cui intendo accedere da
remoto (PC e Mobile) tramite una VPN.

Per l'host pensavo di gestire una doppia lan per una serie di motivi:
1) credo di aver intravisto in rete che una lan non direttamente affacciata
all'esterno è più sicura (il problema sicurezza per i miei dati non è un
tabù, quindi diciamo che la questione è quasi accademica)
2) possibilità di usare l'hardware disponibile (dispongo di una saponetta
con sim dati).

Il tutto si traduce in un host (raspberry) collegato:
a) in wifi (prima rete lan) con la saponetta per l'accesso ad internet (su
cui far viaggiare la VPN)
b) in rete cablata (seconda rete lan) con uno switch POE al quale attaccare
le telecamere IP.

Ecco la prima domanda: si può fare? ha senso oppure esistono soluzioni
migliori?

Grazie a tutti, saluti,
Giuliano

Re: connessione alla lan con in mezzo una vpn

[Leandro Noferini]

Paolo Miotto  writes:


Il 26/07/21 19:58, Leandro Noferini ha scritto:

Io ho necessità di una vpn per poter avere un IP statico da una
connessione casalinga per non aver problemi con i servizi che 
non
vogliono IP residenziali (fondamentalmente l'email ma anche 
roba come

XMPP).


Purtroppo è vero, ci sono servizi che penalizzano gli ip 
assegnati agli utenti

residenziali.

Un serverino in cloud non è pensabile?


È quella cosa della mia "idea" che non lo rende una soluzione 
perseguibile.


L'idea del proxy esterno non mi piace gran che perché in ogni 
caso avrei
una parte fondamentale della mia rete al di fuori del mio 
controllo,

cosa che snaturerebbe la mia idea.



Posso capire questa tua obiezione, ma non capisco come il fatto 
di avere una vpn
fornita da terzi ti consenta un maggiore controllo sulla tua 
rete.


Come dice Marco, io percepisco la vpn solo come un "cavo" che mi 
collega
al resto di internet, servizio che non servirebbe se il mio 
provider

fornisse l'ip statico.

--
ciao
leandro

Re: connessione alla lan con in mezzo una vpn

[Marco Bodrato]

Il 2021-07-27 07:49 Paolo Miotto ha scritto:

Il 26/07/21 19:58, Leandro Noferini ha scritto:


L'idea del proxy esterno non mi piace gran che perché in ogni caso 
avrei

una parte fondamentale della mia rete al di fuori del mio controllo,



Posso capire questa tua obiezione, ma non capisco come il fatto di
avere una vpn fornita da terzi ti consenta un maggiore controllo sulla
tua rete.


Personalmente concordo con Leandro, la VPN può essere vista 
semplicemente come il cavo che ti connette al resto della rete, no? 
Permette magari di figurare altrove rispetto a dove si è, ma non 
impedisce di avere il pieno controllo di ciò che quel cavo collega al 
resto del mondo.


Ĝis,
m

Re: connessione alla lan con in mezzo una vpn

[Paolo Miotto]

Il 26/07/21 19:58, Leandro Noferini ha scritto:

Io ho necessità di una vpn per poter avere un IP statico da una
connessione casalinga per non aver problemi con i servizi che non
vogliono IP residenziali (fondamentalmente l'email ma anche roba come
XMPP).


Purtroppo è vero, ci sono servizi che penalizzano gli ip assegnati agli 
utenti residenziali.


Un serverino in cloud non è pensabile?




L'idea del proxy esterno non mi piace gran che perché in ogni caso avrei
una parte fondamentale della mia rete al di fuori del mio controllo,
cosa che snaturerebbe la mia idea.



Posso capire questa tua obiezione, ma non capisco come il fatto di avere 
una vpn fornita da terzi ti consenta un maggiore controllo sulla tua rete.



--

Mandi.

Paolo

Re: connessione alla lan con in mezzo una vpn

[Leandro Noferini]

Paolo Miotto  writes:

Ho ripensato un attimo alla tua situazione; tu non vuoi fare 
l'uso classico


[...]


con un proxy con ip statico.


Io ho necessità di una vpn per poter avere un IP statico da una
connessione casalinga per non aver problemi con i servizi che non
vogliono IP residenziali (fondamentalmente l'email ma anche roba 
come

XMPP).

L'idea del proxy esterno non mi piace gran che perché in ogni caso 
avrei
una parte fondamentale della mia rete al di fuori del mio 
controllo,

cosa che snaturerebbe la mia idea.

--
ciao
leandro

Re: connessione alla lan con in mezzo una vpn

[Paolo Miotto]

Ho ripensato un attimo alla tua situazione; tu non vuoi fare l'uso 
classico della vpn per proiettare i client sulla rete privata, ma la 
vuoi usare per proiettare un host privato sulla rete pubblica: sei 
sicuro che la vpn sia la soluzione migliore?


Se i client della vpn vengono nattati, allora tu perdi la visibilità 
della sorgente (ip) originale, e probabilmente non ti va bene.


Se i client della vpn non vengono nattati , allora tu devi rispondere 
all'ip originale, pubblico, da cui il default gateway verso l'uscita 
della vpn.


Io farei un pensierino ad un port forwarding, con un DDNS se possibile, 
oppure con un proxy con ip statico.



Il 22/07/21 16:32, Leandro Noferini ha scritto:


Quindi, riassumendo, io dovrei riuscire a raggiungere la rete locale da
quel computer ma devo riuscire a lasciare la default route sulla vpn.


Puoi provare a mantenere la config originale ed inserire una route 
statica per la tua rete privata:


route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.1.1 metric 50

dove 192.168.1.0/24 è la tua rete privata


Paolo

Re: connessione alla lan con in mezzo una vpn

[Leandro Noferini]

Paolo Miotto  writes:


Il 18/07/21 09:03, Leandro Noferini ha scritto:

/sbin/ip link set dev tun0 up mtu 1500
/sbin/ip addr add dev tun0 91.19.51.42/24 broadcast 
91.19.51.255

/sbin/ip route add 91.19.55.235/32 via 192.168.1.1
/sbin/ip route add 0.0.0.0/1 via 91.19.51.1
/sbin/ip route add 128.0.0.0/1 via 91.19.51.1



Se hai già commentato la linea "redirect-gateway" nel tuo file 
di configurazione

e ancora non funziona puoi provare ad inserire la linea


Ho provato a togliere quella riga ma poi (evidentemente?) non 
riesco a

raggiungere i servizi che ci sono su quell'IP da remoto.

Quindi, riassumendo, io dovrei riuscire a raggiungere la rete 
locale da
quel computer ma devo riuscire a lasciare la default route sulla 
vpn.


Spero di essere riuscito a spiegarmi.


pull-filter ignore "route add 0.0.0.0"


[...]


https://serverfault.com/questions/819339/openvpn-client-override-default-gateway-for-vpn-sever


--
Ciao
leandro

Re: connessione alla lan con in mezzo una vpn

[Paolo Miotto]

Il 18/07/21 09:03, Leandro Noferini ha scritto:

/sbin/ip link set dev tun0 up mtu 1500
/sbin/ip addr add dev tun0 91.19.51.42/24 broadcast 91.19.51.255
/sbin/ip route add 91.19.55.235/32 via 192.168.1.1
/sbin/ip route add 0.0.0.0/1 via 91.19.51.1
/sbin/ip route add 128.0.0.0/1 via 91.19.51.1



Se hai già commentato la linea "redirect-gateway" nel tuo file di 
configurazione e ancora non funziona puoi provare ad inserire la linea



pull-filter ignore "route add 0.0.0.0"


come descritto nella man page di openvpn. Non l'ho verificata, controlla 
i log per vedere se matcha correttamente.



Se usi NetworkManger nei pannelli di configurazione della openvpn c'è 
l'opzione per rifiutare il default gateway "usa questa connessione solo 
per le risorse della sua rete".



Una soluzione alternativa è quella di eseguire uno script che 
riconfigura le route dopo il collegamento come descritto in 
https://serverfault.com/questions/819339/openvpn-client-override-default-gateway-for-vpn-sever


--

Mandi.

Paolo

Re: connessione alla lan con in mezzo una vpn

[Leandro Noferini]

On gio, lug 15, 2021 at 09:29:30 +0200, Paolo Miotto wrote:
 
> Nella tua configurazione tutto il traffico viene dirottato nella vpn; spesso
> si fa così per garantire che il client, se compromesso, possa fare da ponte
> verso la rete protetta dalla vpn.
> 
> Tu vorresti fare uno split tunnel, quindi devi eliminare l'opzione
> 
> redirect-gateway
> 
> dalla tua configurazione.
> 
> 
> Devi poi verificare che route ti vengono inviate ed eventualmente rifiutarle
> e gestirle a mano.

Purtroppo di routing c'ho sempre capito meno del giusto e quindi avrei necessità
di un aiuto più preciso.

Nel log leggo queste righe:

/sbin/ip link set dev tun0 up mtu 1500
/sbin/ip addr add dev tun0 91.19.51.42/24 broadcast 91.19.51.255
/sbin/ip route add 91.19.55.235/32 via 192.168.1.1
/sbin/ip route add 0.0.0.0/1 via 91.19.51.1
/sbin/ip route add 128.0.0.0/1 via 91.19.51.1

Devo fare qualcosa qui?

-- 
Ciao
leandro

Re: connessione alla lan con in mezzo una vpn

[Leandro Noferini]

Marco Gaiarin  writes:


La speigazione di Paolo è perfetta; ma

Questa è la configurazione di openvpn che mi ha dato il 
provider:

[...]

pull


Io credo che il problema sia questo; con 'pull' tu ti prendi 
tutto quello

che il server ti dice, compreso suppongo del routing farlocco.




Puoi mandare dei log di connessione?


Allego.

Puoi vedere se il fornitore ha una pagina/faq/... con delle info 
più dettagliate?


Quello ho paura di no perché sto usando un provider che definirlo 
"scarno" è un eufemismo!


:-)

vpn.log==
OpenVPN 2.4.7 arm-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] 
[LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 28 2021

library versions: OpenSSL 1.1.1d  10 Sep 2019, LZO 2.10
TCP/UDP: Preserving recently used remote address: 
[AF_INET]91.19.55.235:443

Socket Buffers: R=[131072->131072] S=[16384->16384]
Attempting to establish TCP connection with 
[AF_INET]91.19.55.235:443 [nonblock]

TCP connection established with [AF_INET]91.19.55.235:443
TCP_CLIENT link local: (not bound)
TCP_CLIENT link remote: [AF_INET]91.19.55.235:443
TLS: Initial packet from [AF_INET]91.19.55.235:443, sid=e8271fcc 
f5cbaea7
WARNING: this configuration may cache passwords in memory -- use 
the auth-nocache option to prevent this
VERIFY OK: depth=1, C=CZ, ST=Ustecky Kraj, L=Usti nad Labem, 
O=FineVPN.com, OU=IT, CN=FineVPN.com CA, 
emailAddress=i...@finevpn.com

VERIFY KU OK
Validating certificate extended key usage
++ Certificate has EKU (str) TLS Web Server Authentication, 
expects TLS Web Server Authentication

VERIFY EKU OK
VERIFY X509NAME OK: C=CZ, ST=Ustecky Kraj, L=Usti nad Labem, 
O=FineVPN.com, OU=IT, CN=eu3.finevpn.com, 
emailAddress=i...@finevpn.com
VERIFY OK: depth=0, C=CZ, ST=Ustecky Kraj, L=Usti nad Labem, 
O=FineVPN.com, OU=IT, CN=eu3.finevpn.com, 
emailAddress=i...@finevpn.com
Control Channel: TLSv1.2, cipher TLSv1.2 
DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
[eu3.finevpn.com] Peer Connection Initiated with 
[AF_INET]91.19.55.235:443

SENT CONTROL [eu3.finevpn.com]: 'PUSH_REQUEST' (status=1)
SENT CONTROL [eu3.finevpn.com]: 'PUSH_REQUEST' (status=1)
SENT CONTROL [eu3.finevpn.com]: 'PUSH_REQUEST' (status=1)
PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 
8.8.8.8,dhcp-option DNS 8.8.4.4,topology subnet,route-gateway 
91.19.51.1,ifconfig 91.19.51.42 255.255.255.0'

OPTIONS IMPORT: --ifconfig/up options modified
OPTIONS IMPORT: route-related options modified
OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Outgoing Data Channel: Cipher 'AES-256-CBC' initialized with 256 
bit key
Outgoing Data Channel: Using 160 bit message hash 'SHA1' for HMAC 
authentication
Incoming Data Channel: Cipher 'AES-256-CBC' initialized with 256 
bit key
Incoming Data Channel: Using 160 bit message hash 'SHA1' for HMAC 
authentication
ROUTE_GATEWAY 192.168.1.1/255.255.255.0 IFACE=eth0 
HWADDR=dc:a6:32:cb:d2:d5

TUN/TAP device tun0 opened
TUN/TAP TX queue length set to 100
/sbin/ip link set dev tun0 up mtu 1500
/sbin/ip addr add dev tun0 91.19.51.42/24 broadcast 91.19.51.255
/sbin/ip route add 91.19.55.235/32 via 192.168.1.1
/sbin/ip route add 0.0.0.0/1 via 91.19.51.1
/sbin/ip route add 128.0.0.0/1 via 91.19.51.1
Initialization Sequence Completed
vpn.log==

--
ciao
leandro

Re: connessione alla lan con in mezzo una vpn

[Marco Gaiarin]

Mandi! Leandro Noferini
  In chel di` si favelave...


La speigazione di Paolo è perfetta; ma

> Questa è la configurazione di openvpn che mi ha dato il provider:
[...]
> pull

Io credo che il problema sia questo; con 'pull' tu ti prendi tutto quello
che il server ti dice, compreso suppongo del routing farlocco.


Puoi mandare dei log di connessione? Puoi vedere se il fornitore ha una
pagina/faq/... con delle info più dettagliate?

-- 
  È come se Mendeleev quando ha scoperto gli elementi, il giorno che ha
  scoperto l'ossigeno avesse detto: "benissimo, ho scoperto l'ossigeno, chi
  respira mi paga una royalty"... chi respira paga, pensa a Genova che
  casino, morivano tutti in apnea.  (Beppe Grillo)

Re: connessione alla lan con in mezzo una vpn

[Paolo Miotto]

Il 02/07/21 12:32, Leandro Noferini ha scritto:

La situazione del router è una cosa come questa:

admin@server:~$ ip r 0.0.0.0/1 via 94.190.57.1 dev tun0 default via 
192.168.1.1 dev eth0 proto dhcp src 192.168.1.125 metric 202 
94.190.57.0/24 dev tun0 proto kernel scope link src 94.190.57.54 
94.190.58.253 via 192.168.1.1 dev eth0 128.0.0.0/1 via 93.190.51.1 dev 
tun0 192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.125 
metric 202


Con questa configurazione non riesco a raggiungere dei servizi 
presenti sulla rete locale (come ad esempio un log server) se non 
fermando la vpn, collegandomi al servizio e poi riattivare la vpn.




Nella tua configurazione tutto il traffico viene dirottato nella vpn; 
spesso si fa così per garantire che il client, se compromesso, possa 
fare da ponte verso la rete protetta dalla vpn.


Tu vorresti fare uno split tunnel, quindi devi eliminare l'opzione

redirect-gateway

dalla tua configurazione.


Devi poi verificare che route ti vengono inviate ed eventualmente 
rifiutarle e gestirle a mano.



--

Mandi.

Paolo

Re: connessione alla lan con in mezzo una vpn

[Leandro Noferini]

Marco Gaiarin  writes:


Mandi! Leandro Noferini
  In chel di` si favelave...


admin@server:~$ ip r


[...]


al servizio e poi riattivare la vpn.


Non so dirti perchè è così (non capisco la configurazione di
openvpn...)


Cosa ti devo inviare per aiutarti?

Questa è la configurazione di openvpn che mi ha dato il provider:

=
proto tcp-client

remote provider.conf 443 # non-stadard port for OpenVPN
dev tun

ignore-unknown-option ip-win32 dynamic 0
ip-win32 dynamic 0

nobind
persist-key

tls-client
remote-cert-tls server
verify-x509-name provider.com name

verb 3

cipher AES-256-CBC
auth SHA1
pull

auth-user-pass provider-pass.txt


[...]

-END CERTIFICATE-

=


ma quello che posso dire è che hai un routing parecchio strano.


Già, era un sospetto che mi era balenato :-)

Ma come ti dicevo, purtroppo di routing non ci capisco niente e 
quindi

mi arrendo presto.

Hai il default routing sulla LAN ma con metrica ('peso'; vince 
il peso più


[...]


192.168.1.0/24.


Quindi il default-route becca tutto.

--
ciao
leandro

Re: connessione alla lan con in mezzo una vpn

[Marco Gaiarin]

Mandi! Leandro Noferini
  In chel di` si favelave...

> admin@server:~$ ip r
> 0.0.0.0/1 via 94.190.57.1 dev tun0
> default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.125 metric 202
> 94.190.57.0/24 dev tun0 proto kernel scope link src 94.190.57.54
> 94.190.58.253 via 192.168.1.1 dev eth0
> 128.0.0.0/1 via 93.190.51.1 dev tun0
> 192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.125 metric 202
> 
> Con questa configurazione non riesco a raggiungere dei servizi presenti sulla
> rete locale (come ad esempio un log server) se non fermando la vpn, 
> collegandomi
> al servizio e poi riattivare la vpn.

Non so dirti perchè è così (non capisco la configurazione di openvpn...) ma
quello che posso dire è che hai un routing parecchio strano.

Hai il default routing sulla LAN ma con metrica ('peso'; vince il peso più
basso) alta:

default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.125 metric 202

e anche il routing della LAN ha metrica alta:

192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.125 metric 
202

e poi hai questi due routing:

0.0.0.0/1 via 94.190.57.1 dev tun0
128.0.0.0/1 via 93.190.51.1 dev tun0

che assieme fanno 'tutto':

gaio@hermione:~$ sipcalc 0.0.0.0/1
-[ipv4 : 0.0.0.0/1] - 0

[CIDR]
Host address- 0.0.0.0
Host address (decimal)  - 0
Host address (hex)  - 0
Network address - 0.0.0.0
Network mask- 128.0.0.0
Network mask (bits) - 1
Network mask (hex)  - 8000
Broadcast address   - 127.255.255.255
Cisco wildcard  - 127.255.255.255
Addresses in network- 2147483648
Network range   - 0.0.0.0 - 127.255.255.255
Usable range- 0.0.0.1 - 127.255.255.254

-
gaio@hermione:~$ sipcalc 128.0.0.0/1
-[ipv4 : 128.0.0.0/1] - 0

[CIDR]
Host address- 128.0.0.0
Host address (decimal)  - 2147483648
Host address (hex)  - 8000
Network address - 128.0.0.0
Network mask- 128.0.0.0
Network mask (bits) - 1
Network mask (hex)  - 8000
Broadcast address   - 255.255.255.255
Cisco wildcard  - 127.255.255.255
Addresses in network- 2147483648
Network range   - 128.0.0.0 - 255.255.255.255
Usable range- 128.0.0.1 - 255.255.255.254

-

a metrica più bassa, quindi vincono loro, e comprendono anche
192.168.1.0/24.

-- 
  Il problema è che, in questa epoca di grande comunicazione globale,
  quando ti fa male il culo non è per le emorroidi...   (Beppe Grillo)