Forum Debian Users Gang

hello_world · 2012-06-29 17:06:17

Mam VPN-a pptpd który w pliku pptpd.conf ma zdefiniowaną sieć 192.168.10.0
Moja sieć na serwerze vpn jest 192.168.0.0
Jak ułożyć routing aby po wbiciu się na vpn-a móc korzystać z sieci lan(192.168.0.0)?

Jacekalex · 2012-06-29 18:15:35

Ten VPN masz jakimś normalnym standardzie, czy "pogiętym"?

Bo jeśli ten vpn działa, jak normany vpn, to sygnał do niego (w obu kierunkach) chodzi przez wirtualny interfejs TAP.

I potem routing na kompa z którego chcesz się dostać ustawiasz na serwerze VPN, a routing do sieci - do której chcesz sie dostać (schowanej za VPN'em), na kompie, z którego się łączysz.

Za każdym razem intersuje Cię routing przez interfejs tapX będący końcówką VPN'a.

To by było na tyle
;-)

hello_world · 2012-06-29 21:11:48

@Jacekalex
To jest pptpd nie Openvpn.
Końcówki to mobilni klienci chyba nie będę im mówił że mają sobie trasę ustawiać.

Z drugiej strony wpadłem na pomysł aby ustawić alias eth0:VPN interfejsu sieciowego gdzie ustawiłem na podsiec vpna i wydaje mi się że jak jest forward na interfejsach ustawiony na 1 to powinno to gadać. Ale nie gada

Ostatnio edytowany przez hello_world (2012-06-29 21:12:19)

Jacekalex · 2012-06-29 22:44:09

O tym, że to pptpd piszesz pierwszy raz, co do tap, to używają tego tunele ustawione przez SSH i IPSec, nie tylko OpenVPN.
Moj bląd polegał na tym, ze nie doczytalem w Twoim poście tego ppptpd, pomylilo mi się pppd, ale moja ślepota jest powszechie znana.
:D

Sprobuj tak ustawić parametry pptpd.conf, żeby kilienci dostawali adresy z tej samej podsieci, do ktorej mają mieć dostęp, albo wydziel im osobną, al e routing ustaw tak, zeby była komunikacja miedzy tymi sieciami.
Ustawisz to parametrami localip i remoteip, np:

Kod:

localip 192.168.0.1
remoteip 192.168.0.2-254

W każdym razie routing ustawiasz tradycyjnie, pptpd nie ma jakichś szczególnych możliwości w tym zakresie.

Tu masz opis z podstawowymi przykładami:
http://quozl.linux.org.au/pptp/pptpd.conf.5.html

hello_world · 2012-06-29 23:43:50

Właśnie chodzi o to aby była to inna podsieć.
Na tej samej podsieci co LAN działa dobrze, natomiast brakuje mi miejsca w LAN-ie na rezerwacje IP dla VPN-ów więc myślę o drugiej podieci.
Ale jak dam podsieć inną jak LAN to dupa nie mam dostępu do LAN-u

Jacekalex · 2012-06-29 23:48:48

Iptables i maskarada? -masz tam przykład?

Względnie sam routing - na serwerze, jeśli to linux, powinno zajarzyć automatycznie, i kierować pakiety do poszczególnych podsieci na podstawie adresów i masek interfejsów sieciowych.
Względnie może tam trzeba poprawić trasy routingu na poszczególne podsieci?

hello_world · 2012-06-30 08:15:49

Mam SNAT ustawiony bo to brama, probowałem dodawać na serwerze VPN trasy na różne sposoby i nic.
Najlepsze jest to że wpadłem na pomysła by na LANIE ustawić maskę 23 co daje mi rezerwacje na 510(Obejmuje zakresem sieć VPN ) hostów i też nic

Jacekalex · 2012-06-30 14:00:37

Jakie interfejsy mają końcówki pptpd? każdy pacjent ma własny pppX?
Czy wszyscy wiszą na jednym interfejsie TAP/ppp/czy innym?
Na jakim interfejsie jest sieć lokalna? eth1? bond0?
W ogóle sprobuj zdiagnozować, czy problem jest na serwerze, z routingiem, czy u pacjenta (na Windows) jest problem z routingiem.

Chyba, że pptpd coś pieprzy.

