Routing + OpenVPN + több ip cím, magánhálózatok

 ( KaTT | 2015. július 27., hétfő - 17:19 )

Sziasztok!

Hogy tudom OpenVPN esetén a legegyszerűbben megoldani, hogy a pár kliens (10.2.0.x/24) lássa a VPN szerverrel azonos hálózaton lévő gépeket (10.2.0.x/24)?

Bonyolítja, hogy a VPN szerver (tap/tcp) elsődleges címe 192.168.122.123 és bár látja a többi gépet a 192.168.122.201 és 192.168.122.202 címen, hiába adtam hozzá mint

ip addr add 10.2.0.201 dev eth0

nem tudják pingelni egymást a gépek a 10.2.0.x-es címen, csak a 192.168.122.x-es címen át, ahogy megy a ping, ssh, minden.
Az iptables-ben kellene állítani routing-ot, a 10.2.0.x -es válózat és a 192.168.122.x között?
Kikapcsolt iptables esetén sem megy.
Az VPN kliensek által elérendő gépek virtuális gépek, és a VPN szerver is. Ha segít tudok beállítani eth1-et, stb. Most alapból az eth0:1-en van a 10.2.0.x/24 és az eth0 a 192.168.122.x/24.
Persze a VPN kliens sem látja a 10.2.0.x-es címet sem.
Próbáltam más tartományt adni a VPN klienseknek és az OpenVPN szerver .conf-ban beadni a "push ip" utasítást, úgy sem volt jó.

Természetesen nem kell látnia egymást a VPN klienseknek, csak a pár megadott szervert kell tudniuk elérni.

Centos 6 az összes gép.

Köszönöm előre is az észrevételeket.

UPDATE, szollosiimre jogos kérésére a pontosítás:

A CÉL, hogy a 10.2.0.201 és a 10.2.0.202 címet lássák az OpenVPN kliensek, elérjék, tudják pingelni, elérjék az összes szolgáltatást a 2 IP címen. Az mindegy, hogy milyen ip címet kapnak az OpenVPN kliensek. Az OpenVPN klienseknek nem kell egymást látniuk.

A 10.2.0.201 gép elsődleges IP címe: 192.168.122.201.
A 10.2.0.202 gép elsődleges IP címe: 192.168.122.202.

A VPN szerver (10.2.0.123) elsődleges IP címe: 192.168.122.123.

Az elsődleges IP címen látják, elérik egymást a gépek (123 + 201 + 202).
A másodlagos IP címen NEM érik el egymást a gépek, nem pingelhetőek.

arp -a esetén látszódik a többi 10.2.0.x-es ip, az nmap nem talál egyetlen nyitott portot sem.

201-es gépről: nmap -T5 10.2.0.0/24

Nmap scan report for 10.2.0.202
Host is up (0.000011s latency).
All 1000 scanned ports on 10.0.0.202 are filtered

Ha a 192.168.122.0/24 címtartományon fut le az nmap, akkor lát mindent jól, a nyitott portokat, stb.

Én első körben azt oldanám meg, hogy lássák egymást a 10.2.0.x-es tartományon át is a gépek. (Iptables / route?)
Második körben megnézném, hogy a működő OpenVPN-en ez esetben mi történik.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Szia,

2 dolog ami elsőre beugrott, az openvpn szerver confban vagy a ccd fájlban kell lenni a routing szabálynak

push "route 10.2.x.0 255.255.255.0 "

A másik hogy a net.ipv4.ip_forward ot engedélyezni kell a szerveren.

És még lehet, hogy a "client-to-client"-re is szüksége lesz...
--
Debian Linux rulez... :D

Az biztos. :)

Ha a kliensek kell hogy lassak egymast, akkor a server configba:
client-to-client

Ha a szerver halozatan levo gepeket is szeretned a kliensekkel elerni, akkor a szerver tuzfalat is modositanam az alabbival:

iptables -A FORWARD -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth0 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT

iptables -nat -A POSTROUTING -s 10.2.0.0/24 -o eth0 -j MASQUERADE

(Termeszetesen @Bucogi push routing-ja is kell.)

Készítenél egy értelmesebb leírást a problémáról?

Jogos. Készítettem.

Sakk-matt,
KaTT :)

dupla

Ha jól értem,akkor neked az a gondod,hogy "nem látják" a VPN kliensek a hálózatot.

Kérdés: Miért fontos,hogy ugyanabból a tartományból legyen IP címük a VPN klienseknek, mint a hálózat többi tagjának? Van olyan szolgáltatás, ami miatt ez szükséges?

