Newsgroup: it.comp.reti.locali
Titolo: Accedere ad un HTTP server dietro NAT ma senza port-forwarding

Ho una Linux box (è un sistema embedded dove posso metterci le mani) con 
un HTTP server con una serie di pagine Web e risorse. Questa Linux box 
si trova dietro un router casalingo.
 
Si accede tranquillamente tramite browser su rete locale, ma io vorrei 
accedere da remoto, però non usando il classico sistema del 
port-forwarding e DDNS.
Questo perché avrò decine di queste box e le persone che le useranno non 
capiscono nulla di queste configurazioni, deve essere un sistema 
plug-and-play.
 
Stavo pensando di metter su un server HTTP pubblico su Cloud (tipo su 
AWS). I web client accederanno al cloud ad indirizzi del tipo:
 
 
https://miocloud.it/dev-123456/index.html
 
 
Il server su Cloud dovrebbe essere in grado di girare questa richiesta, 
comportandosi tipo un proxy, alla Linux box che si chiama 123456. 
Chiaramente non può farlo direttamente perché la box si trova dietro 
router e il suo HTTP server è irraggiungibile da fuori.
 
Allora pensavo di configurare la Linux box in modo che apra una sorta di 
canale tunnel verso il server Cloud... potrebbe essere una VPN?
A questo punto il server Cloud potrebbe tranquillamente accedere al 
server della Linux box e fare da proxy.
 
In soldoni sul server Cloud dovrei installare un HTTP proxy ed un server 
VPN che gestirà decine di connessioni VPN verso ogni Linux box.
Ogni box collegato tramite VPN sarà contattabile dal server Cloud con un 
indirizzo IP tipo 10.x.x.x. Quindi il server Cloud saprà che il device 
123456 è collegato e contattabile su 10.1.2.3 (per esempio).
 
Quindi l'HTTP proxy dovrà convertire l'indirizzo
 
 
https://miocloud.it/dev-123456/index.html
 
 
in
 
 
http://10.1.2.3/index.html
 
 
 
E' fattibile? Esiste una soluzione più semplice secondo voi?

 E' fattibile? Esiste una soluzione più semplice secondo voi?
 
fattibile è sicuramente fattibile. Il problema è trovare il metodo
ottimizzato per farlo con decine di apparati.
Puoi anche pensare di non reindirizzare il traffico ma di caricare i
dati dall'apparato remoto e presentarlo direttamente dal webserver in
cloud.
 
 
 
-- 
MirkoB.   
ne...@bsi-net.it
 
Motoretta BMW R1200R Lightgrey
 
L'indirizzo ema@il non è da considerarsi pubblico,
ma utilizzabile solo per temi inerenti il NG corrente

 cloud.
 
Pensa ad uno scenario in cui devi distribuire decine di box diverse 
(ognuna con un set di pagine web diverse). E magari nel tempo queste 
pagine cambiano con gli aggiornamenti firmware.
 
Con questa soluzione dovresti tenere sul server tutte queste possibilità.
 
Inoltre mi piaceva l'idea di una soluzione "universale" dove messo su il 
cloud una volta, non lo tocchi praticamente più (devi solo manutenere la 
lista dei box autorizzati con i loro certificati).
Quando esce una nuova box con un set completamente diverso di pagine, 
sul Cloud non devi fare nulla.
 

 server della Linux box e fare da proxy.
 
dai un'occhiata ad stunnel
 
https://www.stunnel.org/
 
 
potrebbe fare al tuo caso
 

 come posso risolvere questa cosa?
 
se non hai un DNS interno alla LAN, potresti semplicemente inserire una
voce nel file hosts che faccia puntare il tuo FQDN all'IP del server
 
 

 è il modem il problema, ma non so come risolverlo...
 
beh, bisognerebbe risolvere questo
 
"da dentro la LAN devo accedere con l'IP al server perché se uso
il FQDN va in loop e non capisco cosa lo blocchi, mentre da fuori
accedo senza problemi in https"
 
Fammi capire, il server è in LAN o al di fuori della stessa ?
 
Inoltre, se provi ad interrogare il DNS per ottenere l'IP del server,
lo stesso è identico in LAN e fuori o è diverso ?
 
 
 
 

 Il DNS interno è uguale per tutti: 192.168.1.1 (ovvero il modem)
 
ecco il problema; supponi che l'indirizzo pubblico (WAN) sia
99.88.77.66 e che il tuo FQDN sia 
pippo.dyndns.com
, se un qualsiasi
utente da internet immettesse l'URL 
https://pippo.dyndns.com
 nel suo
browser, il nome host verrebbe risolto in 99.88.77.66 e la richiesta
verrebbe inviata all'interfaccia WAN del tuo router che inoltrerebbe la
stessa al server 192.168.1.x; sin qui, nessun problema
 
ora veniamo ad un client sulla rete interna, se il DNS è il router,
questo sarà configurato come forwarder, ossia le richieste per la
risoluzione DNS inviate dai client a 192.168.1.1 verranno da questo
inoltrate ai DNS esterni (del provider o quelli configurati sul router)
e la risposta di tali DNS verrà ritornata al client... e qui casca
l'asino :D
 
Un client dalla LAN immette l'URL 
https://pippo.dyndns.com
 il browser
interroga il DNS (192.168.1.1) per ottenere l'indirizzo IP del server
"pippo", il router inoltra la richiesta al DNS esterno e la risposta
che ritorna da questo è 99.88.77.66 ossia... l'indirizzo della scheda
WAN del router
 
a questo punto il client tenta di contattare 99.88.77.66, il router si
vede arrivare da un IP LAN una richiesta di connessione verso l'IP
della propria interfaccia WAN ... e si incastra tutto
 
Ci sono varie soluzioni al problema
 
La prima, se il router lo permette, è inserire un host statico in modo
che le richieste di risoluzione per 
pippo.dyndns.com
 ritornino l'IP
192.168.1.X ossia l'IP LAN del webserver
 
La seconda, se il router non ha questa possibilità è quella di
installare in rete un DNS forwarder come ad esempio DNSmasq,
configurare tale DNS per inoltrare le richieste al router e poi
aggiungere a DNSmasq un mapping statico in modo che le richieste per
"pippo..." vengano risolte con 192.168.1.X a questo punto dovrai
configurare i client in modo da usare come DNS l'IP del sistema sul
quale hai installato DNSmasq e NON l'IP del router
 
La terza ed ultima possibilità è quella di modificare su TUTTI i client
il file "hosts" inserendo un mapping come quello già visto nei due casi
sopra, siccome il file "hosts" viene consultato PRIMA di avviare la
risoluzione tramite DNS, i client di rete otterranno a questo punto il
corretto IP LAN del server "pippo"
 
spero sia chiaro
 
 
 
 
 
 
 
 
 
 
 
 
 

 sembra un inutile (quasi) incatastamento...
 
beh, sarà anche un "incatastamento", ma il router ha solo un "DNS
forwarder" senza cache, per cui guadagneresti il caching di BIND, ed in
più potresti configurare BIND per risolvere eventuali domini "interni"
di test o anche per fare filtraggio DNS