radziłbym się też połączyć z Linuxa do tego pptpd, i zobaczyć routing na kliencie i serwerze - czy jest to samo, co na Windows, i takie same objawy.

Ja na Twoim miejscu walnąłbym raczej Strongswana (Ipsec) z radiusem i eap-radius.
Wszystkie Windowsy od XP SP2 dzialają z nim bez specjalnego softu, i obsługuje polączenia przez NAT.

Ostatnio edytowany przez Jacekalex (2012-06-30 14:11:57)

hello_world · 2012-07-01 11:08:35

Każdy mobilny otzrymuje własny pppX oczywiście na serwerze są narastające a u klienta jeden interfejs.
Wszyscy wiszą po stronie serwera na jednym localip
Sieć lokalna jest na eth0
Próbowałem z routingiem na serwerze na różne sposoby.
Nie zmienię na ipseca bo mobilnu to ludzie w całej Polsce (około 100) i nie mam ochoty ani czasu na takie zmiany.

Po stronie klienta(po zestawieniu VPN-a) mogę pingować i dostawać się tylko na serwer pptpd (po IP LAN i po ip pppX)

milyges · 2012-07-01 11:20:20

1.
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -A FORWARD -i ppp+ -o <interjefs_lan> -j ACCEPT
iptables -A FORWARD -o <interfejs_lan> -o ppp+ -j ACCEPT

2. Wszyscy w sieci lan, do których chcesz sie dostac, muszą mieć serwer VPN albo za bramkę domyślną, albo dodany wpis do tablicy routingu ze siec 192.168.10.0 obsługuje serwer VPN

3. w konfigu pptpd musisz mieć zdefiniowane że podsieć 192.168.0.0 jest obsługiwana po VPN

4. Żadna maskarada ani NAT nie ma sensu, jeżeli robisz to pomiędzy dwoma lanami.

hello_world · 2012-07-01 14:26:21

ad1) Mam 1 . Tak dla ścisłości to straciłem ładnych parę dni aby dojść że /proc/sys/net/ipv4/conf/default/forwarding nie daje możliwości SNAT. Daje tylko maskarade co w przypadku stałego IP daje niepotrzebny narzut. SNAT można osiągnąć dając dla wszystkich interfejsow 1.
FORWARD cały mam na ACCEPT
ad2)Nie zrozumiałem tej podpowiedzi. Inni w LANIE są dla użytkownikow VPN tylko hostami na który mobilki chcą się dostać (np jakaś aplikacja magazynowa)
ad3)W konfigu mam localip 192.168.10.X. Sieć LAN mam 192.168.0.0/24. remoteip mam 192.168.10.x-x. Oczywiście jeśli localip dam 192.168.0.X to widzę sieć. Jak mówiłem wczesniej brakuje mi w LAN-ie miejsca dla ip VPN.
ad4)NAT jest potrzebny bo jak wskazalem server VPN bramka to ta sama maszyna, a mobilki to ludzie z polski łączący się z siecią w centrali

Podaje schemat:

