Torna indietro   Hardware Upgrade Forum > Altre Discussioni > Amministrazione e Configurazione Server

Cineca inaugura Pitagora, il supercomputer Lenovo per la ricerca sulla fusione nucleare
Cineca inaugura Pitagora, il supercomputer Lenovo per la ricerca sulla fusione nucleare
Realizzato da Lenovo e installato presso il Cineca di Casalecchio di Reno, Pitagora offre circa 44 PFlop/s di potenza di calcolo ed è dedicato alla simulazione della fisica del plasma e allo studio dei materiali avanzati per la fusione, integrandosi nell’ecosistema del Tecnopolo di Bologna come infrastruttura strategica finanziata da EUROfusion e gestita in collaborazione con ENEA
Mova Z60 Ultra Roller Complete: pulisce bene grazie anche all'IA
Mova Z60 Ultra Roller Complete: pulisce bene grazie anche all'IA
Rullo di lavaggio dei pavimenti abbinato a un potente motore da 28.000 Pa e a bracci esterni che si estendono: queste, e molte altre, le caratteristiche tecniche di Z60 Ultra Roller Complete, l'ultimo robot di Mova che pulisce secondo le nostre preferenze oppure lasciando far tutto alla ricca logica di intelligenza artificiale integrata
Renault Twingo E-Tech Electric: che prezzo!
Renault Twingo E-Tech Electric: che prezzo!
Renault annuncia la nuova vettura compatta del segmento A, che strizza l'occhio alla tradizione del modello abbinandovi una motorizzazione completamente elettrica e caratteristiche ideali per i tragitti urbani. Renault Twingo E-Tech Electric punta su abitabilità, per una lunghezza di meno di 3,8 metri, abbinata a un prezzo di lancio senza incentivi di 20.000€
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 21-03-2016, 14:52   #1
Dwayne
Senior Member
 
L'Avatar di Dwayne
 
Iscritto dal: Nov 2000
Città: Lucca
Messaggi: 1501
OpenVPN - Routing / NAT

Buongiorno,
vi chiedo una mano perchè sono arrivato ad un punto morto
Scenario : collegamento di due sedi remote via openvpn
Situazione attuale : tutto configurato, connessione up e host che si vedono fra loro
Problema : dal server openvpn della sede remota riesce a vedere tutti i pc della sede centrale, dai pc della sede centrale riesco a vedere solo il server della sede remota e oltretutto solo tramite ip del tunnel (10.0.x.x) e non tramite ip locale della macchina remota.

In sede centrale, il server openvpn è una macchina con pfsense, nella sede remota un server con ubuntu.

Ho configurato su pfsense il routing alla sede remota, se attivo la cattura dei pacchetti sull'interfaccia openvpn del pfsense e pingo un'host della sede remota, vedo che i pacchetti prendono la rotta giusta, solo che non arriva nessuna risposta
Dall'altra parte (server sede remota), pingo tranquillamente ogni ip della sede locale
A livello di NAT, non ho configurato niente

Che può esserci che non va?


P.S. aggiungo due info :
Sede remota : macchina ubuntu, non gateway di rete
Sede centrale : macchina pfsense, collegata in wan ad un router telecom
Dwayne è offline   Rispondi citando il messaggio o parte di esso
Old 21-03-2016, 22:39   #2
malatodihardware
Senior Member
 
L'Avatar di malatodihardware
 
Iscritto dal: Sep 2008
Messaggi: 3583
Devi aggiungere una route statica sui PC (o sul gateway) della rete remota per raggiungere la sede usando come gateway il server ubuntu

Inviato dal mio Nexus 5
malatodihardware è offline   Rispondi citando il messaggio o parte di esso
Old 22-03-2016, 08:38   #3
Dwayne
Senior Member
 
L'Avatar di Dwayne
 
Iscritto dal: Nov 2000
Città: Lucca
Messaggi: 1501
Già aggiunta, sia sul server openvpn che sul gateway della rete remota

Dal server della rete remota le rotte sono ok, raggiungo ogni pc della sede centrale; dai pc della rete remota invece no, ma devo sistemare il forwarding della macchina server openvpn che al momento non è attivo
Dwayne è offline   Rispondi citando il messaggio o parte di esso
Old 22-03-2016, 10:41   #4
Dwayne
Senior Member
 
L'Avatar di Dwayne
 
