Assistenza remota simil Team Viewer

[xinyiman]

C'è una cosa che non capisco. Ipotizziamo che ho i due client che si sono già scambiati le informazioni tramite il controller. Ipotizziamo che il client A abbia un indirizzo ip 23.6.141.2 e porta 5000 mentre il client B ha un indirizzo 35.7.121.15 e porta 1926.

Il client A inizia a mandare pacchetti all'indirizzo 35.7.121.15:1926
Il client B inizia a mandare pacchetti all'indirizzo 23.6.141.2:5000

poi ognuno dei client si mette in ascolto e riceve i pacchetti che aveva mandato.
Il client A riceve i pacchetti generati da 35.7.121.15:1926
Il client B riceve i pacchetti generati da 23.6.141.2:5000

Ma non capisco come questo possa accadere.

[nomorelogic]

non so se ho capito il problema ma ci provo

quando dici "si sono già scambiati le informazioni" intendi in passato ed ora ci riprovano con gli stessi parametri?

perché se è così è chiaro che non funziona, quello che chiami "controlloer" stabilisce una comunicazione sia con A che con B e questo gli permette di avere le autorizzazioni per passare attraverso i vari firewall

quindi il tunnel è valido solo finché non si chiude quella comunicazione: se serve un'altra comunicazione serve un altro intervento del controller

spero di aver interpretato bene la tua domanda

[xinyiman]

Ciao a tutti. Penso di aver capito il problema. Il mio programma funziona, il problema è che il mio NAT è di tipo bidirezionale.
In un tipo di nat non bidirezionale quando il client A si collega al controller comunica ip e porta che verranno comunicate al client B e tutto funzionerà, perchè il client A userà sempre quell'ip e quella porta.
In un nat bidirezionale la porta comunicata al controller è diversa da quella usata per il P2P con il client B. Ora ci ho ragionato un pochino, e sembrerebbe che ho solo due strade.

1. Il client A fa una scansione completa delle porte del client B fino a quando non riesco ad accoppiare le comunicazioni tra i client.
2. Chiedo al router la tabella NAT per le mie connessioni verso l'esterno (non ho idea di come si faccia)

Chiedo se secondo voi ci sono strade alternative o se mi aiutate a realizzare il punto 2.

Grazie mille

[xinyiman]

Ovviamente nel caso dovessi "scansionare le porte", partirei da quelle vicine a quelle usate per la comunicazione con il controller. Però non è detto che apra le porte in maniera consecutiva.

[nomorelogic]

la scansione delle porte non mi pare onestamente una buona soluzione

intanto la domanda:
perché non è praticabile che B risponda sullo stesso socket da cui riceve i messaggi di A?


cmq per evitare la scansione, così come A comunica al controller IP e porta che poi verranno consegnate a B
allo stesso modo B potrebbe dare i propri IP e porta al controller in modo che li possa girare ad A

qualcosa di simile alle stanza delle chat insomma
A, B e chiunque altro possono entrare in comunicazione grazie all'ID di una stanza che poi è la chiave per scambiarsi IP/Porta

[xinyiman]

la scansione delle porte non mi pare onestamente una buona soluzione

intanto la domanda:
perché non è praticabile che B risponda sullo stesso socket da cui riceve i messaggi di A?


cmq per evitare la scansione, così come A comunica al controller IP e porta che poi verranno consegnate a B
allo stesso modo B potrebbe dare i propri IP e porta al controller in modo che li possa girare ad A

qualcosa di simile alle stanza delle chat insomma
A, B e chiunque altro possono entrare in comunicazione grazie all'ID di una stanza che poi è la chiave per scambiarsi IP/Porta

Infatti la scansione non è praticabile per lentezza, era solo una ipotetica soluzione concettuale.
Allo stato attuale già faccio quello che dici

Il client A comunica con il controller che si salva il suo indirizzo ip e le sue porte
Il client B comunica con il controller che si salva il suo indirizzo ip e le sue porte
Il client A chiede i dati del client B al controller, che ovvimente le restituisce
Il client B chiede i dati del client A al controller, che ovvimente le restituisce

A prova a mandare dei pacchetti verso B
B prova a mandare dei pacchetti verso A

Sfortunatamente a casa mia non funziona se il controller è su internet, fortunatamente funziona se il controller si trova nella rete locale. Quindi questo porta a pensare due cose