Ha elég a layer 3, akkor ez egy sima routing, amit be kell konfigolni. Ha a VPN kliensek Internetet is akarnak,akkor ip_forward=1 és POSTROUTING szabály eth0-n a 192.168.122.0/24-es hálózatra.

Én valahogy így képzelem el,amit írtál.
VPN kliensek (192.168.122.0/24) --- VPN interface(192.168.122.1) SERVER - LAN interface(10.2.0.1) --- LAN (10.2.0.0/24)

Továbbra sem értem, mit akarsz. Belső hálózatod 10.2.0.0/24, a VPN meg 192.168.122.0/24. A VPN szerver a kettő között route-ol és minden megy faszán.
A két hálózat nem lehet ugyanaz a hálózat és nem lehet (nem érdemes) keverni.
Miért kell ezt bonyolítani, mit hagyok ki?

Akkor leírom, hogy mit akarok:

Ha az OpenVPN kliens csatlakozik az OpenVPN szerverhez, az OpenVPN kliens érje el a 10.2.0.201-es IP-t, és az azon futó szolgáltatásokat (tök mindegy, min az OpenVPN kliens IP címe). Továbbá a 192.168.122.201-en elérhető gép legyen a 10.2.0.201 és a 192.168.122.202-n elérhető gép is legyen elérhető a 10.2.0.202 címen, hogy ezeket lássák a VPN kliensek. Ez a célom, ezt akarom elérni.

A VPN kliens pedig csak ezt a 10.2.0.x tartományt lássa. Tehát ne menjen át a teljes forgalom a VPN-en, csak akkor menjen VPN-en adat, ha ezt a tartományt éri el.

A 192.168.122.x is és a 10.2.0.x is belső hálózat szerintem, az én értelmezésemben. Persze, lehet, hogy tévedek.
Az nem tudom, hogy baj-e, hogy a 10.2.0.x-es hálózaton lévő gépeket a VPN szerver sem látja, ami ugyanúgy, mint a többi gép, annak is van egy 10.2.0.x-es ip címe: 10.2.0.123. Tehát a 10.2.0.201 nem látja a 10.2.0.123-at, és viszont. (A 192.168.122-es címeken látják egymást a gépek.)

Remélem, így tisztább, hogy mi a cél.

Sakk-matt,
KaTT :)

Oké elmondom harmadjára is.
Ne, ismétlem ne legyen ugyanaz az alhálózat mindkét helyen! (VPN,LAN)
Ezzel bonyolítod az életed és szivatod magad a végtelenségig.

Szóval.
belső hálózat=LAN

Egyik hálózat egyik oldalon legyen a másik pedig a másikon. Legyenek A és B. "A" hálózat a lanon csücsül, még "B" hálózatot a VPN használja. Ez két hálózat, ami közé valami kapcsolatot kell csinálnod. Erre való a routing. Erre a legalkalmasabb gép maga a VPN szervered, mert mindkét hálózatba belelát. Ezt ő megoldja és már csak a VPN kliensnek kell elmagyarázni, hogy merre van az "A" hálózat. Erre van az /etc/openvpn/ccd mappában a DEFAULT fájl (vagy esetleg közvetlenül beírod a az openvpn konfig fájlba). A következőt kell beírnod:

push "route |"A" hálózat| 255.255.255.0"

Ha nem a VPN szervered az "A" hálózat default gateway-e, akkor szükséged lesz a szervereken is egy plusz routing bejegyzésre.

ip ro add |"B" hálózat címe|/24 via dev eth1

A VPN szerveren engedélyezni kell az ip_forward opciót.
Ha van rajta tűzfal,akkor akkor az "A" és "B" hálózat közötti forgalmat.

"A" hálózat helyére írd be a LAN-od ip címtartományát, még "B" helyére a VPN címtartományát.

|"A" hálózat| jelenti az "A" hálózat hálózati címét! A | jelek nem kellenek!

Röviden ennyi. Step by step. :)
(Ha nem megy privátban keress és segítek!)

Csatlakozom az előttem szólóhoz:

Igazából egy picit még mindig homályos a kép. Tehát:
Van egy géped, melynek az IP címe : 192.168.122.123

Feltételezem, hogy a default gateway-e 192.168.122.1 vagy 254
Ha jól feltételezem, akkor van egy openvpn címtartományod, amit ez a gép oszt ki, ha jól olvasom, akkor ez : 10.2.0.x

Ebben az esetben az első címet felkapja a szerver, a többi címet pedig a kliensek kapják. Ebben az esetben a következő fog történni, illetve a következőket kell tenni.