Iscritto dal: Nov 2000
Città: Lucca
Messaggi: 1501
Ho parzialmente risolto, adesso riesco a pingare il server remoto openvpn sul suo indirizzo di rete.
A futura referenza, è bastato cambiare il tipo di tunnel da tun a tap

Ora mi metto a sistemare il forwarding sul server remoto e vedo se sistemo il resto
Dwayne è offline   Rispondi citando il messaggio o parte di esso
Old 22-03-2016, 12:21   #5
Dane
Senior Member
 
L'Avatar di Dane
 
Iscritto dal: Jun 2001
Città: Gorizia/Trieste/Slovenia
Messaggi: 4338
Quote:
Originariamente inviato da Dwayne Guarda i messaggi
Ho parzialmente risolto, adesso riesco a pingare il server remoto openvpn sul suo indirizzo di rete.
A futura referenza, è bastato cambiare il tipo di tunnel da tun a tap

Ora mi metto a sistemare il forwarding sul server remoto e vedo se sistemo il resto

tun e tap sono giusto un pelo diversi.....

Che indirizzamento hai tra le due sedi?
__________________
Dio ha fatto il cavo, il diavolo il wireless.

"CCIE-level challenges should stay in CCIE labs." (cit I.Pepelnjak)
Dane è offline   Rispondi citando il messaggio o parte di esso
Old 22-03-2016, 13:24   #6
Dwayne
Senior Member
 
L'Avatar di Dwayne
 
Iscritto dal: Nov 2000
Città: Lucca
Messaggi: 1501
Confesso la mia ignoranza in fatto di VPN

Sede remota : LAN 192.168.5.0
Sede centrale : LAN 192.168.2.0
Tunnel : 10.0.8.0

Al momento, dopo tanti smaneggiamenti, la situazione si presenta così :

Il server sede remota raggiunge tutti i pc della sede centrale
Da ogni pc della sede centrale si raggiunge il server della sede remota, anche con il suo ip locale (192.168.5.100)

Dalla sede centrale, non si riesce ad accedere ai pc della lan remota, ne dai pc della lan centrale ne dal server centrale
Dai pc della rete remota, non si raggiunge niente, nemmeno il server centrale remoto

Route server sede remota

Codice:
Tabella di routing IP del kernel
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.5.1     0.0.0.0         UG    0      0        0 eth0
10.0.8.0        *               255.255.255.0   U     0      0        0 tap0
192.168.2.0     10.0.8.1        255.255.255.0   UG    0      0        0 tap0
192.168.5.0     *               255.255.255.0   U     0      0        0 eth0
Route server centrale
Codice:
default	192.168.1.1	UGS	45178	1500	xn1
10.0.8.0/24	link#7	U	0	1500	ovpns1
10.0.8.1	link#7	UHS	9922	16384	lo0
127.0.0.1	link#3	UH	52	16384	lo0
192.168.1.0/24	link#6	U	7334	1500	xn1
192.168.1.2	link#6	UHS	0	16384	lo0
192.168.2.0/24	link#5	U	68177	1500	xn0
192.168.2.254	link#5	UHS	0	16384	lo0
192.168.5.0/24	10.0.8.1	UGS	14	1500	ovpns1
Dwayne è offline   Rispondi citando il messaggio o parte di esso
Old 22-03-2016, 13:34   #7
Dwayne
Senior Member
 
L'Avatar di Dwayne
 
Iscritto dal: Nov 2000
Città: Lucca
Messaggi: 1501
Aggiungo tcpdump sul server remoto di ping da pc della sede remota a pc sede centrale

Codice:
mauri@NasStation:~$ sudo tcpdump -i tap0 -n icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap0, link-type EN10MB (Ethernet), capture size 65535 bytes
13:30:25.547740 IP 192.168.5.20 > 192.168.2.12: ICMP echo request, id 7666, seq 1, length 64
13:30:26.549942 IP 192.168.5.20 > 192.168.2.12: ICMP echo request, id 7666, seq 2, length 64
Mi pare di capire che il traffico viene indirizzato correttamente, semplicemente non arrivano risposte dall'altra parte

