[MontelLUG] IP pubblico o VPS + VPN?

[Samuele]

Il 16/12/2016 09:07, Odeeno via montellug ha scritto:
> Il 16/12/2016 06:22, Stefano Fraccaro via montellug ha scritto:
>> Teamviewer VPN?

Anche no grazie. Qualche volta mi tocca usarlo (nella sola modalità alla 
vnc), ma lo evito il più possibile.
E' indubbio che è uno strumento a prova di utonto, ma sapere che i miei 
dati o di clienti, viaggiano su server di terze parti non mi piace.

Quello che trovo assurdo è che nessuno abbia fatto un proxy per vnc open 
che installi tu su un tuo server su ip pubblico, dove i tuoi client si 
collegano, tu vedi la lista dei client collegati e decidi a quale 
collegarti.

>> Ipotizzando che client e server siano nattati l'unica cosa che mi viene
>> in mente è UDP con server di mediazione (come trasporto) se vuoi una
>> connessione diretta
> mmm... soluzione interessante; riesci a spiegare come fare?

Come accennavo ieri sera, il tutto si basa sul protocollo UDP.
Per rimanere breve, devo tagliare con la motosega parti della 
spiegazione. Se volete approfondire, dovete studiarvi il funzionamento 
di TCP, UDP ed il connection trackin del firewall di linux.
Diamo per scontato che sapete come funziona il NAT per bene.
Partiamo dal fatto che ogni socket ad entrambi i lati della connessione 
deve aprire una porta per riuscire a inviare e ricevere i dati.
Con TCP, se tu dal tuo pc devi collegarti alla porta 22 di un server, il 
tuo pc apre una porta a caso (tipicamente ci sono un paio di parametri 
nel kernel che specificano in quale range, ora non ricordo il nome) es.: 
22334, mentre il server è in ascolto sulla porta 22. Quando tu invii un 
pacchetto dati, questo parte dalla porta 22334 e arriva alla porta 22 
del server. Quando il server ti risponde, parte dalla sua porta 22 e 
arriva alla tua porta 22334.
Un eventuale router con nat in mezzo, va a sostituire sul pacchetto in 
uscita dalla tua rete, il tuo indirizzo ip e la porta sorgente con il 
suo. Idem quando riceve un pacchetto dal server fa il contrario.
In una connessione TCP, tra le altre cose, ogni pacchetto è numerato in 
modo da poter ritrasmettere quelli persi e garantirne il corretto ordine 
di arrivo.
Per una terza parte che volesse intrufolarsi in una connessione TCP 
esistente, non è banale.
UDP, non gestisce lo stato della connessione, il pacchetto è 
unidirezionale. Il protocollo non prevede che chi riceve un pacchetto 
possa mandare indietro una risposta. Per farlo, bisogna che anche il 
client abbia un socket in modalità server in ascolto (cosa non 
necessaria con TCP, dove bastava un solo socket lato client).
Come fa allora un povero router nat a fare il connection tracking di 
traffico udp? Nel caso di linux tiene una tabella (se non ricordo male) 
con ip sorgente, ip destinazione, porta (forse anche porta sorgente, non 
ricordo, sono passati anni).
Quindi, un secondo server, che volesse rispondere al client basta che 
spedisca all'indirizzo del router nat un pacchetto che corrisponda con 
porta di destinazione ed ip.
Il client dietro alla lan non ha nessun modo di sapere da quale dei due 
server è arrivato il pacchetto, visto che non c'è nessun numero di 
sequenza o altro (la sicurezza del tutto è lasciata all'applicativo 
finale a L7).

Quindi, questa ultima caratteristica può essere utilizzata da un 
software per stabilire delle connessioni nattate da entrambe le parte. 
Si inviano periodicamente dei pacchetti "punch hole" per imbrogliare il 
router/nat in modo che questo accetti i pacchetti in ingresso, così 
l'altro endpoint della connessione può sparare i dati. Facendo questo da 
entrambe le parti, riesci a stabilire una connessione bidirezionale.

Questa tecnica era usata agli albori di skype per non sovraccaricare i 
server.

Esiste un software pwnat che dovrebbe permettere di fare questo. Non ho 
mai avuto necessità modo di provarlo. Se qualcuno vuole e poi posta 
l'esperienza tanto meglio.

>      > Per un side project, per un
>      > periodo ho preso un VPS su
>      > Arubacloud
>
>      In effetti molto interessante per un progetto, prototipo o simile.
>      Il problema privacy è molto,rilevante, però. :-)