ki kell push-olnod a 192.168.122.0/24-es hálózatot a klienseknek, hogy ezt az osztott címen keresztül elérjék, továbbá a helyi ( szerver oldalon elérni kívánt hálózatban ) meg kell mondani, hogy a 10.2.0.x hálózat gazdája az az openvpn szerver. Ez történhet a központi routerben, ( amennyiben nem háklis a reverse path filterre ), vagy a gépek routing táblájában.

A VPN szerverben mindenképpen be kell kapcsolni permanensen az ip forwardingot, valamint az iptables-ben is hozzá kell igazítani. ( vagy ideiglenesen kiszedni a szabályokat, amig tesztelsz )

A kollegák teljesen jól mondják:
Felesleges az L2-es kapcsolat, igazából csak az életedet nehezíted, valamint a helyi szervereknek szükségük van a routingra, mert a csomag nem fog visszatalálni.
Azért ajánlom a központi router-t, mert igy egyrészt dokumentált, másrészt nem kell egyéb dolgot tenned a szerverekben egyesével.

Remélem érhetően írtam le, és passzol az eredeti igényhez.

+1
Ha már ketten mondjuk csak lesz foganatja:) és nem ragaszkodik görcsösen a végtelenségig elbonyolított elképzeléséhez.

Köszönöm a választ és kallaicsnak is.

Válaszok:

Van egy géped, melynek az IP címe : 192.168.122.123 - igen
Feltételezem, hogy a default gateway-e 192.168.122.1 - igen
Ha jól feltételezem, akkor van egy openvpn címtartományod, amit ez a gép oszt ki, ha jól olvasom, akkor ez : 10.2.0.x - igen
A VPN szerverben mindenképpen be kell kapcsolni permanensen az ip forwardingot - ez már be van
valamint az iptables-ben is hozzá kell igazítani - ez még lehet, hogy nincs meg, ide mi kellhet?

Az a célom, hogy az OpenVPN gépen ha csatlakoztak a VPN szerverhez, akkor elérjék a 10.2.0.201 címen a 192.168.122.201-es gépet, valamint a
10.2.0.202 címen a 192.168.122.202-es gépet.

Az OpenVPN szerver gépen beállítottam:
ip route add 10.2.0.0/24 via 192.168.122.123

Ez jó út?

Majd valahogy még ha el lenne érve, hogy a 10.2.0.201-nek lássa a vpn felől a 192.168.122.201-et a VPN kliens, valamint ha jól sejtem, be kellene valamit állítani a 192.168.122.201 gépen is, hogy visszafelé is legyen route. Így működhet?

Sakk-matt,
KaTT :)

Ezt magyarázzuk,hogy ezt FELEJTSD EL végre!

"Az a célom, hogy az OpenVPN gépen ha csatlakoztak a VPN szerverhez, akkor elérjék a 10.2.0.201 címen a 192.168.122.201-es gépet, valamint a
10.2.0.202 címen a 192.168.122.202-es gépet.

Az OpenVPN szerver gépen beállítottam:
ip route add 10.2.0.0/24 via 192.168.122.123

Ez jó út?"

A VPN klienseknek a 192.168.122.201 és 192.168.122.202-es IP-re kell felcsatlakozniuk. Ne bonyolítsd feleslegesen!

Biztos, hogy kell lennie megoldásnak. Mert biztos, hogy van megoldás.

A VPN klienseknek a 10.2.0.201-re kell csatlakozniuk, mármint hogy azon az IP-n kell elérniük a nyitott portokat. Van egy kész cucc, ami csak úgy működik.
Szóval így fogom megoldani.

BSD alapon OpenVPN használattal meg is van csinálva jól ez, csak egy hasonlót kell csinálni.
Nyilván az én bénaságom, hogy nem tudom átvenni ezt az egészet egy Linuxon, de biztos, hogy lehetséges.

Ha nem tudtok segíteni, akkor ha kész, érdekességből megírom, hogy mi volt a megoldás, hátha tanulságos lesz.

Azon gondolkozom, hogy jó ötlet-e átrakni a 192.168.122.x-et 10.2.0.x-re, és hogy lehet-e bármi hátránya.
Engem nem az érdekel, hogy mennyire komplex a megoldás, hanem az, hogy működjön.
Persze minél egyszerűbb és átláthatóbb megoldást keresek. Nyilván nem akarom nehezíteni az egészet...

Számomra még az is logikusnak tűnik, hogy az OpenVPN szerveren beállítani, hogy lássák a kliensek a 10.2.0.201-et (ami a 192.168.122.201 valójában), majd a 192.168.122.201-es gépen még valamit beállítani (route, iptables), hogy visszafelé is működjön, az OpenVPN kliens felé, és így elméletben ez működhetne.

