Simulare richiesta da client locale come provenisse da internet

[joe]

Ho un PC host con Slackware.
Su questo gira una macchina virtuale (via virt manager) con un sistema guest windows 7.

Voglio esporre sul sistema host un servizio, openvpn nella fattispecie ma non ha importanza, andrebbe bene anche netcat in ascolto su una porta.
E vorrei utilizzare il sistema guest come client per richiedere connessione al servizio in ascolto su slackware.
Però vorrei testare il servizio in modo che sia accessibile dall'esterno, cioè da internet, quindi mi servirebbe che il guest in qualche modo potesse instradare la sua richiesta all'esterno per poi presentarla al sistema host come proveniente da fuori.

Questo mi servirebbe in seconda battuta anche per testare il buon funzionamento di DDNS, ma è un argomento secondario... ho IP pubblico dinamico ma cambia poco di frequente, per fare una prova posso utilizzare l'IP numerico.
Non so se sia possibile e non riesco a trovare una chiave di ricerca che mi restituisca risultati interessanti via google.

libvirt e virt-manager di defult permettono al guest di comunicare col sistema host via rete utilizzando un bridge virtuale. Sto quasi pensando che potrei utilizzare uno di quei siti che mettono a disposizione una VPN su cui instradare il traffico internet. Se la attivassi dal sistema guest, questo sarebbe costretto a passare da là per poi collegarsi al sistema host che riceverebbe la richiesta come proveniente dall'esterno. Però è un'idea che m'è venuta solamente ora mentre scrivo... non so. Magari ci sono sistemi più furbi.

Vi viene in mente qualche possibilità migliore?

[ponce]

nel caso di servizi web, ad esempio, io uso host esterni a cui mi posso connettere via ssh come proxy socks 5 sul browser e poi da questo faccio richieste ai miei host locali dove gira il webserver che voglio provare.

ma se vuoi testare openvpn probabilmente una macchina esterna e' la soluzione piu' semplice.
potresti anche usare un altro pc nel solito luogo pero' connesso a internet invece che con la rete locale via tethering del cellulare (e quindi usa la rete, esterna, del tuo provider mobile).

[joe]

Avevo pensato anch'io al cellulare... il problema è che non ho sotto mano un altro PC.

Invece ho fatto la prova con netcat su due terminali dello stesso host e ottengo una comunicazione testuale, esempio sull'ipotetico server:

Codice: Seleziona tutto

nc -l -p 1500 127.0.0.1

E sull'ipotetico client (io l'ho provato sempre dal localhost):

Codice: Seleziona tutto

nc 127.0.0.1
testo di prova
tanto per vedere
se si vede apparire questo
scritto anche sul netcat in ascolto

Per il resto io avevo pensato a vpnbook:
https://www.vpnbook.com/howto/setup-openvpn-on-windows7

Si deve installare il client openvpn sul client win7 virtualizzato e impostare i file di config scaricabili dal sito, poi col client openvp si esegue la connessione mettendo utente e password pubblicati sempre sul sito.

A quel punto installando netcat anche su windows ed eseguendolo:

Codice: Seleziona tutto

nc ${mioip-reale} 1500
quel che è scritto qui dovrebbe apparire
anche sul netcat in ascolto, ma sta volta
la comunicazione dovrebbe passare da internet
via vpnbook.

Ci dev'essere il modo anche di vedere da quale IP proviene la comunicazione, e assicurarci che effettivamente provenga dall'esterno con l'IP di vpnbook. Ora non saprei bene come farlo ma credo che tipo con netstat o simili si dovrebbe vedere...

[ponce]

puoi anche usare la linea del cellulare e il client ufficiale di openvpn per android per connetterti da fuori

https://openvpn.net/connect-docs/connec ... droid.html

da dove proviene la connessione dovresti vederlo dai log del server openvpn.

[joe]