Sni.
E' ovvio che su una macchina qualsiasi dove non è sotto tuo stesso 
controllo l'accesso fisico (al limite con l'apertura del case a macchina 
accesa collegata a dell'esplosivo) non può essere considerata sicura.
Detto questo, in questa situazione è un falso problema, sia che tu abbia 
un ip pubblico o privato, la tua zona sicura (posto che secondo alcuni 
anche la lan è una zona non sicura), termina sul tuo router/fw.
Basta considerare il traffico che proviene dalla vps come insicuro.
Cioè, utilizzi una vpn, eventualmente anche senza crittografia per avere 
un ip della tua lan raggiungibile all'esterno.
Tanto, che sia dopo il router, o dopo la vps, comunque i tuoi dati 
saranno esposti sulla internet brutta e cattiva, quindi una buona 
crittografia la devi usare comunque (o con il protocollo che usi per 
accedere alla tua applicazione o con un'altra vpn (attestata sul tuo 
dispositivo mobile e un pc dentro alla tua lan) che viaggia dentro alla 
vpn che invece fa capo alla vps.


>
>      > Se il tuo unico problema avere
>      > un URL fisso per poterci
>      > accedere comodamente, un
>      > simil-dyndns?
>
>      Potrebbe essere sufficiente.
>
>      Ma con dyndns arriverei all'IP pubblico dell'ISP: come giro i
>      pacchetti verso l'IP del mio modem?

Non puoi.
Ecco, nel tuo caso, hai un doppio nat da un lato, non saprei se pwnat 
sia in grado di gestirlo.

> La domanda che però mi son continuato a fare è: non si può avere
> dall'ISP un IPv6? Un paio di anni fa non ho trovato chi lo fornisse
> (forse TIM): non so ora.
> Possibile che a distanza di tutti questi anni non si affermi come standard?

Guarda, nel 2000, durante la naja, mi ero preso un manuale di tcp/ip per 
imparare come funzionava. La versione inglese originale, se non erro era 
del 1997. Li dicevano che nel giro di qualche anno si sarebbe per forza 
passati ad ipv6. Siamo alle porte del 2017, sono passati vent'anni.
Aver fatto la transizione prima del 1998-2000 (quando è iniziata 
l'esplosione di internet), richiedeva un certo sforzo, ora è di diversi 
ordini di grandezza superiore.
Purtroppo ipv6 introduce casini:
- gli operatori devono cambiare apparati, dai router di casa a quelli 
sulle backbone (e qui forse ormai ci siamo);
- la struttura logica (attribuzione di indirizzi, routing ecc.) va 
gestita sia per ipv6 che ipv4, quindi lavoro in più;
- ipv6, non è solo un più ampio range di indirizzi, ma lavora anche in 
modo diverso da quanto fa ipv4;
- gli applicativi software vanno adeguati: non tutti i software, specie 
quelli più vecchi, ma anche roba nuova, supportano ipv6;
- pigrizia e mancanza di tempo in generale: con mille cose da fare ipv6 
può aspettare :-D;
- il fatto di gestire una rete mista, quindi dei meccanismi di 
transizione tra apparati solo ipv4, verso altri ipv6, sta incasinando il 
tutto;
- sentivo conoscenti che ad esempio sui server di posta hanno problemi a 
consegnarla su ipv6 per via di politiche antispam molti più aggressive;
- infine, da lato dei provider, quando tutto sarà ipv6, come faranno a 
venderti ancora a caro prezzo gli ip statici e/o pubblici sui quali 
adesso lucrano ingiustamente?

Io per un po' ho provato il tunnel Sixxs per vedere come andava, 
purtroppo la connessione era lentissima, quindi ad un certo punto ho 
dovuto disabilitarlo, visto che di default gli applicativi in presenza 
del doppio stack vanno su ipv6 di default.

Ritornando al discorso privacy e ipv6, che nasce per favorire l'IoT, mi 
vien male (o terrorizza se preferite) pensare che ci sarà gente che 
utilizzerà, dal termostato, tv, bilancia, tostapane, caffettiera, 
sveglia, letto tutto smart, ma dove il software di gestione invece che 
girare su un computer dentro casa, girerà obbligatoriamente su un server 
da qualche parte, gestito da chissà chi.
Un giorno forse rimpiangeremo il microonde od il frullatore stupido che 
nessuno più produrrà per quei quattro nerd paranoici rimasti? Ho la vaga 
sensazione di si...