Az utóbbira ha van észrevétel, javaslat, hogy mit hogy kellene, vagy hol olvassak utána, az nagy segítség lenne.

Sakk-matt,
KaTT :)

"Biztos, hogy kell lennie megoldásnak. Mert biztos, hogy van megoldás."

Van több megoldás is, csak kérdés mennyire akarod szivatni magad feleslegesen?

Megmondjuk neked a legegyszerűbb megoldást és nem értjük miért ragaszkodsz annyira ahhoz, hogy azonos IP tartományból kapjon a LAN-on is a szerver VPN címet is?
Ha meg tudod érdemben indokolni, akkor tudunk segíteni, hogy merre tovább (optimális megoldás), de ha csak annyi,hogy BSD alapon OpenVPN használattal meg is van csinálva jól ez, csak egy hasonlót kell csinálni. , akkor csak azt tudom javasolni, hogy csináld meg BSD alapon:)

Ettől még nem fogod érteni mi van mögötte, mert ez már világossá vált több hozzászólásoddal korábban is, hogy ismereteid meglehetősen hiányosak. Ennek ellenére én is és mások is írtak kész megoldást neked, mégis ragaszkodsz a Te elképzelésedhez. Remek lenne, ha kicsit képeznéd magad az alapokat illetően. Sztem. a legtöbb fórum tagnak ott csücsül a Tannenbaum könyv a könyvespolcán, amiben több száz oldalon van szó a hálózatokról.
Nem baj,ha kezdő vagy szívesen segítek(segítünk), de helyetted nem akarom(akarjuk) megoldani a problémáid. Segíteni és más helyett dolgozni egész más. Továbbra is fenntartom, hogy szívesen segítek privátban szabadidőm feláldozva.

Ezt szeretném ha jó tanácsnak vennéd és megfogadnád.

Hát igen, na meg az aktív munkatapasztalat. :)

Olvasgatom a nagy hálózati könyvet, most is éppen. Eddig csak bizonyos fejezetekbe néztem bele, de úgy látom, hogy jót tenne egyben elolvasni.
A nyilvánvaló hiányosságom, hogy nem értem pontosan a routing működését jelenleg. A port forwardot, ip cím kiosztást, osztályokat, maszkolást nagy arányban értelmezni tudom.

Ha a jelenlegi cél működne, akkor megérteném a beállításokon át a működést és a mechanizmust.
Nem akarom BSD alapon csinálni, mert tudom, hogy nem azért működik, mert az BSD... :)
Egyszerűen hiányzik pár LEGO elem ismerete számomra, hogy építkezni tudjak. Nem tudom, hogy milyen LEGO építőelemekből építkezhetek (és hogy melyik hogy működik pontosan, és azt sem, hogy pontosan melyik LEGO elemet kellene felhasználnom, bekonfigurálnom a cél eléréséhez). A jelenleg számomra ismert LEGO elemekből nem megvalósítható a megoldásom, ezért írtam, kérdeztem és ezért olvasok mellette szakirodalmat.
Tisztában vagyok a gyengeségeimmel, és ez a kihívás pont jó, hogy fejlődjek, hogy megértem, hogy mi a megoldás.

Sakk-matt,
KaTT :)

Olvasgatom a nagy hálózati könyvet, most is éppen. Eddig csak bizonyos fejezetekbe néztem bele, de úgy látom, hogy jót tenne egyben elolvasni.
A nyilvánvaló hiányosságom, hogy nem értem pontosan a routing működését jelenleg. A port forwardot, ip cím kiosztást, osztályokat, maszkolást nagy arányban értelmezni tudom.

Helyes plusz pont érte. Routing lényege,hogy bejön egy a csomag a gépre. A gépnek van (legalább) egy ún. routing táblája, ahol meg van tanítva neki,hogy melyik hálózatot merre találja (amibe belelóg). Ez alapján próbálja a csomagot továbbítani a megfelelő irányba. Ha legegyszerűbb esetet vesszük ,akkor minden gép azt a gépet tudja,hogy kinek kell tovább adni a csomagot a hálózatán belül. Utána majd a címzett gép továbbítja a következőnek és így tovább.

Ha a jelenlegi cél működne, akkor megérteném a beállításokon át a működést és a mechanizmust.

Helyes, de először tervezünk utána jön a megvalósítás. Nem szégyen lerajzolni, amit szeretnél. (Még ha egy egyszerű dologról is van szó, később persze meg majd fejből is:) )

Tisztában vagyok a gyengeségeimmel, és ez a kihívás pont jó, hogy fejlődjek, hogy megértem, hogy mi a megoldás.
Jó hozzáállás, mert ez egy olyan szakma, ahol életed végéig tanulni fogsz:)