Questo è il packet capture sull'interfaccia openvpn del server centrale dello stesso comando di prima
Codice:
13:32:46.477558 IP 192.168.2.2.57241 > 192.168.5.100.22: tcp 52
13:32:46.533988 IP 192.168.5.100.22 > 192.168.2.2.57241: tcp 68
13:32:46.565297 IP 192.168.2.2.57241 > 192.168.5.100.22: tcp 0
13:32:47.165285 IP 192.168.2.2.57241 > 192.168.5.100.22: tcp 52
13:32:47.222976 IP 192.168.5.100.22 > 192.168.2.2.57241: tcp 52
13:32:47.234698 IP 192.168.5.100.22 > 192.168.2.2.57241: tcp 100
13:32:47.235063 IP 192.168.2.2.57241 > 192.168.5.100.22: tcp 0
13:32:47.239584 IP 192.168.5.20 > 192.168.2.12: ICMP echo request, id 7667, seq 1, length 64
13:32:47.240225 ARP, Request who-has 192.168.5.20 tell 10.0.8.1, length 28
13:32:48.241992 IP 192.168.5.20 > 192.168.2.12: ICMP echo request, id 7667, seq 2, length 64
13:32:48.242284 ARP, Request who-has 192.168.5.20 tell 10.0.8.1, length 28
13:32:49.241544 IP 192.168.5.20 > 192.168.2.12: ICMP echo request, id 7667, seq 3, length 64
13:32:49.241782 ARP, Request who-has 192.168.5.20 tell 10.0.8.1, length 28
13:32:50.240604 IP 192.168.5.20 > 192.168.2.12: ICMP echo request, id 7667, seq 4, length 64
13:32:50.240880 ARP, Request who-has 192.168.5.20 tell 10.0.8.1, length 28
13:32:51.241647 IP 192.168.5.20 > 192.168.2.12: ICMP echo request, id 7667, seq 5, length 64
13:32:51.241890 ARP, Request who-has 192.168.5.20 tell 10.0.8.1, length 28
13:32:52.241234 IP 192.168.5.20 > 192.168.2.12: ICMP echo request, id 7667, seq 6, length 64
13:32:52.241471 ARP, Request who-has 192.168.5.20 tell 10.0.8.1, length 28
13:32:53.240841 IP 192.168.5.20 > 192.168.2.12: ICMP echo request, id 7667, seq 7, length 64
13:32:53.241246 ARP, Request who-has 192.168.5.20 tell 10.0.8.1, length 28
13:32:54.242097 IP 192.168.5.20 > 192.168.2.12: ICMP echo request, id 7667, seq 8, length 64
13:32:54.242386 ARP, Request who-has 192.168.5.20 tell 10.0.8.1, length 28
13:32:55.244573 IP 192.168.5.20 > 192.168.2.12: ICMP echo request, id 7667, seq 9, length 64
13:32:55.244847 ARP, Request who-has 192.168.5.20 tell 10.0.8.1, length 28
13:32:56.240437 IP 192.168.5.20 > 192.168.2.12: ICMP echo request, id 7667, seq 10, length 64
13:32:56.240722 ARP, Request who-has 192.168.5.20 tell 10.0.8.1, length 28
13:32:57.241716 IP 192.168.5.20 > 192.168.2.12: ICMP echo request, id 7667, seq 11, length 64
13:32:57.241946 ARP, Request who-has 192.168.5.20 tell 10.0.8.1, length 28
Dwayne è offline   Rispondi citando il messaggio o parte di esso
Old 22-03-2016, 14:59   #8
Dane
Senior Member
 
L'Avatar di Dane
 
Iscritto dal: Jun 2001
Città: Gorizia/Trieste/Slovenia
Messaggi: 4338
Quote:
Originariamente inviato da Dwayne Guarda i messaggi
Confesso la mia ignoranza in fatto di VPN

Sede remota : LAN 192.168.5.0
Sede centrale : LAN 192.168.2.0
Tunnel : 10.0.8.0

Al momento, dopo tanti smaneggiamenti, la situazione si presenta così :

Il server sede remota raggiunge tutti i pc della sede centrale
Da ogni pc della sede centrale si raggiunge il server della sede remota, anche con il suo ip locale (192.168.5.100)

Dalla sede centrale, non si riesce ad accedere ai pc della lan remota, ne dai pc della lan centrale ne dal server centrale
Dai pc della rete remota, non si raggiunge niente, nemmeno il server centrale remoto

Route server sede remota

Codice:
Tabella di routing IP del kernel
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.5.1     0.0.0.0         UG    0      0        0 eth0
10.0.8.0        *               255.255.255.0   U     0      0        0 tap0
192.168.2.0     10.0.8.1        255.255.255.0   UG    0      0        0 tap0
192.168.5.0     *               255.255.255.0   U     0      0        0 eth0
E' abilitato il routing sul server remoto?
I client usano il server remoto (192.168.5.100) come gateway?
Se no, puoi impostare su 192.168.5.1 di passare da 192.168.5.100 per 192.168.0.2/24 e 10.0.8.0/24.