1. Il mio router di casa (vodafone station revolution) adotta un NAT bidirezionale (che fa si che le porte vengono cambiate in funzione dell'endpoint, a prescindere dalla sorgente).

2. Sbaglio qualcosa io

Onestamente non so più dove sbattere la testa. Questa sera sul tardi se riesco, riaggiorno i sorgenti e "chiedo aiuto dal pubblico a casa".

[nomorelogic]

Sfortunatamente a casa mia non funziona se il controller è su internet, fortunatamente funziona se il controller si trova nella rete locale.

hai pensato al fatto che se il controller è su internet mentre A e B sono sulla stessa lan, il controller deve:
- passare ad A l'indirizzo di B dove l'IP è interno alla lan
- passare a B l'indirizzo di A dove l'IP è interno alla lan


esempio:
A in una lan ha IP 192.168.1.150 e porta 1234
B stessa lan ha IP 192.168.1.151 e porta 6789

A comunica con il controller e il controller registra l'indirizzo pubblico, esempio 79.124.28.125 porta 456
B comunica con il controller e il controller registra l'indirizzo pubblico, esempio 79.124.28.125 porta 741

se il controller deve mettere in comunicazione A e B, visto che questi 2 sono nella stessa lan deve:
- trasmettere ad A che B lo trova con IP 192.168.1.151 e porta 6789
- trasmettere a B che A lo trova con IP 192.168.1.150 e porta 1234


quindi il controller deve, per ogni client, conoscere sia IP/Porta pubblici che interni alla rispettiva LAN

detto questo potrebbe essere il firewall della vodafone 

[xinyiman]

Sfortunatamente a casa mia non funziona se il controller è su internet, fortunatamente funziona se il controller si trova nella rete locale.

hai pensato al fatto che se il controller è su internet mentre A e B sono sulla stessa lan, il controller deve:
- passare ad A l'indirizzo di B dove l'IP è interno alla lan
- passare a B l'indirizzo di A dove l'IP è interno alla lan


esempio:
A in una lan ha IP 192.168.1.150 e porta 1234
B stessa lan ha IP 192.168.1.151 e porta 6789

A comunica con il controller e il controller registra l'indirizzo pubblico, esempio 79.124.28.125 porta 456
B comunica con il controller e il controller registra l'indirizzo pubblico, esempio 79.124.28.125 porta 741

se il controller deve mettere in comunicazione A e B, visto che questi 2 sono nella stessa lan deve:
- trasmettere ad A che B lo trova con IP 192.168.1.151 e porta 6789
- trasmettere a B che A lo trova con IP 192.168.1.150 e porta 1234


quindi il controller deve, per ogni client, conoscere sia IP/Porta pubblici che interni alla rispettiva LAN

detto questo potrebbe essere il firewall della vodafone 

Ho pensato anche a questo, ma per il momento voglio evitarlo. Voglio poter uscire e rientrare dalla rete locale. Così da testare il caso peggiore. Ovvero i due client sono dietro una NAT. Ieri sera ho iniziato a creare un test scorporato dal progetto originale. Così da semplificare il debug e capire cosa sbaglio. Questa sera (o in pausa pranzo) lo finisco e poi lo posto. Così magari qualche anima pia mi aiuta a capire cosa sbaglio.
PS: quando ho fatto il test il firewall della vodafone lo avevo disabilitato.

[nomorelogic]

Ho pensato anche a questo, ma per il momento voglio evitarlo. Voglio poter uscire e rientrare dalla rete locale. Così da testare il caso peggiore. Ovvero i due client sono dietro una NAT.

Sel la lan è la stessa non so se è possibile.
Nel senso che se tu esci dal tuo IP pubblico per rientrare nel tuo IP pubblico, penso sia una cosa che non si possa proprio fare.
Forse mi sbaglio ma ora ho questa convinzione.
Potresti provare installando un apache, pubblichi la porta e poi apri un browser in lan ma cerchi di raggiungere apache con l'IP pubblico.


Secondo me devi proprio lavorare con 2 IP pubblici diversi altrimenti rischi di perdere tempo.

[xinyiman]

No perchè un client lo fai uscire su una porta e il secondo su un'altra porta.

[nomorelogic]

infatti nell'esempio che ti ho mandato l'IP pubblico è lo stesso ma le porte sono diverse

però sempre che A esce da un IP pubblico e deve rientrare nello stesso (e lo stesso deve fare B)
per fare una cosa del genere forse serve configurare un loopback ma non è una condizione che trovi normalmente

[xinyiman]

infatti nell'esempio che ti ho mandato l'IP pubblico è lo stesso ma le porte sono diverse

però sempre che A esce da un IP pubblico e deve rientrare nello stesso (e lo stesso deve fare B)
per fare una cosa del genere forse serve configurare un loopback ma non è una condizione che trovi normalmente

Farò delle prove al riguardo. Nel frattempo ho finito il programma di test.

Per capire come funziona il programma seguite questi punti (prima in locale, poi su 3 pc diversi della rete lan e infine spostando il controller fuori dalla lan)

1. Avviare l'eseguibile del controller che risponderà con qualcosa di simile

UDP Hole Punching Controller
MAX_CONNECTIONS: 100
MAX_INACTIVE_MS: 30000
SOURCE_PORT: 1985
PWD:

2. Avviare una istanza del client ed impostare l'indirizzo ip del controller nel campo identificato come "Controller IP:" che di default è 127.0.0.1

3. Avviare una seconda istanza del client ed impostare l'indirizzo ip del controller nel campo identificato come "Controller IP:" che di default è 127.0.0.1 e successivamente cliccare sul check "Invert"

4. Sull'istanza 1 del client cliccare sul pulsante "Start conn" che restituirà un id nel campo memo (Es: 1qhlUQ)

5. Sull'istanza 2 del client cliccare sul pulsante "Start conn" che restituirà un id nel campo memo (Es: NnGLQ8)

6. Inserite nel campo "Remote id session:" dell'istanza 1 l'id dell'istanza 2 (Es: NnGLQ8)

7. Inserite nel campo "Remote id session:" dell'istanza 2 l'id dell'istanza 1 (Es: 1qhlUQ)

8. Su entrambe le istanza cliccate sul pulsante "Start P2P"

Se funziona tutto dovreste trovarvi un lista di messaggi inviati e ricevuti nella memo di entrambe le istanze

Es.

ControllerMyId  :A
ControllerIp    :127.0.0.1
ControllerPort  :4999
ControllerTS    :0
127.0.0.1:4999 --> A msg_1
127.0.0.1:4999 <-- B msg_1
127.0.0.1:4999 --> A msg_2
127.0.0.1:4999 <-- B msg_2
127.0.0.1:4999 --> A msg_3
127.0.0.1:4999 <-- B msg_3
127.0.0.1:4999 --> A msg_4
127.0.0.1:4999 <-- B msg_4
127.0.0.1:4999 --> A msg_5
127.0.0.1:4999 <-- B msg_5
127.0.0.1:4999 --> A msg_6
127.0.0.1:4999 <-- B msg_6
127.0.0.1:4999 --> A msg_7
127.0.0.1:4999 <-- B msg_7
127.0.0.1:4999 --> A msg_8
127.0.0.1:4999 <-- B msg_8
127.0.0.1:4999 --> A msg_9
127.0.0.1:4999 <-- B msg_9
127.0.0.1:4999 --> A msg_10
127.0.0.1:4999 <-- B msg_10

Ovviamente se eseguite tutti e tre i programmi sullo stesso computer non dovete cambiare neanche il Controller IP delle due istanze, lasciatelo a 127.0.0.1

[nomorelogic]

provato poco fa in locale su win e funziona
in giornata farò altre prove

[nomorelogic]

mi è tornato in mente questo vecchio thread
xinyiman, ci sono state evoluzioni?

[DragoRosso]

Siccome sono diverse pagine di post, un sunto sintetico sarebbe utile ....

Ok...me lo sono letto tutto, senza scaricare o provare alcunchè.

Progetto interessantissimo, anche perchè faccio uso giornaliero di teleassistenza (non uso TeamViewer che genera problemi con le applicazioni che faccio ma uso AnyDesk).

Mi pare di capire che siano state esplorate tutte le problematiche e più o meno risolte, a parte forse la connessione tramite Internet.

I sistemi di teleassistenza, così come anche i sistemi vari simili come accessi agli impianti di videoregistrazione, allarmi, etc ... fanno tutti uso di server esterni. Senza un server esterno non è possibile in generale creare un sistema di teleassistenza flessibile.

Principalmente i motivi sono:

1) presenza di firewall che impediscono l'accesso dall'esterno;

