Check alle échte Black Friday-deals Ook zo moe van nepaanbiedingen? Wij laten alleen échte deals zien

[vpn] Eén ip adres onbereikbaar

Pagina: 1
Acties:

  • Stien
  • Registratie: Oktober 2004
  • Laatst online: 13-10 21:28
Ik heb thuis een Openvpn server draaien op mijn router (dd-wrt). Ik kan zonder problemen op afstand hiermee verbinden. Ik loop echter tegen één probleem aan en dat is dat als verbonden ben via vpn ik één bepaald ip adres niet kan bereiken. Zodra ik de vpn verbinding verbreek kan ik zonder problemen verbinden. Andere ip adressen zijn wel perfect te benaderen.

Nu vermoed ik dat dit te maken heeft met het feit dat het onbereikbare ip adres een vaste vpn verbinding heeft met een andere VPN server (niet mijn server).

Dit is mijn Openvpn configuratie:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
push "route 192.168.1.0 255.255.255.0"
server 10.8.0.0 255.255.255.0
dev tun0
proto tcp
keepalive 10 120
dh /tmp/openvpn/dh.pem
ca /tmp/openvpn/ca.crt
cert /tmp/openvpn/cert.pem
key /tmp/openvpn/key.pem

# Only use crl-verify if you are using the revoke list &#-106; otherwise leave it commented out
# crl-verify /tmp/openvpn/ca.crl

# management parameter allows DD-WRT&#-110;s OpenVPN Status web page to access the servers management port
# port must be 5001 for scripts embedded in firmware to work
management localhost 5001

comp-lzo no
cipher AES-128-CBC


Dit is de route output van een bereikbaar ip adres
code:
1
2
3
4
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.1.1     0.0.0.0         UG    202    0        0 eth0
192.168.1.0     *               255.255.255.0   U     202    0        0 eth0


Dit is de route output van het onbereikbare ip adres
code:
1
2
3
4
5
6
7
8
9
10
11
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         10.9.0.5        128.0.0.0       UG    0      0        0 tun0
default         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
8.8.8.8         192.168.1.1     255.255.255.255 UGH   0      0        0 eth0
10.9.0.1        10.9.0.5        255.255.255.255 UGH   0      0        0 tun0
10.9.0.5        *               255.255.255.255 UH    0      0        0 tun0
128.0.0.0       10.9.0.5        128.0.0.0       UG    0      0        0 tun0
179.43.133.114  192.168.1.1     255.255.255.255 UGH   0      0        0 eth0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0
192.168.1.1     *               255.255.255.255 UH    0      0        0 eth0


Nu denk ik dit op te kunnen lossen met een static route.
Maar ik weet niet waar ik dat doe,De firewall of in de Openvpn server configuratie of de VPN client configuratie.

En wat moet ik dan specificeren in deze static route?

  • Yariva
  • Registratie: November 2012
  • Laatst online: 11:04

Yariva

Moderator Internet & Netwerken

Power to the people!

Vanaf waar test je dit? Binnen of buiten?

Mensen zijn gelijk, maar sommige zijn gelijker dan andere | Humans need not apply


  • Stien
  • Registratie: Oktober 2004
  • Laatst online: 13-10 21:28
van buiten het netwer: met mijn telefoon als access point

  • Yariva
  • Registratie: November 2012
  • Laatst online: 11:04

Yariva

Moderator Internet & Netwerken

Power to the people!

Okay nat je het 10.8.0.0/24 net?

En om welk op adres gaat het? Indien het geen private adres is kan je een adres kiezen in de zelfde range.

Mensen zijn gelijk, maar sommige zijn gelijker dan andere | Humans need not apply


  • ik222
  • Registratie: Maart 2007
  • Niet online
Het probleem zit hem in de weg terug van de onbereikbare host. Die krijgt namelijk vanuit zijn (andere) VPN een /1 route waar ook de IP range van jou VPN onder valt. Hierdoor wordt verkeer terug naar jou over die andere tunnel gestuurd en daar gaat het fout.

Mogelijke oplossingen:
- Statische route voor jou /24 naar 192.168.1.1 maken op de nu niet bereikbare host zelf.
- Kijken of de andere VPN van die host wel echt een /1 moet pushen.
- Je eigen VPN van subnet veranderen, bijvoorbeeld het hele 192.168.0.0/16 subnet valt niet onder die /1

  • Stien
  • Registratie: Oktober 2004
  • Laatst online: 13-10 21:28