Quote:
Route server centrale
Codice:
default	192.168.1.1	UGS	45178	1500	xn1
10.0.8.0/24	link#7	U	0	1500	ovpns1
10.0.8.1	link#7	UHS	9922	16384	lo0
127.0.0.1	link#3	UH	52	16384	lo0
192.168.1.0/24	link#6	U	7334	1500	xn1
192.168.1.2	link#6	UHS	0	16384	lo0
192.168.2.0/24	link#5	U	68177	1500	xn0
192.168.2.254	link#5	UHS	0	16384	lo0
192.168.5.0/24	10.0.8.1	UGS	14	1500	ovpns1
[/quote]

Qua non batte 10.0.8.1. Non dovrebbe essere 10.0.8.2? (ma ti confesso che le vpn tap-tap le evito a prescindere, quindi metterei tun-tun).

Assicurati inoltre che i due "server vpn" non nattino.
__________________
Dio ha fatto il cavo, il diavolo il wireless.

"CCIE-level challenges should stay in CCIE labs." (cit I.Pepelnjak)
Dane è offline   Rispondi citando il messaggio o parte di esso
Old 22-03-2016, 15:10   #9
Dwayne
Senior Member
 
L'Avatar di Dwayne
 
Iscritto dal: Nov 2000
Città: Lucca
Messaggi: 1501
Non l'avevo precisato, ma nella sede remota il server openvpn non è il default gateway, ma ho già provveduto ad aggiungere al default gateway (192.168.5.1) le due route per 10.0.8.0 e 192.168.2.0

Quote:
Qua non batte 10.0.8.1. Non dovrebbe essere 10.0.8.2? (ma ti confesso che le vpn tap-tap le evito a prescindere, quindi metterei tun-tun).

Assicurati inoltre che i due "server vpn" non nattino.
Sono un co....ne, si, dovrebbe essere 10.0.8.2, e infatti adesso va tutto
Pensa te, c'avrò guardato 100 volte e non me n'ero accorto

Grazie mille Dane
Dwayne è offline   Rispondi citando il messaggio o parte di esso
Old 22-03-2016, 15:48   #10
Dane
Senior Member
 
L'Avatar di Dane
 
Iscritto dal: Jun 2001
Città: Gorizia/Trieste/Slovenia
Messaggi: 4338
ben.
prima di metterlo in produzione togli il tap a favore del tun.
Ti dovrebbe evitare un po' di broadcast inutili (nel senso che se servono c'è qualcosaltro che non va).

W!
Dane
__________________
Dio ha fatto il cavo, il diavolo il wireless.

"CCIE-level challenges should stay in CCIE labs." (cit I.Pepelnjak)
Dane è offline   Rispondi citando il messaggio o parte di esso
Old 22-03-2016, 16:59   #11
Dwayne
Senior Member
 
L'Avatar di Dwayne
 
Iscritto dal: Nov 2000
Città: Lucca
Messaggi: 1501
Sto provando a reimpostare la vpn con tun, solo che ora mi ritrovo nella situazione iniziale

Questo è il route attuale sul server centrale
Codice:
default	192.168.1.1	UGS	3848	1500	xn1
10.0.8.0/24	10.0.8.2	UGS	307	1500	ovpns1
10.0.8.1	link#7	UHS	1288	16384	lo0
10.0.8.2	link#7	UH	115	1500	ovpns1
127.0.0.1	link#3	UH	36	16384	lo0
192.168.1.0/24	link#6	U	1200	1500	xn1
192.168.1.2	link#6	UHS	0	16384	lo0
192.168.2.0/24	link#5	U	5398	1500	xn0
192.168.2.254	link#5	UHS	0	16384	lo0
192.168.5.0/24	10.0.8.2	UGS	3	1500	ovpns1
Codice:
Mar 22 16:51:21	openvpn[61971]: xxxxxx [xxxxx] Peer Connection Initiated with [AF_INET]xxxxxxxx
Mar 22 16:51:21	openvpn[61971]: xxx/xxxx MULTI_sva: pool returned IPv4=10.0.8.6, IPv6=(Not enabled)
Mar 22 16:51:23	openvpn[61971]: xxx/xxxx send_push_reply(): safe_cap=940
Questo il route sul server remoto
Codice:
Tabella di routing IP del kernel
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.5.1     0.0.0.0         UG    0      0        0 eth0
10.0.8.1        10.0.8.5        255.255.255.255 UGH   0      0        0 tun0
10.0.8.5        *               255.255.255.255 UH    0      0        0 tun0
192.168.2.0     10.0.8.5        255.255.255.0   UG    0      0        0 tun0
192.168.5.0     *               255.255.255.0   U     0      0        0 eth0

