ipsec/l2tp: ubuntu szerver - osx kliens

Fórumok

Sziasztok!

Lassan két hete próbálok egy ubuntu 10.10-ből vpn szervert faragni, mivel osx klienssel szeretnék bekapcsolódni ezért ipsec/l2tp-t választottam. A felállás, olyan hogy a d-link 524-es router mögött van az ubuntu-s gép, amin az ipsec és az xl2tp fut (ugyanezen gépen vannak a szolgáltatások is melyeket el szeretnék érni távolról). A beállítási fájlok a következők:

ipsec.conf:

config setup
nat_traversal=yes
virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
nhelpers=0

conn L2TP-PSK-NAT
rightsubnet=vhost:%no,%priv
also=L2TP-PSK-noNAT

conn L2TP-PSK-noNAT
leftnexthop=[routerem ip címe]
authby=secret
pfs=no
auto=add
keyingtries=3
rekey=no
type=transport
left=[ubuntu-s gép ip címe]
#leftprotoport=17/%any
leftprotoport=17/1701
right=%any
rightprotoport=17/%any

include /etc/ipsec.d/examples/no_oe.conf

ipsec.secrets


[ubuntu-s gép ip címe] %any: "[kiválasztott PSK]"

xl2tpd.conf


[global]
auth file = /etc/xl2tpd/l2tp-secrets
[lns default]
exclusive = no
ip range = 192.168.0.201-192.168.0.254 ; Replace with your IP range
local ip = 192.168.0.200 ; One of your interface must be using this IP
require authentication = yes
require chap = yes
refuse pap = yes
pppoptfile = /etc/ppp/options.l2tpd
length bit = yes

l2tp-secrets


* * [kiválasztott PSK]

options.l2tpd


dump

# Output debugging information to /var/log/debug
debug

# Do not support BSD compression.
nobsdcomp
passive
lock

# Allow all usernames to connect.
name *
proxyarp
ipcp-accept-local
ipcp-accept-remote
lcp-echo-failure 3
lcp-echo-interval 5
nodeflate

# Do not authenticate incoming connections. This is handled by IPsec.
noauth
refuse-chap
refuse-mschap
refuse-mschap-v2

# Set the DNS servers the PPP clients will use.
ms-dns 8.8.8.8
ms-dns 8.8.4.4

mtu 1400
mru 1400

Amikor osx-ről (leopard) próbálok csatlakozni, akkor a következők jelennek meg a system logban:


2010.10.25. 10:20:41 pppd[19961] L2TP connecting to server '[ip címem]'...
2010.10.25. 10:20:41 pppd[19961] L2TP connecting to server '[ip címem]'...
2010.10.25. 10:20:45 pppd[19961] IPSec connection started
2010.10.25. 10:20:45 pppd[19961] IPSec connection started
2010.10.25. 10:20:46 pppd[19961] IPSec connection established
2010.10.25. 10:20:46 pppd[19961] IPSec connection established
2010.10.25. 10:20:48 pppd[19961] L2TP connection established.
2010.10.25. 10:20:48 pppd[19961] Connect: ppp0 <--> socket[34:18]
2010.10.25. 10:20:48 configd[14] en1: DHCP duplicate configured service
2010.10.25. 10:20:48 pppd[19961] IPCP: Maximum Config-Requests exceeded
2010.10.25. 10:20:48 pppd[19961] Connection terminated.
2010.10.25. 10:20:48 pppd[19961] L2TP disconnecting...
2010.10.25. 10:20:48 pppd[19961] L2TP disconnected
2010.10.25. 10:20:48 configd[14] en1: DHCP duplicate configured service

Ha esetleg valakinek van tapasztalata a témában (neadjisten működő rendszere) kérem írja meg. Köszi!

Hozzászólások