Az openvpn szerver látja ezt a hálózatot, igy oda nem kell route. A klienseknek kell egy push route a belső hálód felé.

# Push routes to the client to allow it
# to reach other private subnets behind
# the server. Remember that these
# private subnets will also need
# to know to route the OpenVPN client
# address pool (10.8.0.0/255.255.255.0)
# back to the OpenVPN server.
;push "route 192.168.10.0 255.255.255.0"
;push "route 192.168.20.0 255.255.255.0"

tehát push "route 192.168.122.0 255.255.255.0"
Ő majd ezt jól rároute-olja a kialakult interface-re.

A csomagod azért nem talál vissza, mert a szerverek nem ismerik a 10.2.0/24-es hálót, ezért ezt a default gateway felé továbbítják. Ha a default gateway-nek megmondod, hogy a 10.2.0/24-es hálózat a 192.168.122.123-őn található.

Egyelőre ne erőltessük az iptables-t, egy iptables -F -nél erősebben.

Persze ha a servereken van lokális fűzfal, ami nem engedi be a VPN klienseket, az baj, azt orvosolni kell.

Különösen kártékonynak találom, ha csak ezért a szervereknek is kialakítasz egy 10.2.0-ás címet, mert egyrészt nem tudod leszabályozni, hogy ezt kiossza a VPN szerver, mindazonáltal a kialakíott hálózat L3, és a VPN szerver nem azon az interface-en fogja keresni a feloldását, ahol te szeretnéd ( eth0 ), mert ez a hálózat nála a TAP interface-en van.

Ha beállítottad és felcsatlakoztál, akkor ellenőrizd a routingot. Ha helyesen felvette. ( rároute-olta a 192.168.122.0-át a tap interface-re ), akkor már nyert ügyed van.
Milyen routered van a szerverek felett? ( mi tartja a default gateway-t? )

Ha így teszel, akkor a 192.168.122-es címen ülő szervereid tudnak IP szinten kommunikálni a 10.2.0-ás kliensekkel, direktbe, csak vedd le róluk a 10.2.0-ás címeket.

Köszönöm Imi, kallaics és mindenkinek az észrevételeket és a segítséget.

Mi lenne, ha a szerverek nem a 192.168.122.x/24-ben, hanem a 10.2.0.x/24-ben lennének? Akkor nem kellene kialakítani +1 hálózati címet.
Akkor a VPN kliensek el tudnák írni a 10.2.0.201-et, igaz? Már csak kérdés, hogy az OpenVPN kliensek is a 10.2.0.x/24-es tartományban legyenek-e (ahogy BSD-n), vagy valami más tartományban?

Sakk-matt,
KaTT :)

Nem.

Amit leírtam, az az egyetlen hálózatilag helyes kialakítás. L3 hálózat esetén.

Amúgy TAP helyett is TUN-t kellene használni.

Köszönöm.

Az OpenVPN-ben beállítottam a push-t, amit írtál. Átállítottam TAP-ról TUN-ra.
Az OpenVPN kliensek jelenleg 10.11.0.x/24-es tartományból kapnak IP címet. Ez jó így, vagy más legyen?

Mit kell beállítanom konkrétan az OpenVPN szerveren, a 192.168.122.123-on?
Mit kell beállítanom konkrétan a 192.168.122.201-es gépen?

Sakk-matt,
KaTT :)

Postold be a konfigot plase.
Ird meg a router tipusát.
Hallgass ránk. ;)

Az OpenVPN tap-ként működik megfelelően, 10.11.0.x-es IP-t kap jelenleg az OpenVPN kliens, de ezt könnyű átállítani, hogy mást kapjon.


/etc/openvpn/server.conf

port 1194
proto tcp
dev tap
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key # This file should be kept secret
dh /etc/openvpn/easy-rsa/keys/dh2048.pem
ifconfig-pool-persist ipp.txt
server-bridge 10.11.0.30 255.255.255.0 10.11.0.31 10.11.0.87
push "route 192.168.122.0 255.255.255.0"
keepalive 30 300
comp-lzo
max-clients 30
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 4

Libvirt + LXC-n belül fut az összes gép: a VPN szerver (192.168.122.123) és a 201 és 202 is.

A host gépről:

ip route
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.111
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
169.254.0.0/16 dev eth0 scope link metric 1002
169.254.0.0/16 dev eth1 scope link metric 1003

A VPN szerver gépről (192.168.122.123):

ip route
10.2.0.0/24 via 192.168.122.123 dev eth0
192.168.122.0/24 dev eth0 proto kernel scope link src 192.168.122.123
169.254.0.0/16 dev eth0 scope link metric 1002