Ok, ik heb mijn eigen vpn server configuratie aangepast naar 192.168.0.0/16

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
push "route 192.168.1.0 255.255.255.0"
server 192.168.0.0 255.255.0.0

dev tun0
proto udp
keepalive 10 120
dh /tmp/openvpn/dh.pem
ca /tmp/openvpn/ca.crt
cert /tmp/openvpn/cert.pem
key /tmp/openvpn/key.pem

# Only use crl-verify if you are using the revoke list &#-106; otherwise leave it commented out
# crl-verify /tmp/openvpn/ca.crl

# management parameter allows DD-WRT&#-110;s OpenVPN Status web page to access the servers management port
# port must be 5001 for scripts embedded in firmware to work
management localhost 5001

comp-lzo no
cipher AES-128-CBC


Ik krijg nu een ander ip adres toegewezen wanneer ik met de vpn ben geconnect.

code:
1
Mon May 16 11:34:36 2016 MANAGEMENT: >STATE:1463391276,CONNECTED,SUCCESS,192.168.0.6


Jammer genoeg blijft de situatie hetzelfde, één ip adres is niet bereikbaar.

=====

Ook heb ik getracht een statische route aan te maken in de onbereikbare host.

code:
1
 route add default gw 192.168.1.1/24


Ook dat bood geen soelaas.

Waarschijnlijk doe ik iets verkeerd, maar ik heb geen idee wat.

  • ik222
  • Registratie: Maart 2007
  • Niet online
Misschien moet je eens een netwerktekening maken met de exacte adressen etc. zodat wat duidelijker is wat er niet werkt.

  • Stien
  • Registratie: Oktober 2004
  • Laatst online: 13-10 21:28
Dat begrijp ik.
Ik ben even creatief geweest en het onderstaande plaatje samengesteld.
Ik hoop dat ik al het vereiste opgenomen heb.
Afbeeldingslocatie: http://s32.postimg.org/75hcns4up/2016_05_16_13_11_09_netwerk_docx_Word.jpg

  • ik222
  • Registratie: Maart 2007
  • Niet online
Dit maakt het inderdaad een stuk duidelijker.

Oke, ik zou sowieso het subnet van je eigen VPN client even wat kleiner maken, nu overlapt het met je LAN netwerk en dat is niet handig. En ik verwacht niet dat je ruim 65000 VPN clients tegelijk gaat gebruiken ;) Gebruik bijvoorbeeld 192.168.2.0/24 (dus netmask 255.255.255.0).

Als je routetabel er daarna zo uitziet op de probleemhost zoals in je eerste bericht staat zou het daarna in principe moeten werken zonder verder statische route op de probleemhost. Die statische route die je in een vorige host gemaakt hebt trouwens ook wel daadwerkelijk even verwijderen want wat je daar nu gemaakt hebt klopt sowieso niet en zorgt waarschijnlijk voor rare problemen.

Als je namelijk wel een statische route zou maken (wat alleen nodig is als je 10.8.0.0/24 zou willen blijven gebruiken als VPN subnet) dan moet die enkel de weg terug naar je VPN vertellen, dus:
code:
1
route add -net  10.8.0.0/24  netmask 255.255.255.0 gw 192.168.1.1

  • Stien
  • Registratie: Oktober 2004
  • Laatst online: 13-10 21:28
Thanks _/-\o_

Ik heb het opgelost door toch weer terug te gaan naar 10.8.0.0/24 en een iets aangepaste variant van jou voorgestelde static route door te voeren in de eerder onbereikbare host.

code:
1
route add -net  10.8.0.0  netmask 255.255.255.0 gw 192.168.1.1


Hartstikke bedankt. Deze kan gesloten worden

  • ik222
  • Registratie: Maart 2007
  • Niet online
Mooi :) Ja die /24 moest eraf ja. Copy & paste foutje... :)

Let wel dat als je die route zo invoert dat hij na een reboot weg is, dus even in je interfaces file zetten ofzo als 'up' commando.

[ Voor 54% gewijzigd door ik222 op 16-05-2016 14:14 ]


  • GuntherDW
  • Registratie: November 2004
  • Laatst online: 29-12-2022
Die /24 is voor als je de nieuwe commando's (iproute2) gebruikt.
Het wordt aangeraden van over te stappen naar die nieuwe commando's.

Het wordt dan inderdaad iets als
code:
1
ip route add 10.8.0.0/24 via 192.168.1.1

(of ip ro)
Pagina: 1