Potrebbe essere un'idea... Preferivo farlo con il guest windows 7 perché riflette poi una situazione che ho in realtà con un pc remoto. Ma per testare è OK.
Il fatto è che non ho ancora messo in piedi il server vpn su slackware, per quello per il momento volevo assicurarmi della raggiungibilità. E netcat mi è sembrato semplice e adeguato per lo scopo, tanto per escludere che ci siano problemi diversi con router, firewall ecc...

Comunque dal guest win7 sono riuscito a collegarmi a vpnbook e ho verificato di avere un ip francese, quindi diverso dal mio IP pubblico che allo stesso momento avevo sul sistema host facendo la stessa verifica.
In pratica il guest win7 era tunnelizzato verso internet, mentre l'host slackware no.
Questa situazione intanto mi è servita banalmente per installare il client openvpn su win7 ed in effetti serviva un aggiornamento windows inerente sha2 (256) senza il quale non funzionava.

netcat però, per il momento non sono riuscito a farlo comunicare.
Ho messo in ascolto su slackware, sull'interfaccia 127.0.0.1 e da win7 ho provato "netcat mioipvero porta". Ovviamente avendo prima aperto la porta sul router e creato una regola su iptables per aprire la porta in questione anche sul sistema slackware.

Alla fine mi sono detto: "proviamo prima a vedere se netcat funziona tra host e guest passando per la rete che viene messa in piedi da virt-manager.
Allora, dall'host slackware vediamo un interfaccia bridge virbr0 con indirizzo 192.168.122.1/24.
Mentre dal guest win7 ho yba scheda eth virtuale con indirizzo 192.168.122.103 e gateway 92.168.122.1 cioè il bridge di cui sopra.
Ho provato a mettere in ascolto dall'host netcat sull0indirizzo del bridge e collegarmici dal guest ma restituisce:

Codice: Seleziona tutto

invalid connection to [192.168.122.1] from (UNKNOWN) [192.168.122.103]

La cosa simpatica è che provando la stessa cosa ma mettendo il serve netcat sul localhost dell'host e attivando vpnbook su win7 da dove lancio il netcat client, l'errore che appare sul terminale dell'host è analogo, cambiano gli ip però: al posto di quello del bridge kvm ho quello della mia scheda di rete reale del PC. E al posto dell'indirizzo della scheda di rete virtuale del guest ho l'IP pubblico di vpnbook.
Questo dimostra che il guest è passato da internet per contattarmi su slackware.
Poi netcat in qualche modo rifiuta la comunicazione ed esce, però credo che almeno il router e il firewall di slackware siano stati "bucati", o meglio la porta d'interesse è aperta.

[ponce]