mobilki (dostają nowy interfejs ppp0 o ip z puli remoteip)
\
\
-------> WAN_IP ------[ debian-router ]-------LAN_IP(192.168.0.0/24)
[ vpn(localip 192.168.1.1 ]
[ remoteip 192.168.1.2-200 ]

Najlepsze że jak zapuszczampinga z klienta mobilnego na stacje w lanie (po zestawieniu VPN-a) tcpdump-a po stronie serwera na interfejsie ppp0 to widać że coś się dzieje
tcpdump -i ppp0

Kod:

15:24:21.305546 IP 192.168.1.200 > 192.168.0.52: ICMP echo request, id 10072, seq 67, length 64
15:24:22.314522 IP 192.168.1.200 > 192.168.0.52: ICMP echo request, id 10072, seq 68, length 64
15:24:23.324522 IP 192.168.1.200 > 192.168.0.52: ICMP echo request, id 10072, seq 69, length 64
15:24:24.331760 IP 192.168.1.200 > 192.168.0.52: ICMP echo request, id 10072, seq 70, length 64
15:24:25.339885 IP 192.168.1.200 > 192.168.0.52: ICMP echo request, id 10072, seq 71, length 64
15:24:26.349022 IP 192.168.1.200 > 192.168.0.52: ICMP echo request, id 10072, seq 72, length 64
15:24:27.354771 IP 192.168.1.200 > 192.168.0.52: ICMP echo request, id 10072, seq 73, length 64
15:24:28.381321 IP 192.168.1.200 > 192.168.0.52: ICMP echo request, id 10072, seq 74, length 64
15:24:29.372031 IP 192.168.1.200 > 192.168.0.52: ICMP echo request, id 10072, seq 75, length 64
15:24:30.389056 IP 192.168.1.200 > 192.168.0.52: ICMP echo request, id 10072, seq 76, length 64
15:24:31.388550 IP 192.168.1.200 > 192.168.0.52: ICMP echo request, id 10072, seq 77, length 64
15:24:32.396441 IP 192.168.1.200 > 192.168.0.52: ICMP echo request, id 10072, seq 78, length 64
15:24:33.402885 IP 192.168.1.200 > 192.168.0.52: ICMP echo request, id 10072, seq 79, length 64
15:24:34.413921 IP 192.168.1.200 > 192.168.0.52: ICMP echo request, id 10072, seq 80, length 64
15:24:35.417816 IP 192.168.1.200 > 192.168.0.52: ICMP echo request, id 10072, seq 81, length 64
15:24:36.447778 IP 192.168.1.200 > 192.168.0.52: ICMP echo request, id 10072, seq 82, length 64
15:24:37.434086 IP 192.168.1.200 > 192.168.0.52: ICMP echo request, id 10072, seq 83, length 64
15:24:38.444123 IP 192.168.1.200 > 192.168.0.52: ICMP echo request, id 10072, seq 84, length 64
15:24:39.459151 IP 192.168.1.200 > 192.168.0.52: ICMP echo request, id 10072, seq 85, length 64

A na kliencie ping nie odpowida

Ostatnio edytowany przez hello_world (2012-07-01 15:29:38)

Jacekalex · 2012-07-01 15:32:06

A czy próbowałeś Sam się połaczyć z tym VPNem z domu?

Wiesz przynajmniej, gdzie nawala routing? na serwerze czy u pacjentów?
Bo ten malutki drobiazg w dalszym ciągu z niczego tu nie wynika.
Jeśli nie wiadomo nawet, czy winny serwer, czy winny Windows u pacjentów, (a tak się dziwnie składa, że wszystkie Windowsy mają ten sam domyślny program do łączenia z VPN), to nie masz co majstrować przy serwerze, bo łatwiej coś popieprzyć, niż naprawić.

Weź sobie sam odpal jakiegoś Windowsa, i obejrzyj po połączeniu trasy routingu zarówno na serwerze, jak i kliencie.

Poza tym jeśli wszystkie adresy pppX i LANu są w jednej podsieci, to czy przypadkiem pptpd nie ma dla takiego ustawienia specjalnego trybu proxyarp?

Ostatnio edytowany przez Jacekalex (2012-07-01 15:32:46)

hello_world · 2012-07-01 15:54:55

No to podaje zestawienie tras routingu po zestawieniu VPN-a:
SERVER

Kod:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         44.44.44.1     0.0.0.0         UG    0      0        0 eth2
44.44.44.0     0.0.0.0         255.255.255.128 U     0      0        0 eth2
192.168.0.0     0.0.0.0         255.255.254.0   U     0      0        0 eth0
192.168.1.200   0.0.0.0         255.255.255.255 UH    0      0        0 ppp0

KLIENT

Kod:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         0.0.0.0           0.0.0.0         U     0      0        0 ppp0
10.10.10.0    0.0.0.0           255.255.255.0   U     0      0        0 wlan0
44.44.44.120   10.10.10.1      255.255.255.255 UGH   0      0        0 wlan0
44.44.44.120   10.10.10.1      255.255.255.255 UGH   0      0        0 wlan0
192.168.0.177   0.0.0.0         255.255.255.255 UH    0      0        0 ppp0

Dane ip wan zmyslone

Podaję jeszcze szczegóły tcpdumpa przy próbie połączenia po ssh z klienta mobilnego do komputera za bramką VPN w sieci LAN
LAPTOP mobilny

Kod:

root@laptop:/home/tk# tcpdump -i ppp0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
16:01:25.915152 IP 192.168.1.200.56808 > 192.168.0.52.ssh: Flags [s], seq 3749208969, win 13600, options [mss 1360,sackOK,TS val 5084510 ecr 0,nop,wscale 6], length 0
16:01:26.914883 IP 192.168.1.200.56808 > 192.168.0.52.ssh: Flags [s], seq 3749208969, win 13600, options [mss 1360,sackOK,TS val 5084760 ecr 0,nop,wscale 6], length 0
16:01:28.918898 IP 192.168.1.200.56808 > 192.168.0.52.ssh: Flags [s], seq 3749208969, win 13600, options [mss 1360,sackOK,TS val 5085261 ecr 0,nop,wscale 6], length 0
16:01:32.930875 IP 192.168.1.200.56808 > 192.168.0.52.ssh: Flags [s], seq 3749208969, win 13600, options [mss 1360,sackOK,TS val 5086264 ecr 0,nop,wscale 6], length 0
16:01:40.946899 IP 192.168.1.200.56808 > 192.168.0.52.ssh: Flags [s], seq 3749208969, win 13600, options [mss 1360,sackOK,TS val 5088268 ecr 0,nop,wscale 6], length 0
16:01:56.962893 IP 192.168.1.200.56808 > 192.168.0.52.ssh: Flags [s], seq 3749208969, win 13600, options [mss 1360,sackOK,TS val 5092272 ecr 0,nop,wscale 6], length 0

i w tym samym czasie na bramce VPN zapuszczony tcpdump pokazuje:
BRAMKA VPN

Kod:

16:01:29.027961 IP 192.168.1.200.56808 > 192.168.0.52.ssh: Flags [s], seq 3749208969, win 13600, options [mss 1360,sackOK,TS val 5084510 ecr 0,nop,wscale 6], length 0
16:01:30.024528 IP 192.168.1.200.56808 > 192.168.0.52.ssh: Flags [s], seq 3749208969, win 13600, options [mss 1360,sackOK,TS val 5084760 ecr 0,nop,wscale 6], length 0
16:01:32.030705 IP 192.168.1.200.56808 > 192.168.0.52.ssh: Flags [s], seq 3749208969, win 13600, options [mss 1360,sackOK,TS val 5085261 ecr 0,nop,wscale 6], length 0
16:01:36.038494 IP 192.168.1.200.56808 > 192.168.0.52.ssh: Flags [s], seq 3749208969, win 13600, options [mss 1360,sackOK,TS val 5086264 ecr 0,nop,wscale 6], length 0
16:01:44.056865 IP 192.168.1.200.56808 > 192.168.0.52.ssh: Flags [s], seq 3749208969, win 13600, options [mss 1360,sackOK,TS val 5088268 ecr 0,nop,wscale 6], length 0
16:02:00.071746 IP 192.168.1.200.56808 > 192.168.0.52.ssh: Flags [s], seq 3749208969, win 13600, options [mss 1360,sackOK,TS val 5092272 ecr 0,nop,wscale 6], length 0

Ostatnio edytowany przez hello_world (2012-07-01 16:09:19)

Jacekalex · 2012-07-01 16:34:45

Jedna sprawa mnie dziwi na pierwszy rzut oka:
Dlaczego w obu systemach adres 0.0.0.0 jest routowany na interfejs zewnętrzny, jak powinien być traktowany tak, jak adres localhosta?

A potem masz adres 0.0.0.0 jako gateway, i jeśli 0.0.0.0 ma iść przez eth2 lub ppp0 - to wychodzą kwadratowe jaja.
Dziwne, że tam w ogóle coś działa normalnie. ;)
Czym osiągnąłeś taki routing? Jaki program to tak skonfigurował?