2) impossibilità di effettuare un NAT, a parte in poche situazioni;

3) impossibilità dell'uso di UPNP in impianti aziendali, tecnologia che consente di aprire in automatico le porte di un firewall e/o router;

4) uso di connessioni mobili che non consentono in alcun modo di poter essere configurate ne con DDNS ne possono essere raggiungibili da chichessia.

In particolare la principale funzionalità è quella della connessione a richiesta e questo è possibile solo tramite un server stabile in Internet (o comunque raggiungibile da Internet).

In pratica, il client su cui portare assistenza dovrebbe avere libero accesso ad Internet tramite le classiche porte 80 o 443, stabilisce una connessione UDP con il server per "ascoltare" eventuali richieste di assistenza e in caso ci siano viene instaurata la connessione tramite il server stesso con il client che fornirà assistenza.

La connessione dovrà per forza passare tramite il server per i motivi sopra citati.

Poi oltre la connessione, usare i JPEG per la comunicazione non è il massimo perchè il carico di lavoro di compressione / decompressione di un monitor ad esempio a 4K non è così ininfluente.

Si dovrebbe usare qualche algoritmo di compressione tipico dei compressori video secondo me, come se ci fosse un flusso video tra un client e l'altro (e ciò potrebbe aiutare a trasportare facilmente anche l'eventuale audio).