Ultima modifica di Dwayne : 22-03-2016 alle 17:04.
Dwayne è offline   Rispondi citando il messaggio o parte di esso
Old 22-03-2016, 17:09   #12
Dane
Senior Member
 
L'Avatar di Dane
 
Iscritto dal: Jun 2001
Città: Gorizia/Trieste/Slovenia
Messaggi: 4338
ma stai mettendo indirizzi a caso?

10.0.8.2
10.0.8.5
10.0.8.6
__________________
Dio ha fatto il cavo, il diavolo il wireless.

"CCIE-level challenges should stay in CCIE labs." (cit I.Pepelnjak)
Dane è offline   Rispondi citando il messaggio o parte di esso
Old 22-03-2016, 17:16   #13
Dwayne
Senior Member
 
L'Avatar di Dwayne
 
Iscritto dal: Nov 2000
Città: Lucca
Messaggi: 1501
Ho visto, in realtà non sto mettendo niente io, sono indirizzi che prende in automatico :

in pratica server prende 10.0.8.1 e come gateway 10.0.8.2
Server remoto prende 10.0.8.6 come ip e 10.0.8.5 come gateway

I due indirizzi 10.0.8.2 e 10.0.8.5 non sono pingabili

Dal server remoto riesco però a raggiungere correttamente tutti i pc della rete centrale
Dwayne è offline   Rispondi citando il messaggio o parte di esso
Old 22-03-2016, 17:33   #14
Dwayne
Senior Member
 
L'Avatar di Dwayne
 
Iscritto dal: Nov 2000
Città: Lucca
Messaggi: 1501
Ok, ho trovato il responsabile di questo "comportamento", nella configurazione di default tun di pfsense abilita un'opzione "Address Pool : Provide a virtual adapter IP address to clients (see Tunnel Network) "

Disabilitata questa, il client mi prende 10.0.8.2 e tutti son felici e contenti

Grazie ancora Dane
Dwayne è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


Cineca inaugura Pitagora, il supercomputer Lenovo per la ricerca sulla fusione nucleare Cineca inaugura Pitagora, il supercomputer Lenov...
Mova Z60 Ultra Roller Complete: pulisce bene grazie anche all'IA Mova Z60 Ultra Roller Complete: pulisce bene gra...
Renault Twingo E-Tech Electric: che prezzo! Renault Twingo E-Tech Electric: che prezzo!
Il cuore digitale di F1 a Biggin Hill: l'infrastruttura Lenovo dietro la produzione media Il cuore digitale di F1 a Biggin Hill: l'infrast...
DJI Osmo Mobile 8: lo stabilizzatore per smartphone con tracking multiplo e asta telescopica DJI Osmo Mobile 8: lo stabilizzatore per smartph...
Blue Origin rinvia il secondo lancio del...
Nasce l'albo degli influencer 'rilevanti...
Il Digital Networks Act è stato r...
ASUS ROG ha lanciato due nuovi monitor d...
I nuovi iPhone 18 Pro potrebbero present...
Una parte dei Galaxy S26 avrà chi...
Amazon permetterà agli autori ind...
Il caso Zuckerberg a Palo Alto: una scuo...
Texas contro Roblox: il procuratore gene...
Offerte auto da urlo su Amazon: da CarPl...
Windows 11 26H1 in arrivo fra pochi mesi...
Un Black Friday continuo a rilascio lent...
Redmi Pad Pro da 12,1" 2560x2600 pi...
Tesla Roadster rinviata (di nuovo): ora ...
Il nuovo TV premium 2025 Samsung OLED 4K...
Chromium
GPU-Z
OCCT
LibreOffice Portable
Opera One Portable
Opera One 106
CCleaner Portable
CCleaner Standard
Cpu-Z
Driver NVIDIA GeForce 546.65 WHQL
SmartFTP
Trillian
Google Chrome Portable
Google Chrome 120
VirtualBox
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 01:02.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Served by www3v