Dla przykładu, mam teraz włączony tylkon net przez pppoe:

Kod:

ip route show
default via 178.210.202.1 dev ppp0  metric 4008 
127.0.0.0/8 via 127.0.0.1 dev lo 
178.210.202.1 dev ppp0  proto kernel  scope link  src 178.210.204.11

I net chodzi.

Jakbym teraz podniósł Virtualboxa, to przybędzie interfejs vboxnet0 z trasą routingu 192.168.56.0/24 przez vboxnet0.
Ale w pokazanych wyżej ustawieniach nie ma prawa nic zmienić.

Dlatego trasy routingu, które pokazaleś, wyglądają trochę jak choninka świateczna. ;)

Ostatnio edytowany przez Jacekalex (2012-07-01 16:54:16)

hello_world · 2012-07-01 17:13:12

Tak mam przed podlączeniem VPN-a na kliencie

Kod:

tk@laptop:~$ ip route ls
default via 10.10.10.1 dev wlan0  proto static 
10.10.10.0/24 dev wlan0  proto kernel  scope link  src 10.10.10.152

Łącze się przez NetworkManager-a, ale takie same objawy sa przy windowsie tzn nie ma dostepu do sieci LAN Bramki VPN-a

Jacekalex · 2012-07-01 17:26:29