Milyen információ kell még?

Sakk-matt,
KaTT :)

A 10.11.0.x hálózatról idáig nem volt szó;(

A 10.11.0.x-et most állítottam át, próbából, mert megnéztem valamit, az alapból 10.2.0.x/24 volt.
Akkor azt vegyétek úgy, hogy 10.2.0.x/24, mindjárt át is írom.
Csak valaki azt javasolta, hogy legyen különböző a VPN kliens hálózat, mint a 10.2.0.x/24, azért írtam át.

Sakk-matt,
KaTT :)

port 1194
proto tcp
dev tun
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key # This file should be kept secret
dh /etc/openvpn/easy-rsa/keys/dh2048.pem
ifconfig-pool-persist ipp.txt
server 10.2.0.0 255.255.255.0
push "route 192.168.122.0 255.255.255.0"
keepalive 30 300
comp-lzo
max-clients 30
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 4

A hoston-en mit keres a 122 rároute-olva a virbr-re?
Mondjuk ha már route-okat mondasz, akkor már elindíthattad volna a klienst.

a szerveren mit keres a 10.2.0-ára az eth0-ra route-olva?
Nagyon megkeverted ezt a routing dolgot..

Azt ugye tudod, hogy ezért a munkáért akár nagyon sok pénzt is kérhetnénk lassan.... .

A szerver routing táblájanak valahogy igy kellene kinéznie:

10.8.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 eth0
0.0.0.0 192.168.122.1 0.0.0.0 UG 0 0 0 eth0

Ha nem megy a TUN, csak a TAP az OpenVPN-en, az itt

http://hup.hu/node/141854

ismertetett probléma miatt, akkor az maradhat TAP, vagy úgy nem tud működni?

A TAP a jelenlegi tudásom alapján jobb a célra, hogy működjön a Windows gépről a Samba megosztás (202-es gép), tallózás, stb.
Azt olvastam, hogy TUN esetén sok speciális probléma lehet, hogy nem működnek bizonyos dolgok.
A TUN viszont megy okostelefonokon is. Szóval én örülnék, ha működne TUN-on.

A hoston-en mit keres a 122 rároute-olva a virbr-re? - Azt alapból a Libvirt állítja be szerintem, amikor felhúzza a virbr-t.
A szerveren mit keres a 10.2.0-ára az eth0-ra route-olva? - Próbálkoztam megoldani... :-)

A szerver routing táblájában a 10.8.0.2-t nem értem pontosan. Akkor mostantól lesz egy 10.8.0.0/24 is?

Azt ugye tudod, hogy ezért a munkáért akár nagyon sok pénzt is kérhetnénk lassan. - Igen, sejtem. Azonban amikor az elmúlt több mint 10 éven összesen száz+ órát, vagy ki tudja mennyit segítettem ismeretleneknek IRC-n, vagy levelezve, akkor arra gondoltam, ha majd én is megakadok valahol, akkor jogos lesz, hogy visszakapom egy részét annak, amit én ráfordítottam mások segítésére. Persze semmi sem jogos, semmi sem kötelező és semmi sem jár. Én a másoknak segítséggel nagyon sokat fejlődtem, mert utána néztem a problémának és a megoldást később én is fel tudtam használni, mint tudás. Persze ez az én hozzáállásom, azonban jogos a felvetésed, nem kérdéses.

Sakk-matt,
KaTT :)

Megértem a felháborodásod, de miután leírtuk, hogy mit kell csinálni, ugy gondolom megtettem mindent.

A route példa csak példa volt, nálad a 10.8 helyett 10.2 lesz.

A libvirt sajnos nem leszt jó, mert azonos lesz a szerver hálózattal, de mivel ez natra van, ezért nyugodtan megváltoztathatod, alapból ugy sem használod. Ezt guin virt-managerrel megteheted.

Félre értesz, nem háborodtam fel... :)
Egyszerűen csak keresem a megoldást... peace! :)

Sakk-matt,
KaTT :)

Jó.

A következő lépés, hogy átírod a kliensen, hogy a virbr más címmel legyen, mert a connected route erősebb, mint a static.

Ha ez is megvan, akkor csatlakozz fel az általam küldött konfigra és nézzünk routing táblát...

Az általad küldött OpenVPN konfigurációval elhasal az OpenVPN... Nem indul el, mert nincsen TUN. Ez nem a te libád, azaz hibád... :)

A következő lépés, hogy átírod a kliensen, hogy a virbr más címmel legyen, mert a connected route erősebb, mint a static.
A kliens alatt a host gép LXC kliensét, azaz konténerét érted? Vagy az OpenVPN klienset?
A host gépen van virbr0 csak, tehát azt értheted, de az meg számomra nem kliens.

