Sziasztok,
Elkezdtem foglalkozni az OpenVPN-el és megy is szépen, belső IP-ket kapnak a kliensek, és egy külső IP-vel csatlakozik máshová mindegyik. Egyébként Ubuntu rendszeren van a szerver a kliensek pedig windows 7,8,10
Ha jól tudom amit fent leírtam az a subnet megoldás.
Én azt szeretném elérni, hogy a felcsatlakozott kliensek, mind egy publikus IP címet kapjanak az általam megadott ip címek közül, és közvetlen azzal menjenek a világhálóra (persze a szerver és az osztott ip-k mind egy tartományban vannak).
Gondoltam hogy ezt server-bridge módban tudom megtenni, így hát átállítottam bridge módra, létrehoztam egy bridget a szerveren, átváltottam tap-ra tun helyett és tádám felcsatlakozik a kliens, ki is írja a rendszer hogy melyik IP-t kapta meg és minden sikeres, csak hogy mégsem vette fel az IP-t mert ha ellenőrzöm az ip címét a gépnek mondjuk weboldalon vagy speedtesten akkor nem változott, vagy ha tracerouton nézem mi a helyzet, még csak nem is érinti a vpn szervert, szóval valami nem okés..
Az érdekelne, hogy egyáltalán jól gondolkodom-e hogy ezt így kell? :D Esetleg valakinek van-e más ötlete?
Előre is köszönöm,
üdv,
Norbi
Hozzászólások
Ez elsőre nem lesz olyan magától értetődő. Az OpenVPN kliens gépeken így két interfész lesz, az egyik az eddigi alap IP cím, amihez van egy default gateway. A másik meg maga az OpenVPN kliens interfész, amihez ezek szerint az általad akart publikus IP hozzá is rendelődik. Kérdés, hogy ez utóbbi interfészen van-e beállítva default gateway? Annak kisebb-e a metrikája, mint az alap interfészhez tartozónak? Mert ha nem, akkor minden netforgalom továbbra is az alap interfészen keresztül indul el.
a VPN hálózaton (tun0 vagy tap0 interface) mindig privát cím van, nem hiába virtual private network :-)
adjuk pl a 172.16.0.0/24 tartományt a vpn-nek,
melyből az egyik, a .0.1 legyen a gateway.
érdemes megjegyezni, hogy a vpn szerver és a vpn hálózat default gateway-lye két különálló szerepkör, alapból nem következik egyik a másikból. azaz ahol a vpn szerveralkalmazás fut, futtatni kell egy vpn klienst is, hogy az a gép is network stack-ből hozzáférjen a vpn hálózathoz.
biztos van az openvpn-nek olyan módja amikor ezt automatikusan megteszi, de én szeretem elkülöníteni a feladatköröket. ezért az openvpn démon csak mintegy virtuális switch-ként működik, dhcp-t se oszt, se nem routing-ol, azt a direkt erre dedikált alkalmazások teszik nálam.
ha ajánlhatom, kövesd ezt a megvalósítást, könnyebb debuggolni, kiterjeszteni.
ha jól értem, azt akarod, hogy kívülről ugyanarról a címről látszódjanak a kliensek, ha a VPN hálózaton keresztül forgalmaznak (default gw 172.16.0.1).
ez már adott, ha a GW (a vpn szerver router minőségében) elvégzi a NAT-olást.
de az a külső IP - gondolom ezt valósítottad meg először - a router IP-je.
ahhoz, hogy egy külső IP-re NAT-old a vpn kliensek forgalmát, ami nem a router default source címe, egyszerűen másik forrás címre kell NAT-oláskor fordítani.
"iptables -j MASQUERADE"-del lehet legegyszerűbben NAT-olni, ehelyett "iptables -t nat -A POSTROUTING -j SNAT" -ra lesz szükséged.
de meg kéne bizonyosodni róla, hogy ilyenkor automatikus-e a válaszcsomagok DNAT-olása...
ez aggasztó. lehet, nem is a vpn hálózat felé forgalmaz?
"route print" mit mond a windows-okon?
szükség lehet még egy "iptables-save" kimenetre.
~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack
"VPN hálózaton (tun0 vagy tap0 interface) mindig privát cím van": ez így nem igaz, teljesen működőképes lehet egy olyan konfiguráció, ahol csak publikus IP címekről van szó, és amit a kérdező is akar. A "private" azt jelenti, hogy a tunnel-en belüli forgalom privát, azt nem láthatják/módosíthatják azon eszközök, amelyek továbbítják a tunnel forgalmát.
jó, technikailag persze, lehet.
gondolkodtam is, hogy csillagozzam meg azt a szélsőséges "mindig" kijelentésemet :)
szerintem továbbra is NAT-ra lesz szükség, hogy mind egy publikus címről látszódjék.
ha tegyük fel, vpn-en keresztül, mindegyik kliens publikus címmel kéne kommunikáljon, akkor a vpn szerveren lenne annyi tapX, amennyi kliens van és mind össze lenne bridge-elve a fizikai interfésszel?
onnastól kezdve csak engedélyezni kell a broadcastot a vpn-en, az ARP miatt
~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack
végülis rendelhetsz globálisan publikus címeket a VPN interface-ekhez, ahogy azt közben ricpet is írta, és akkor natúr routinggal oldod meg, hogy kommunikálni tudjanak; akkor nem kell NAT.
én feltételeztem, hogy áll rendelkezésedre 4 publikus IP erre a célra, ezért gondolkodtam NAT-olásban.
~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack
Az elgondolás megvalósítható, ha nagyon akarod, akkor még akár tun eszközt használva is, de akkor mindenképpen route-olni is kell a fogadón - tap esetén a bridge használatával ez megkerülhető.
Ami mindenképpen fontos, az viszont a klienseken a route-olás, azok ugyanis alapban minden forgalmat, amely nem a VPN helyi subnetje, az eredeti interface-n, az eredeti gateway-en tol ki. Ezt meg lehet trükközni azzal, hogy a fogadón bevésel egy "redirect-gateway" opciót is. Ezt a fogadó letolja a kliensnek, amikor az kapcsolódik, amire is a kliens a default gw-t átállítja a fogadó (VPN-beli) IP-jére, illetve felvesz egy extra route-ot, hogy a fogadó (valós) IP-je az eredeti gw-n keresztül érhető el (így maga a VPN kapcsolat életben marad).
Ami itt hibalehetőség, hogy W7 esetén user jogokkal a VPN interface UP-ba tehető és konfigurálható, de a route-olás nem módosítható! Ezért az OpenVPN külön nem szól, csak a logban szerepel, hogy "hát ez nem sikerült". Ezen a ponton nagyon zavaró, hogy minden jónak tűnik, hiszen a VPN él, a túloldal pingelhető direktben - és mégsem úgy működik a rendszer, ahogy szeretnénk. A megoldás ekkor, hogy a kliensen az OpenVPN-t úgy futtatjuk, hogy a futtató usernek legyen joga ezt elkövetni. (Fapados módszer: admin userrel indítjuk. Finomabb(?) módszer: a futtató user kap Network Admin jogkört.)
Köszönnöm, mint utólag kiderült a bridge nem jól futott a gépen, és ha megpróbálom elindítani megszakad az internet.
Most az lenne a kérdésem, hogy userenként kell létrehoznom tap0-1-2-3 "eszközöket" vagy hogy lehet ezt megvalósítani? Külön routolni nem szeretnék.
Egyébként az OpenVPN oldaláról vettem a bridge start fájlt amivel próbálkoztam, bemásolom ide:
#!/bin/bash
#################################
# Set up Ethernet bridge on Linux
# Requires: bridge-utils
#################################
# Define Bridge Interface
br="br0"
# Define list of TAP interfaces to be bridged,
# for example tap="tap0 tap1 tap2".
tap="tap0"
# Define physical ethernet interface to be bridged
# with TAP interface(s) above.
eth="eth1"
eth_ip="79.172.***.***"
eth_netmask="255.255.255.0"
eth_broadcast="79.172.***.***"
for t in $tap; do
openvpn --mktun --dev $t
done
brctl addbr $br
brctl addif $br $eth
for t in $tap; do
brctl addif $br $t
done
for t in $tap; do
ifconfig $t 0.0.0.0 promisc up
done
ifconfig $eth 0.0.0.0 promisc up
ifconfig $br $eth_ip netmask $eth_netmask broadcast $eth_broadcast
A szerveren egyetlen tap eszköz kell. Az OpenVPN szerver konfigja eleve csak egy eszköz nevet tud fogadni. Minden egyes OpenVPN kliens oldalon lévő tap ezzel az egy szerver oldali tap eszközzel lesz összekötve.
Végül sikerült elindítani a bridget, csak nem tudom hozzáadni az átjárómat hogy működjön az internet elérés is..
ahogy lentebb írtam.
A klienseken: A default route legyen a vpn szerver default gw-je, a vpn szerver ip-jét pedig az eredeti default gw irányába kell route-olni
// Happy debugging, suckers
#define true (rand() > 10)
Igen próbáltam, de valamiért nem engedi berakni a default gw-t.
Pontosítok: rtnetlink answers invalid argument
a vpn interface azonos tartományban a gateway-el?
// Happy debugging, suckers
#define true (rand() > 10)
Igen
most akkor nem a windows-os klienseken való route beállitásról van szó?
a szerveren hogy néz ki a routing tábla?
gondolom már van egy default gw és te pluszba meg akarsz egy másikat adni a vpn-bol jövo forgalom számára.
ez esetben source routing-ot kell alkalmazni. "ip rule", "ip route table" parancssal.
~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack
Szia!
Ehhez több dolog kell. Egyrészt a legegyszerűbb megoldás az lenne, hogy ha a szerverre lenne route-olva az a tartomány, amiből szeretnéd osztani a címeket. A klienseket pedig úgy kell konfigurálnod, hogy a route táblájukba a vpn szerver felé az eredeti gateway marad meg, default gateway-ként pedig a vpn túloldala.
Persze meg lehet úgy is oldani, hogy nincs feléd routeolva a tartomány, így viszont a bridge nem elég, iptables varázslás is kell hozzá. A kliens oldal ettől még áll, csak a default gateway a vpn szerver gateway-e lesz:)
// Happy debugging, suckers
#define true (rand() > 10)