hogy megnyugtassalak:
nekem OSX Server (10.8.3) és OSX kliensek (szintén 10.8.3) között SEM sikerült még soha az életben ipsec/l2tp kapcsolatot kiépíteni. :)
az okosok azt mondják, hogy portforwardolva nem is fog menni, mert az 53-as típusú IP csomagot is forwardolni kéne, lyat meg nem tudnak a routerek, mert az nem az 53-as TCP/IP port, hanem 53-as típus. (lehet, nem 53-as, hirtelen erre emlékszem)

marad a pptp 128bites titkosítással, vagy - ami még jobb - openvpn Viscosity klienssel.

nekem nem kéne szerencsére portworward-olnom (vagy van public IP-m, vagy nem én felügyelem a router-t)
viszont pptp-rõl azért akarok l2tp-re váltani, mert állítólag nem igényel másik szállítási rétegbeli protokollt, azaz megyen TCP-n vagy UDP-n.
ellenben a pptp-vel, ami IP/GRE felett folyik és egy hétvége alatt úgy gondolta a szolgáltatóm, hogy az neki jó ha blokkolják...

(köszönöm, meg nem nevezett ISP. már egy napot elbsztam rá)

~~~~~~~~
http://www.youtube.com/watch?v=VbUVqODL1nE

Nálam erre a tuti megoldás az ssh tunneling. "kintről" csak ssh, és mint egy alagútba bele lehet tolni az összes szükséges alkalmazás portját. Szerintem sokkal szebb és egyszerűbb megoldás.

pl van egy routeren futó torrent kliens, amit a 192.168.1.1:9091 -es porton lehet elérni.
Ha beputty-olok kintről a routerbe úgy, hogy a 9091-es portot a helyi gép 40000-es portjára irányítjuk, akkor a localhost:40000 -es porton lehet elérni a távoli torrent felületet. Ugyanez a technika működőképes bármilyen más alkalmazásnál is.

Ha kintről akarsz benti win-es géped adminolni akkor érdemes fix ip-t állítani a célgépre, és ennek a 3389-es portját átforwardolni a routerre mondjuk 30000-es portra.
A külső putty-ra ilyenkor be kell állítani egy tunnelt, ami a 30000-es portot a helyi gép 30000-es portjára állítja.
Ezután mstsc localhost:30000 -rel be lehet jelentkezni a belső gépre ( persze remote admint engedélyezni kell ) és ez a kapcsoalt is természetesen ssh-ba van beágyazva.

( a teljesség kedvéért, van egy etherwake nevű package az openwrt-ben ami kinyomja a magic packet-et, így win-es a gép távolról és kívülről is bekapcsolható )

Nálam ez a megoldás működik jó ideje, gond nélkül. Az hogy osx-es gépről szeretnél adminolni, a helyzeten nem változtat sokat.
remélem tudtam segíteni. Üdv, PGY

"Ezt véletlenül nem valahogy úgy kellene megadni hogy:
ip range = 192.168.0.201/254; "
nem.
mert megadhatom akar azt is, hogy a 192.168.0.101 és 192.16.0.130 kozott osszon csak ipcimeket, pl.

az ssh tunneles alternativad meg vpn-t nem helyettesit. ha mar alternativa kell, akkor openvpn.
az legalabb megy minden platformon. illetve nem ecsetelem tovább, gondolom te is érzed a külömbséget az ssh tunnel meg egy vpn kozott, amikor a belsőhálozati, pl. céges iroda rendszereket kellene elérni...

ssh tunnel valóban égi áldás - ha minden résztvevõ node-on megvan a kellõ mennyiségũ jogod.
használom is gyakran saját gépeimen. jelen megoldásra váró problémémnak, ami miatt bekapcsolódtam a topic-ba, azonban nem felel meg.
egy L2 szinũ hálózatra van szükségem, ahol oszthatok dhcp-t, a gépek akár teljes porttartományát elérem, külön L3-as címmel szólíthatom meg, mint egy szviccselt hálózaton.

~~~~~~~~
http://www.youtube.com/watch?v=VbUVqODL1nE