ma l'ip dove sta in ascolto il servizio/netcat a cui ti vuoi connettere da fuori (e a cui devi eventualmente redirigere la porta sul router) non e' quello sulla rete privata virtuale di libvirt, no?
dovrebbe essere sulla rete privata del network fisico dove sei (non su 127.0.0.1 che e' localhost e non puoi raggiungerlo da fuori), e' li' che vuoi far girare il server vpn, vero? il tuo router non sa niente ne del network 122 ne di localhost della macchina Slackware...

[joe]

No, in realtà l'IP a cui voglio connettermi è l'IP locale del mio PC che sta dietro un router, il quale a sua volta ha IP pubblico esposto ad internet (fornito dal mio ISP).
Il servizio che dovrà mettere a disposizione il mio PC sarà una VPN. Ma per il momento non è ancora in piedi, ne ho visto una guida apposita per slackware ma non è proprio immediata e volevo capire un po' meglio la teoria prima (soprattutto il discorso certificati ecc...).

Allora prima di complicare la situazione con un servizio vero e complesso che potrebbe non funzionare al primo colpo per enne altri motivi, volevo assicurarmi di essere raggiungibile dall'esterno.
L'ip da raggiungere da fuori in pratica sarebbe l'ip del mio router, il quale dovrà poi redirigere la porta specificata sull'ip locale assegnato alla mia scheda di rete in LAN che sarà del tipo "192.168.111.2".

Per testare il tutto "accendo" un'istanza netcat sul localhost del PC in questione 127.0.0.1. E dall'esterno vorrei raggiungere questo servizio di test contattando il mio IP pubblico.
Siccome però non ho il vero PC client (remoto) sotto mano da cui fare la prova, e non ho neanche un secondo PC da collegare ad internet via rete mobile per fare la prova, ecco che ho simulato la situazione utilizzando virt-manager.

Virt-manager di suo crea una scheda di rete nella macchina virtualizzata "guest" e le assegna IP 192.168.122.103. Questa scheda si collega al mondo esterno reale attraverso un gateway con indirizzo 192.168.122.1.
Sul sistema che ospita la macchina virtuale, il sistema host (slackware nel mio caso) si vede semplicemente l'interfaccia bridge "virbr0" con l'indirizzo sopra citato 192.168.122.1.
In partica dall'host posso pingare il guest all'indirizzo 192.168.122.3, e dal guesto posso pingare l'host attraverso il bridge utilizzando l'indirizzo stesso del bridge 192.168.122.1.

Le prove con netcat le ho fatte a due livelli:

1. da win7 guest a slackwre host facendo girare il servizio netcat su 127.0.0.1 e collegandomi con netcat (chiamiamolo client) dal guest all'IP del bridge 192.168.122.1.
L'esito è quello riportato sopra: il netcat server in ascolto "sente" la richiesta, ma la rifiuta come "invalid connection" from 192.168.122.103.
Quindi al "server" la richiesta del netcat client arriva, non so perché venga rifiutata, ma arrivare arriva.
A questo livello il router e internet on c'entrano. La prova serviva solamente per vedere se la comunicazione da win7 a slackware funzionava via netcat, in modo da capire se il netcat server funziona. E qualcosa non funziona in effetti.

2. da win7 guest a slackware sempre facendo girare il netcat server sul 127.0.0.1 (di slackware) e però sta volta collegandomi con netcat client all'IP pubblico del mio router avendo in precedenza instradato la connessione di win7 attraverso VPNbook in modo da forzarla a passare per un tunnel che la porta su internet da una via diversa.
In questo secondo scenario ci sono diversi problemi in più: il mio router deve far passare le richiesta alla porta del server netcat sull'ip locale del mio PC. Poi c'è anche la complicazione del passaggio in appoggio alla VPNbook che potenzialmente potrebbe apportare qualche limitazione non meglio nota. E in tutto ciò anche il firewall di slackware deve essere aperto sulla porta di ascolto di netcat server.
Alla fine comunque anche questa prova sembra funzionicchiare, come nello scenario semplificato del punto precedente:
cioè il netcat in ascolto riceve effettivamente la richiesta proveniente da IP "francese" e però la rifiuta con un mesaggio del tipo:

Codice: Seleziona tutto

invalid connection to [192.168.111.2] from (UNKNOWN) [54.36.174.134]

Il che significa che la richiesta proviene effettivamente da quell'ip 54.36.x.x che è un ip pubblico appunto francese fornito da vpnbook al sistema win7 tunnelizzato.

Mi chiedevo perché dicesse "invalid connection".
Probabilmente ho spiegato in modo confusionario... spero di no ma il discorso è un po' arzigogolato già di suo, se qualcosa non vi torna dite pure che magari correggo anch'io qualche strafalcione.

[ponce]

ma, ribadisco, perche' se vuoi contattare il tuo pc apri netcat su localhost (127.0.0.1) e non su 192.168.111.2?

[joe]

Probabilmente per mia ignoranza in termini di reti e servizi da predisporre in ascolto per eventuali client esterni... In soldoni che differenza c'è?
Alla fine dietro l'interfaccia eth c'è pur sempre il mio localhost... 127.0.0.1, no?

[ponce]

no, la rete 127.0.0.0/8 e' una rete diversa (nemmeno routata: ogni macchina ha la sua interfaccia di loopback configurata di default).
se vuoi mettere un servizio disponibile sulla rete (non al solo host locale) non puoi metterlo su localhost ma devi necessariamente metterlo su un'interfaccia di rete raggiungibile.
nel tuo scenario l'interfaccia di rete raggiungibile, tramite router, dall'esterno e, tramite routing delle interfacce del tuo pc, dalla macchina virtuale e' l'interfaccia fisica tramite la quale sei collegato al router, nel tuo esempio 192.168.111.2: e' su questa interfaccia che dovresti mettere in ascolto il servizio (netcat o openvpn server che sia) se vuoi che sia raggiungibile da dentro e da fuori.

[joe]

Giusto, ho anche provato e in effetti se apro il "nc server" su 127.0.0.1, da win7 non lo raggiungo.

Alla fine il problema potrebbe essere legato all'opzione "-s" di netcat, che prima non avevo utilizzato, si vedeva la richiesta (a conferma della raggiungibilità), ma netcat non funzionava uscendosene con l'errore di cui sopra "invalid connection ecc...".

https://github.com/acmesh-official/acme.sh/issues/582

NC test

Codice: Seleziona tutto

➜  nc -l -s aaa.bbb.ccc.ddd -v
listening on [aaa.bbb.ccc.ddd] 39101 ...
# Connect to this server with: nc aaa.bbb.ccc.ddd 39101, then type ba
cli.ent.ip.addr: inverse host lookup failed: Unknown host
connect to [aaa.bbb.ccc.ddd] from (UNKNOWN) [cli.ent.ip.addr] 23949
ba


^C

Codice: Seleziona tutto

➜  nc -l aaa.bbb.ccc.ddd -v 
aaa.bbb.ccc.ddd: inverse host lookup failed: Unknown host
listening on [any] 35909 ...
# Connect to this server with nc aaa.bbb.ccc.ddd 35909
cli.ent.ip.addr: inverse host lookup failed: Unknown host
invalid connection to [aaa.bbb.ccc.ddd] from (UNKNOWN) [cli.ent.ip.addr] 43827

Aggiungendo l'opzione -s ecco che la cosa funziona. Ho messo anche un messaggio di benvenuto...

Codice: Seleziona tutto

$ (echo "Welcome"; cat) | nc -lvp 12345 -s 192.168.111.2
listening on [192.168.111.2] 12345 ...
connect to [192.168.111.2] from ns3103449.ip-54-36-174.eu [54.36.174.134] 49193
Prova da windows 7 via VPNbook
ok funge
Risposta da slackware
w7> conferma
w7> risposta ricevuta

OK, va be' il "Welcome" si vede solo dalla parte del client, comunque funziona: il servizio va esplicitamente aperto sull'interfaccia di rete "reale" cui verrà rediretta la richiesta remota dal router grazie all'appropriata regola di forwarding. Alla fine si può fare una piccola chat con netcat: quello che digito dal client, dando invio appare sul server e quel che digito sul server, dando invio appare sul client. Il giochino termina se il client si disconnette: in quel caso netcat server resta in piedi ma non funziona più se si riprova a contattare... va be' non interessa più di tanto, per lo scopo direi che ce n'è d'avanzo così.

In sintesi per ricapitolare e tornare alla richiesta dell'argomento:
- si può effettuare un test di accessibilità da remoto sul sistema locale simulando la richiesta con una macchina virtuale sullo stesso sistema.
- il sistema virtualizzato deve però essere tunnelizzato verso un servizio esterno
- a quel punto dal sistema virtualizzato si può effettuare una richiesta all'IP pubblico reale del sistema host
- su quest'ultimo il servizio deve essere in ascolto sull'interfaccia reale di rete, eventualmente richiamata dalla regola di forwarding del router se il PC è nattato.
- in questo modo pur essendo la macchina virtuale collocata sullo stesso PC, la richiesta eseguita come client effettuata dal guest, appare ed effettivamente è proveniente dall'ip assegnatogli dal tunnel (nel caso in esempio via vpn)

OK, "artifizi" simili forse si ottengono anche coinvolgendo un proxy remoto, che funga sempre da sponda esterna su cui rimbalzare la richiesta che parte dal guest e arriva al sistema reale host su cui gira il server in ascolto.

Se avete altri commenti e correzioni sono benvenute, grazie per le risposte Ponce!