A możesz się połączyć z VPNem bez NM, żeby sprawdzić, czy zachowanie klienta (routing) jest jednakowe, jak z NM?

Bo tu nie ma gwarancji, że jest tylko jeden błąd.

Na serwerze też masz co najmniej dziwne te trasy routingu.
Obecnie na kliencie dziwi brak trasy do localhosta, powinna być widoczna.

Całą sieć w kliencie ustawia NM?
Co ustawia routing na serwerze?

Edyta:
Jako że sam szykuję sobie do jednej firmy konfigurację strongswan+radius, kilka sznurków i uwag na temat VPN:

PPTP:
http://pl.wikipedia.org/wiki/PPTP

Wikipedia napisał(-a):
.....Od momentu powstania protokół PPTP, w implementacji firmy Microsoft, był wielokrotnie łamany i jego stosowanie w poważnych zastosowaniach nie gwarantuje odpowiedniego poziomu bezpieczeństwa przesyłanych danych....

http://www.schneier.com/pptp-faq.html

IPSEC i Strongswan:
http://pl.wikipedia.org/wiki/IPsec
http://en.wikipedia.org/wiki/StrongSwan
http://www.strongswan.org/documentation.html
http://www.strongswan.org/docs/LinuxKongress2009-strongswan.pdf - strona 53 - 54.
http://wiki.strongswan.org/projects/strongswan/wiki … ultipleConfig
Strongswan obsługuje połączenia za NATem.

Cecha wspólna:
Oba protokoły są obsługiwane przez wbudowane narzędzia systemu Windows lub darmowe oprogramowanie Microsoftu.

Pozdrawiam
;-)

Ostatnio edytowany przez Jacekalex (2012-07-05 07:36:51)

Forum Debian Users Gang

Ogłoszenie

#1 2012-06-29 17:06:17

hello_world - Członek DUG

routing w pptpd

#2 2012-06-29 18:15:35

Jacekalex - Podobno człowiek...;)

Re: routing w pptpd

#3 2012-06-29 21:11:48

hello_world - Członek DUG

Re: routing w pptpd

#4 2012-06-29 22:44:09

Jacekalex - Podobno człowiek...;)

Re: routing w pptpd

Kod:

#5 2012-06-29 23:43:50

hello_world - Członek DUG

Re: routing w pptpd

#6 2012-06-29 23:48:48

Jacekalex - Podobno człowiek...;)

Re: routing w pptpd

#7 2012-06-30 08:15:49

hello_world - Członek DUG

Re: routing w pptpd

#8 2012-06-30 14:00:37

Jacekalex - Podobno człowiek...;)

Re: routing w pptpd

#9 2012-07-01 11:08:35

hello_world - Członek DUG

Re: routing w pptpd

#10 2012-07-01 11:20:20

milyges - inż.

Re: routing w pptpd

#11 2012-07-01 14:26:21

hello_world - Członek DUG

Re: routing w pptpd

Kod:

#12 2012-07-01 15:32:06

Jacekalex - Podobno człowiek...;)

Re: routing w pptpd

#13 2012-07-01 15:54:55

hello_world - Członek DUG

Re: routing w pptpd

Kod:

Kod:

Kod:

Kod:

#14 2012-07-01 16:34:45

Jacekalex - Podobno człowiek...;)

Re: routing w pptpd

Kod:

#15 2012-07-01 17:13:12

hello_world - Członek DUG

Re: routing w pptpd

Kod:

#16 2012-07-01 17:26:29

Jacekalex - Podobno człowiek...;)

Re: routing w pptpd

Wikipedia napisał(-a):

Stopka forum