Ha megvan, hogy mit, akkor mire írjam át? 10.2.0.x/24-re? Más tartományra? Vagy mire gondoltál?

Sakk-matt,
KaTT :)

Csak átírtam a konfigodat, nem próbáltam ki. Biztos hogy van benne hiba, de ezt egy kis google, meg egy csomaglista nézegetés megoldja.

Hogy mire írod át a virbr-t, azt tökmindegy, csak ne a kliens és ne a szerver ip subnetre, mert pont az overlapot akarod elkerülni.

Köszönöm az eddigi fáradozásodat Imi.

A virbr0 nem azért van, hogy a LXC-s konténerek azon keresztül érjék el egymást? Libvirt húzza fel, ha elindítom, úgy tudom.
Meg lesz veth0, veth1, veth2 is, a konténereknek, amiknek a host-ról nézve csak IPV6 címük van, ha megy a Libvirt.

Jelenleg ezen a 192.168.122.0/24-es hálózaton kommunikálnak egymással az LXC-s konténerek (szerverek).
Sőt, ha akarom, ki is tudnak látni az internetre ( dhcpclient eth0 )

Átírnám én a virbr0-t bármire, ha érteném, hogy miért kell ez, miért nem jó.
Miért nem jó a 192.168.122.x/24 a virbr0-nak?
Sőt, nem is kell értenem, átírhatom. De akkor adjak új tartományt és IP címeket az LXC-s konténerben lévő is?
Az én tudásom alapján a virbr0 és a szerverek szándékosan vannak egy hálózaton.

Tehát az elsődleges cél, hogy a 10.2.0.201-es címet elérje a VPN kliens, ami lehetőleg TAP, mert a TUN nem működik és a TAP-os megoldás az eddig használt. Ha működne a TUN az LXC-n belül, akkor szívesen megnézném...

Másodlagos cél, hogy ha lehet, ne bombázzuk szét a már működő 192.168.122.x/24-es hálózatot. Ha ez nem megoldható, akkor az elsődleges cél miatt ez sem gond, csak jobb lett volna ezt nem bántani, ha már miden jól működik ezzel kapcsolatban.

Ma már nem nagyon leszek a gép előtt, holnap újra leszek, megújult erővel, és remélhetőleg frissült tudással... :-)

Sakk-matt,
KaTT :)

Ui.: Kezd ez a téma kicsit kalandjáték hangulatú lenni: egy nagyon rosszul látó ( = én) mászik / kúszik / rohangál egy csapdákkal, tükrökkel, éneklő unikornisokkal teli labirintusban, akit a föntről, és különböző szemszögből néző segítők ( = ti) irányítanak, hogy túlélje és kijusson. Ezt vegyétek természetesen önkritikának.

Ha futó szolgáltatások vannak a hoston, amiknek az ip-je 192.168.122, akkor ne csinálj semmit, mert akkor csak kárt csinálsz.

Azért ez fontos kiegészítő lett volna ide is ... .
http://hup.hu/node/141854

A küldött config fut egyébként. Csak az architektúrára nem fordítottál figyelmet.

Szia Imi!

Átraktam a konténereket a 10.2.0.x címre, így akkor az ip címe, amit el kell érni:
10.2.0.201

Így a host (10.2.0.1) is látja a 10.2.0.201-et és viszont.

A host-ra felraktam az openvpn-t, nem konténerben fut, mert a jelenlegi lxc + libvirt xml-es konfigjában nem találtam megoldást a tun használatára.

Így megy a tap/tun, és elérhető is a szerver. A tun-os megoldás lett, ahogy javasoltad.
Van push a 10.2.0.0-ra, és működik megfelelően.
Bár most fogom tesztelni az egészet.

Köszönöm a segítséged, és köszönöm mindenkinek, aki segített.

Még megpróbálom esetleg tap-ra átrakni, ha nem fog minden működni megfelelően.

Ha mindkét gépen az openvpn a drbd-ről olvassa a kulcsokat és a konfigurációkat, akkor zavarni fogja ez az openvpn klienseket? Ha jól gondolom, nem.

Sakk-matt,
KaTT :)

