|
|||||||
|
|
|
![]() |
|
|
Strumenti |
|
|
#1 |
|
Senior Member
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 |
|
|
|
|
|
#2 |
|
Senior Member
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 |
|
|
|
|
|
#3 |
|
Senior Member
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 |
|
|
|
|
|
#4 |
|
Senior Member
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 |
|
|
|
|
|
#5 | |
|
Senior Member
Iscritto dal: Jun 2001
Città: Gorizia/Trieste/Slovenia
Messaggi: 4338
|
Quote:
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) |
|
|
|
|
|
|
#6 |
|
Senior Member
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 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 |
|
|
|
|
|
#7 |
|
Senior Member
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 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 |
|
|
|
|
|
#8 | ||
|
Senior Member
Iscritto dal: Jun 2001
Città: Gorizia/Trieste/Slovenia
Messaggi: 4338
|
Quote:
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:
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) |
||
|
|
|
|
|
#9 | |
|
Senior Member
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:
Pensa te, c'avrò guardato 100 volte e non me n'ero accorto Grazie mille Dane |
|
|
|
|
|
|
#10 |
|
Senior Member
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) |
|
|
|
|
|
#11 |
|
Senior Member
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 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. |
|
|
|
|
|
#12 |
|
Senior Member
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) |
|
|
|
|
|
#13 |
|
Senior Member
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 |
|
|
|
|
|
#14 |
|
Senior Member
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 |
|
|
|
|
| Strumenti | |
|
|
Tutti gli orari sono GMT +1. Ora sono le: 01:02.




