Ha jól értem így néz ki a hálózat:
LAN1(192.168.122.201 és 10.2.0.201) - LAN2 (192.168.122.202 és 10.2.0.202 - SERVER (192.168.122.123 és OVPN 10.2.0.123) - OVPN kliensek (10.2.0.x)

A 10.2.0.201 és .202 akkor látszódna OVPN felől, ha azok is OVPN-en keresztül kapnák ezt az IP-t és a client-to-client be van kapcsolva, de ez most nem így van.

A LAN-os gépeket sima routinggal elérheted az OVPN felől a 192.168.122.20x IP címükön.
Ha az OVPN kliensekkel tallózni szeretnéd a belső gépeket, akkor az meg a bridge módú OVPN telepítéssel menne.

Úgy látom, te kb látod, hogy mit szeretnék.

Az OpenVPN szerver tap-ot, ethernet tunnelt használ.

Én láttam ilyen feladatra olyan megoldást, hogy nem volt client-to-client az OpenVPN szerverben és működött az elérés az OpenVPN klienseknek a 10.0.2.x-es IP cím felé. Ott ha jól emlékszem egyenként volt routing beállítva az OpenVPN kliens fix IP címekre, hogy mit lásson. Ez nem volt szép, viszont működött és nem látták egymást a kliensek.

Én szép és értelmes megoldást keresek.

Egyszerűen, hogy kap az OpenVPN szervertől IP-t az OpenVPN kliens (mindegy számomra, hogy mit, nincs korlátozás), majd szépen eléri a 10.2.0.201-es és 10.2.0.202-es gépet, amin lehet http/samba/ftp/ssh/pop3/imap. A Windows OpenVPN kliens fel tudja csatolni, mint megosztott meghajtót a 10.2.0.202-ről. Ennek kell mennie.

Sakk-matt,
KaTT :)

Na, ha tap, akkor bridge módban fut az OVPN server, annak másodlagos, 10.2.0.123-as IP-jét használva, és persze a kliensek látják egymást.
Az OVPN HOWTO alapján a tűzfal szabályokhoz ennyi kell:

iptables -A INPUT -i tap0 -j ACCEPT
iptables -A INPUT -i br0 -j ACCEPT
iptables -A FORWARD -i br0 -j ACCEPT

Nem látok semmi változást sajnos.

Sakk-matt,
KaTT :)

Az OpenVPN hálózat és a belső LAN NE(!) legyen egy IP tartomány! (a szervereidnek nem kell 10.2.x.y másodlagos IP)

A LAN a 192.168.122.0/24-es hálózat, a default GW az OpenVPN szerver (és router egyben - ha nem, akkor kicsit bonyolódik a dolog)
A VPN a 10.2.0.0/24-es hálózat, a klienseknek pedig OpenVPN conf-ból push route-al kiküldöd, hogy static route a 192.168.122.0/24 felé a VPN szerver.

Ezen felül már iptables tűzfal szabályokkal játszadozhatsz, hogy melyik kiosztott IP érje vagy ne érje el melyik szervereket.

-------------------------------^v-----------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Szia!

Oké, akkor kiszedem a 10.2.0.x-es másodlagos IP címeket mindenhonnan.

A 192.168.122.123, az OpenVPN szerver lesz a default gw. ()
A VPN lesz a 10.2.0.0/24-es hálózat. Küldök push-t:

push "route 10.2.0.0 255.255.255.0"

Honnan fogja tudni az OpenVPN kliens, hogy a 10.2.0.201 az a 192.168.122.201 ?
Egyenként, minden portjára kell tenni forwardot a 201-es ip-s gépnél, és ip-nént külön, vagy hogy érdemes?

Sakk-matt,
KaTT :)

1., push "route 192.168.122.0 255.255.255.0" - azaz a VPN kliens a LAN szervereid címeit a VPN szerveren át keresse, míg a default GW-e marad a saját netkapcsolata által adott (gond lehet, ha ő is épp 192.168.122.0-es hálózaton netezik valahol, de ez kis esélyes)

2., ezután a VPN kliensen is neked a 192.168.122.201-et kell keresned, a 10.2.0.201 nem is létezik, felejtsd el!

3., port forward nem kell itt semmihez. Ha a route-ok jól vannak beállítva, akkor a szerver(ek) és a VPN kliens(ek) a 2 különböző IP tartományból szépen látni fogják egymást

ui.: persze hibák biztos hogy lesznek a konfigban, amik miatt elsőre nem fog menni és ha nem látod át, mi miért működik, akkor baromi nehéz lesz őket megtalálni :/ (pl. mikor az egyik oldalon mégsem jó a route és bejön a csomag, de vissza nem talál)

-------------------------------^v-----------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

A default gateway nem fog gondot okozni, ha én csak azt szeretném, hogy a 10.2.0.x-es hálózatot érje el az OpenVPN szerveren át, a többi forgalom menjen a VPN-től független irányban (az internetre, a router-en át)?

Sakk-matt,
KaTT :)

sub