[MEGOLDVA] OpenWrt VPN két router között

Hálózatok egyéb

Mint azt a címben jeleztem, szeretnék kapcsolatot "állandó" teremteni két TL-WR1043BD ver:1.8 (32M RAM) OpenWrt router között.
Az egyik router Bp. nyócker, az internetről látható (pingelhető) UPC hálózaton "csücsül" - mögötte egy kis Linux szerverrel és általában legalább 2 munkaállomással.
A másik router Nógrádban a vidéki házamban a helyi szolgáltató hálózatán és NEM látható/pingelhető az internetről. Első lépésként, szeretnék egy RPI -vel felépített kamerát és néhány érzékelőt (hőmérséklet, páratartalom, csapadék stb) feltenni amit az internetről is el akarok érni.
Szeretném ha a kapcsolatot a két router egymásközt megoldaná. Először az ssh tunnel -re gondoltam - ilyet már csináltam, működőképes megoldás de ahogy jobban belementünk a történetbe, a kapcsolat megbízható fenntartása nehézkesnek tűnik. Javasolták, hogy inkább vpn -el próbálkozzak. Még nem tudom elég lesz-e a routerek kapacitása erre a feladatra de tegyük fel, hogy igen.
1. A vpn -el kapcsolatban mindenütt a vpn szerver és egy vagy több kliensről beszélnek. Nekem nem világos ki is az én esetemben a szerver és a kliens (két router)?
2. Két alapvetően más megoldásról beszélnek a bridge és a tunnel. Nem készülök (egyenlőre) windows szervert üzemeltetni. Így a tunnel lenne a megoldás. Viszont ezt nem igazán értem. Hogy fogom elérni, hogyan érhetem el közvetlenül (Bp.-en és bárhol az interneten) a nógrádi házam routerén lógó RPI-s kamerát (ami mondjuk http -n érhető el)?
Ha ssh tunnel, akkor kettőre van szükségem, ssh elérés és a kamera http portját. Lehet, mégis túlzás a vpn?

SZERKESZTÉS: Később közreadom a teljes működő konfigurációt. Valójában ami fenn van a pastebin -en használható, lehet elég ha az srv-vpn.conf fájlban a kliens path -t abszolút path -ként definiálod /etc/openvpn/ccd

  • 25055 megtekintés

( Skuzzy | 2016. 01. 30., szo – 14:27 )

Szerver praktikusan az lesz, ami publikusan elérhető a másik számára. Jelen esetben a bp.-i a szerver, a másik a kliens.
Openvpn-nél az az alap, hogy a vpn kapcsolat kap egy külön ip tartományt, ami független a két router 'belső' tartományaitól.
Hogy a két belső tartomány elérje egymást, be kell állítani, a rountingokat, 'push route' -nak nézz utána.
Nálad lehet, hogy trükközni kell majd kicsit kézzel is a routing-gal, mert a bp-i belső hálód nem egy másik kliensen keresztül kapcsolódik a másikhoz, hanem a szerverre közvetlenül, de ezt most hirtelen meg nem mondom.

Köszönöm a választ!
Igen a publikusan elérhető router szerver kell hogy legyen.
Kicsit zavaros a történet (látszólag egyszerű) de mégis ki a kliens ezen a hálózaton?
Alapvetően így lenne a hálózat:
kliens_A.x - VPN_szerver_A - VPN_izé_B - kliens_B.y

A "VPN_szerver_A" és a "VPN_izé_B" a két router.

a vpn kapcsolat kap egy külön ip tartományt, ami független a két router 'belső' tartományaitól.

Tehát van egy A hálóm és egy B hálóm, amit egy C virtuális(?) háló (azaz cím tartomány) kapcsol össze?
A C virtuális háló címeihez kell rendleni az A vagy a B háló valamely gépének címét? Ez lenne a "push route"?
Mit kellene telepítenem a "VPN_izé_B" routerre, ha nem VPN szervert? A "VPN_izé_B" szolgáltatná a csatornát (TUN) a B háló számára ...
Én ezt még mindig nem értem :( Hogy lesz ebből "privát hálózat"?
Az OpenVpn dolgai között még nem találtam meg ezt a konfigurációt. Bár az is lehet ez a TUN (vagy TAP) interfészt létrehozó és a titkosítást biztosító programnak semmi köze, ez csak egy tool (ahogy ott ezt írják is) de a kapcsolatokat valahogy nekem kell összeraknom úgy , ahogy megálmodtam (már ha tudom).

* Én egy indián vagyok. Minden indián hazudik.

Nálam az otthoni és a szüleim hálózata van vpn-nel összekötve, annyi a plusz, hogy nálam van egy 3.pont egy vps személyében, azon fut az openvpn szerver. Az otthoni és a szüleim 'routereken' openvpn kliens. Az egyik tomato firmware egy linksys routeren, a másik normál linux-os nas.
Annyi lényeges, hogy a két helyen ne azonos ip tartomány legyen kiosztva.
Nálam 192.168.9.0 , szüleimnél 192.168.10.0 , az openvpn-en 10.x.0.0 van beállítva, ebből oszt a szerver a klienseknek egy egy p2p kapcsolatot. A szerver config-jában be lehet állítani, hogy a kapcsolódó klienseknek milyen másik kliens belső ip tartományát push-olja át. így amikor egy kliens kapcsolódik, felveszi a vpn ip címét, és kap egyéb tartományokat is, akkor ha abba az irányba megy kérés, beletolja a vpn-be. Openwrt-re mit kell pontosan telepíteni nem tudom, de szerintem van openvpn csomag rá. Az egyiken egy jó szerver config-gal, a másikon egy kliens config-gal kell elindítani.

Tehát a router(ek) mögül erre, a 10.x.0.0 cím tartományra kell "csak" hivatkozni, és a router az ott beállított/pusholt routnak megfelelően összeköti a másik hálón ülő géppel?
Az "x" ugye valami számot feltételez?
Nem fog ez "belerondítani" az általam elérhető internetes cím tartományba?

* Én egy indián vagyok. Minden indián hazudik.

( ncc1701 | 2016. 01. 30., szo – 15:05 )

1: site to site vpn leírást keress. Itt az a szerver, amelyikre szt mondod, h szerver. Lehetőleg fix ip-vel, bár openvpn-nek jó dinamikus dns név is.

2: tunnel esetén két külön ip cím tartományban kell lennie a két hálózatnak. Ha megvan a vpn, (tűzfal, routing) akkor simán az ip címével eléred a túloldali eszközt.

Azaz mindkét routerre fel kell pakolni a (mondjuk) az openvpn -t majd az egyiket szervernek a másikat kliensnek kell konfigurálni?
"Ha megvan a vpn" - ez alatt a tun (esetleg tap) virtuális interfészre gondolsz?
Mondjuk B hálózaton (a vidéki) 192.168.x.1 -es címen csücsülő RPI https portját (443-as) az A hálózat munkaállomásáról el kell tudnom érni ha a navigációs sorba beírom: https://192.168.x.1
Gondolom az A oldali (vpn szerver) router iptables -be kell egy olyan szabály, hogy a x címtartományba irányuló kéréseket a irányítsa a "tun" interfészre?
HF: Megnézni a site to site vpn leírásokat.

* Én egy indián vagyok. Minden indián hazudik.

Igen, mindkettőre felteszed, egyik configba beállítod, h hová kapcsolódjon, másikban csak portot kell megadni.
A megadott portokat ofc tűzfalon kinyitni.
Lesz két tun intf-ed az 1-1 gépen, egy harmadik ip cím tartománnyal, a két router egy tartományba legyen ofc.
Static kulcsot legenerálod, megoldod, h mindkét routeren ugyanaz legyen.
Configba route szabályt beteszed (értelem szerűen).

Ha küldesz mailt, akkor küldök 1-1 minta cfg-t, bár én linuxon használom, openwrt eléggé hasonló lehet.

Üzenet ment - előre is köszönöm!
"A megadott portokat ofc tűzfalon kinyitni." - mi az az ofc?
"a két router egy tartományban legyen" - azt hogy?
A WAN oldali ip cím nem az én "kompetenciám" (ráadásul az egyik nem látható a neten) a másik oldal meg egy-egy LAN, amiről azt mondtuk más-más tartomány.

* Én egy indián vagyok. Minden indián hazudik.

ofc -t én of course -ra tippelem :-)
A két router egy tartományba legyen mondat megtévesztő, nem lehet másban úgy sem. A szerver configban állítod be, hogy mi legyen az a közbenső tartomány, és ő fog osztani abból a csatlakozó klienseknek, illetve magának is mindig a p2p kapcsolat saját oldalára, így egyben lesznek.

"Gondolom az A oldali (vpn szerver) router iptables -be kell egy olyan szabály, hogy a x címtartományba irányuló kéréseket a irányítsa a "tun" interfészre?"
igen, ezt valszeg kézzel kell megadnod, erre utaltam az elején, a kliens oldalra ez nem kell kézzel, ha jól belövöd a push route-okat, akkor a visszafelé irányt ő belerakja a sajátjába automatikusan a csatlakozásnál.
Mert ugye B oldal-nak is tudnia kell, hogy hogy éri el az A hálózatot.

Még egyszer próbálom összefoglalni:
1. a szerver oldalon valszeg kézzel kell megadnod a routing-ot (vpn kofigtól 'független' módon), mert az ottani belső lan nem egy kliensen keresztül kapcsolódik, hanem a szerver routerre közvetlenül, de erre írtam, hogy ilyet nem próbáltam még, ezt tippelem csak, ki kell próbálni, én így képzelem
2. a kliens oldalon a push route megoldja automatikusan a routing beállítást, a push route-ot a szerver oldalon az openvpn konfigjában állítod be, milyen kliensnek, mit push-oljon. (pontosabban a push route-okat mindegyiknek default küldi, ha valakinek nem akarsz valamit közülük (a sajátját vissza pl), azt külön lehet kliensenként kikapcsolni)

Köszönöm! Bocs az értetlenkedésért, de még mindig kicsit homályos a logikája a dolognak. Nincs mese össze kell rakni és megnézni hogy működik :)
OFF: A TCP/IP protokoll nem egy ördöngösség és valahogy még nem találtam olyan leírást a vpn -hez ami tisztán leírná a működési mechanizmust, hogy én is értsem. Howto az van dögivel, a tun/tap különbséget is jól leírják de azt, hogy a csomagok, hogy is kerülnek a tun interfészbe, majd a túloldalon átforduljon az ottani címre stb. azt valahogy nem láttam.
Még kicsit kutatnom kell.

* Én egy indián vagyok. Minden indián hazudik.

Az előző hozzászólásom két pontja azt eredményezi, hogy mindkét routerben lesz 1-1 bejegyzés, hogy a másik router belső hálójára menő csomagokat zuzza bele a tun-ba.
példa 192.168.9.0-ban lévő kliens routing táblája, két másik kliens belső hálózatával(ezek jöttek a push-sal) és a vpn 10.111.0.x -es címeivel:
$route -n

Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.9.1 0.0.0.0 UG 0 0 0 p3p1
10.111.0.0 10.111.0.13 255.255.255.0 UG 0 0 0 tun0
10.111.0.13 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.168.2.0 10.111.0.13 255.255.255.0 UG 0 0 0 tun0
192.168.9.0 0.0.0.0 255.255.255.0 U 0 0 0 p3p1
192.168.200.0 10.111.0.13 255.255.255.0 UG 0 0 0 tun0

tényleg nem egy ördöngősség, ha valamit a tunelbe akarsz, azt bele kell routolnod:-)

( tovis v | 2016. 01. 31., v – 18:02 )

Hát a Bp. router -re "feldobtam" az openvpn. Ahogy lenni szokott egyik howto sem teljesen tökéletes, pl. hivatkoznak egy /etc/openvpn/openvpn.cnf -re de az nincs, csak az /etc/config/openvpn létezik.
Lehet az egy minta, mivel tartalmazza a szerver és a kliens oldali konfigurációt is ... viszont a tesztek azt mutatják hogy szerverként üzemel (sok default paraméterrel).
Talán, a kliensnél kipróbálom, hogy bemásolom az /etc/openvpn könyvtárba a szerkesztett konfigurációs fájlt. Furcsa de még nem látom a scriptekből (pl /etc/init.d/openvpn) hogy honnan is szedi alapvetően a konfigurációt.
Az OpenWrt verziója Attitude Adjustment 12.09 - ezt javasolják a TL-WR1043ND -re.
Sajnos, az openvpn -nek nincs "interfésze" a Luci -hoz :(
(Szerencsére a parancssor sem idegen :)
Persze a döntő az lesz ha a klienst is feltelepítem és összekötöm a két outert.

* Én egy indián vagyok. Minden indián hazudik.

Mint mondtam, rengeteg howto van. Mind kicsit másként írja le a dolgokat (más verziókra is vonatkozik). Az említett minta openvpn konfiguráció is rengeteg megjegyzést tartalmaz, akárki csinálta szorgalmas volt, viszont így nehezen áttekinthető. Érdemes lesz "kigyomlálni", csak azt kell kiderítenem hozzá honnan akarja valójában elővenni a konfigurációt, úgy tűnik beleforgatták. Lehet az openvpn site -on lesz a válasz.
A konfigurációban megjelenik pár minta *list push x.x.x.x y.y.y.y* a push érthető az ip cím tartomány és maszk is de mi az a list? A manual nem tartalmaz ilyen direktívát - tény hogy az init.d -ben lévő script is a parancssorba nyom be egy nagy kupac parancssori paramétert.

* Én egy indián vagyok. Minden indián hazudik.

( tovis v | 2016. 02. 03., sze – 16:34 )

Most jól behúztak a csőbe?
Nézegettem a különféle howto -kat és közben rájöttem, hogy az általam használt OpenWrt verzió - ATTITUDE ADJUSTMENT (12.09, r36088) - igencsak elavult. Hát akkor mielőtt tovább lépdelnék upgradelni kéne a 15.05 -ös verzióra, biztos jobb és többet tud.
Hát nem igazán jött be, lehet több gondot okoz mint amit megold. Nem tudom kikapcsolni az IPv6 -ot. Van róla több helyen is szó, több konfigurációs fájl módosítása kell és egy kupac modult, köztük kernel modult is ki kell venni az inicializációból, így viszont tartok tőle hogy nem fog rendesen működni a router mint olyan. Ráadásul alapból jóval több memóriát használ.
Most mit, maradjak a kaptafánál?
Az openvpn konfigurációk is inkább a szervert favorizálják, a klienst nem annyira taglalják.

* Én egy indián vagyok. Minden indián hazudik.

A "rakat" az van. Más verziókra. Valójában lehet a "forrástól" kellene elindulni, azaz az openvpn.org - a gond az hogy még mindig kicsit homályos a mechanizmus.
Illetve most az lenne a legfontosabb hogy a legfrissebbel haladjak vagy elégedjek meg régivel. Lehet át kellene nyálaznom mi más változott a verziók között, azonkívül hogy szervesen beleépítették az ipv6 -ot ami nekem inkább csak nyűg.

* Én egy indián vagyok. Minden indián hazudik.

Vannak használható olvasnivalók az openvpn.org-on (meg az openwrt-n is), néhány dolgot érdemes elolvasni, de szerintem nem akarsz túl mélyen belemenni. A más verziókon nagyon ne aggódj, olyan oltári változást nem tapasztaltam az elmúlt években.
Én mindenképp a frissebbet használnám, még ha több nenóriát eszik is. Erre én swap-et használok a 1043nd-n (én alapban extroot-olok, és a legkisebb pendrive-on is elfér pár mega swap).

Az ipv6 nem annyira nagy kaland, ha jól emlékszem az egyes interface-eken ki tudod kapcsolni (talán ipv6 paraméter?), illetve raksz túzfalon ipv6 drop-ot vagy reject-et minden láncra (input, output, fwd).

Pont ugyanarra jó, mint "normális" gépen. Tetű lassú, de ami nem kell azt a RAM-ból ki tudja oda lapátolni a kernel.

Ehhez egyébként nem kell extroot, az extroot arra jó, hogy ami a router flash-en van azt kirakod pendrive-ra, így több helyed lesz. Szóval ha van flash bőven akkor ez nem kell, de a 8 mega flash-ből elég könnyen ki lehet futni. Nekem legalábbis könnyen sikerült.

( tovis v | 2016. 02. 03., sze – 21:57 )

Egyenlőre maradok a kaptafánál. Miután (eléggé nehezen) beindítottam az openvpn szervert (csak épp hogy fut), alapterhelés mellett (nincs vpn kliens) a 29M -ból még van 9M RAM -om.
Most kellene tesztelni, de ehhez kellene egy működőképes kliens, vagy van valami alap teszt amivel látom hogy akár működhet is?
Kicsit nehéznek tűnik a beállítás, ha egyik oldal felől sem lehet biztos.
pl. meg lehet pingelni a tun interfészt? Vagy ez teljesen értelmetlen?

* Én egy indián vagyok. Minden indián hazudik.

Köszönöm! Megfontolom.
Az egyik WR1043 -as évek óta működik ezzel a firmware -el kifogástalanul.
IPv6 nálam még nincs, így az új verzió épp semmit nem ad viszont elveszi a memóriát, pont annyit amivel még biztonsággal(?) működtethetek egy openvpn -t. Akkor most melyik firmware verziót is használjam?
FLAME: IPv6? - ultrahangos medvecsapda.

* Én egy indián vagyok. Minden indián hazudik.

( tovis v | 2016. 02. 04., cs – 17:07 )

Kezdődnek a buta kérdések
A szerveren generáltam egy kupac ceritificate -et:
#ls /etc/openvpn
ca.crt
dh1024.pem
server.crt
server.key

Most, ahogy próbálom összerakni a kliens konfigurációt:
A kliens azonos könyvtárába kell másolnom a szerver dh1024.pem kulcsát?
A kliens oldalon nem kell semmilyen kulcsot generálnom?
Látszik hogy lövésem sincs, hogy is épül fel ez a kapcsolat.

SZERK: Még valami, szerintem nekem nem kell sok kliens, valójában elégséges, a két router elintézi a kapcsolatot nem?

* Én egy indián vagyok. Minden indián hazudik.

Egyenlőre az openvpn dokumentációra támaszkodva átmásoltam az ott felsorolt kulcsokat és certifictokat.
Sajna a kliens egyenlőre nem találja a szervert - nézegetem az iptables beállítást, ott lesz a hiba - pingelni tudom a szervert, tehát csak a port forwardokkal(?) lehet a baj.

* Én egy indián vagyok. Minden indián hazudik.

grammar nazi on:
Szóltak már, de én is megteszem. Egyelőre != egyenlőre.
Egyelőre: jelenleg, a közeljövőben valameddig, stb. Példa: egyelőre jó ez így, ha megjön az új TV akkor megcsinálom rendesen.
Egyenlőre: ugyanakkorára, azonosra. Példa: a deszkát elvágtam két egyenlőre, és ez lett az akármi két oldala. (Erőltetett, most jobb nem jön.)
grammar nazi off

ON: lassan egy hete szenvedsz (szenvedünk) már ezen a nyüves ovpn konfigoláson. Előtte meg volt pár hét valami ssh tunnel témában is, vagy hasonló.

És én ezt már kezdem k****ra unni. Mármint azt, hogy te kvázi blogolsz a mindenféle problémáidról anélkül, hogy bármi használható konkrétumot írtál volna. Vagy hogy bárhova tenni lehetne azt, amit leírsz, pl. most: "Sajna a kliens egyenlőre nem találja a szervert". Dafuqq?
Mi az, hogy nem találja?
Mi az, hogy pingelni tudod a szervert? (a publikus IP válaszol a pingre, vagy a belső (VPN-es) IP cím?)
A port forward-nak meg aztán végképp nincs köze ehhez, az nagyon más téma (csak hogy a kérdőjeledre válaszoljak).

Szóval nem az a baj, hogy vakon vagy, az a baj, hogy az is vakon van, aki segíteni próbálna. Mert tök homály az, amit írsz.

Van a neten számtalan olyan step by step howto, ami alapján ctrl-c ctrl-v alapon talán még a kutyám is össze tudna lőni egy openvpn-t pár óra alatt, már ha nem temettem volna el már vagy 15 éve.
De ezek általában különböző módon oldanak meg dolgokat, szóval csak magukkal konzisztensek. Nyilván ha értesz hozzá akkor 2-3 howto-t is összegyúrsz, és a manual alapján még meg is fűszerezed, aztán lesz egy remek konfigod.
De ha csak fogalmatlanul kutyulod, akkor csak egy nagy katyvasz lesz belőle.

Szóval ha (tőlem) segítséget szeretnél kapni, akkor írd le hogy mi alapján csináltál valamit (url a howto-ra), mit csináltál konkrétan (config pastebin-re, nyilván a szükséges dolgok kicsillagozásával), stb.
Amíg ez meg nem történik ezt a topic-ot olyan blognak fogom fel amit nem kommentelek.

Jogos.
Megpróbálom vázolni hogy néz ki a kísérleti/teszt felállás.
... internet
...... tovis-lab.port0.org szerver router LAN: 192.168.1.254
.......... LAN: 192.168.1.0 255.255.255.0
...........192.168.1.252 gép gw, dhcp LAN: 172.16.3.252
.............. kliens router LAN: 192.168.2.254
.................. LAN 192.168.2.0 255.255.255.0
.................. 192.168.2.32 teszt gép
A két router openvpn konfigurációja http://pastebin.com/S1tnJud3
+ kliens log (ha elindítom az openvpn -t)

OFF: Mentségeim:
1. Eléggé zűrösek a dolgaim, úgy csipegetek néhány órát erre a kis hobby projectre, és akkor folyton megszakítanak. Néha azt sem tudom, jövök vagy megyek :(
2. Még mindig nem látom át hogy is kellene az openvpn -nek működnie. Tudom, emlékszem többször is leírtátok, de nem látom még át. eresek valami számomra is érthető leírást.
3. Csak addig eljutnom, hogy a konfiguráció beolvasásán túljusson a cucc soronként kellet piszkálnom vi -vel a konfigokat (az ami az eredeti minta konfigban van, uci szintakszisú - úgy kezdődik "option" - majd a mögötte lévő paraméter macskaköröm, aztán azt is megettem hogy az openwrt aláhúzásokat tett a kötőjelek helyett - azért került a lényeg az include -ba mert így az eredeti openvpn leírásokra, szintaxisra lehet támaszkodni).
4. Blog szerű - tökéletes a megfogalmazás :) Részben a HUP amolyan dokumentációként is működik - nekem. Abban a reményben, hogy esetleg lesz valaki akinek a hasznára van.
5. Ami a helyesírásomat illeti, magyarul elfelejtettem (így a helyesírási szótárra kell hagyatkoznom de az "egyenlőre" vagy "egyelőre" szemantikai kérdés), oroszul és angolul sosem tanultam meg.
És most lett kész a vacsi :D
SZERK: Az asszony jót röhögött a bejegyzéseden!

* Én egy indián vagyok. Minden indián hazudik.

elso gond: "Cannot resolve host address: tovis-lab.port0.org" , probald meg eloszor ip-vel a kliens konfigban (nem neztem meg reszletesebben a tobbit)

Azt jo parszor irtad, hogy meg mindig nem latod at, hogyan kellene mukodnie, de nem ertem, mit nem ertesz rajta. Alapvetoen p.csa egyszeru es logikus az elvi oldala, szerintem tulkomplikalod es bonyolultabbnak akarod latni, mint amilyen.

"... tulkomplikalod es bonyolultabbnak akarod latni, mint amilyen."
Jogos :)
Nagyot léptem előre! - kapcsolódik.
A kliens konfigban a remotot macskaköröm közé tettem - anélkül már kapcsolódik is :)
Most már csak azt kellene tudnom, mit és hogyan tudnám kipróbálni?!
A 192.168.2.x "távoli" szegmensből, a jelenlegi beállítások mellett látom a 192.168.1.x "helyi" hálót. A 192.168.1.x "helyi" szegmens viszont nem látja a 192.168.2.x szegmenst, ahol a routeren kívül most csak egy gép van.
Azonfelül van egy warning és egy note ...
WARNING: No server certificate verification method has been enabled.
NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables

* Én egy indián vagyok. Minden indián hazudik.

Igen így már kicsit oszlik a homály. De akkor a kliens oldalon is el kellhet egy ilyen nem? - azaz hogy a 192.168.1.0 tartományt a "runba nyomja".
Bocs de nem tudom mi az az mtr?
Ráadásul, úgy tűnik korai volt az öröm.
A szerver oldal:
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
TLS Error: TLS handshake failed
Re-using ssl/TLS context
...
[ECONNREFUSED]: Connection refused (code=146)
ua 9x
...
SIGUSR1[soft.tls-error] received, client-instance restarting
MULTI: multi_create_instance called
és hízik a log :(
Itt még valami nagyon nem stimmel.

* Én egy indián vagyok. Minden indián hazudik.

Párszor írtam már, hogy a klines oldalon megcsinálja a push route ( de csak a szerver oldalit push-old a kliensnek, önmagát ne, ahogy a pastebin-en van). Ha nem raksz a szerver konfigba push route-ot, akkor kell ott is kézzel.
Viszont ezzel ráérsz azután, ha már megoldod a kulcsok problémáját és csatlakozik, látod mindkét oldalon a tun eszközt.

mtr 'magyarul' traceroute

Megint javult a helyzet. Kivettem a kliens oldalból a "comp-lzo no" opciót. A szerver logjában nem láttam hogy ezt elindítaná, míg a kliens jelzi hogy tömörít.
Megállt a szerver oldali logolás. :)
"Initialization Sequence Completed" :)

Viszont van egy olyanom is, hogy /tmp/openvpn-status.log és az olyan mintha nem lenne kliens:

OpenVPN CLIENT LIST
Updated,Fri Feb 5 23:42:35 2016
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
GLOBAL STATS
Max bcast/mcast queue length,0
END

Vagy csak ennyi kell hogy itt legyen?

* Én egy indián vagyok. Minden indián hazudik.

A comp-lzo legyen mindkét oldalon ugyanaz, vagy yes vagy no. Van még az adaptive opció is, de annak lehet valami kehe ami ennyi sör után pillanatnyilag nem jut eszembe, szóval javaslom mindkét oldalon legyen konzisztensen yes vagy no.

És ez a status.log tényleg úgy néz ki, mint ha nem lenne kliens. Konfigban ez gondolom nincs kikommentezve, és a kliens is kapcsolódva van.

Javaslom ezt a debug-hoz:

option log '/tmp/openvpn.log'
option status '/tmp/openvpn-status.log'
option verb '7'
option mute '5'

A debug levellel már játszottam, de a kliens oldalon. A szerver látszólag tök boldog ...
Másik gyanús momentum, hogy a kliens 2 percenként leáll!?
[UNDEF] Inactivity timeout (--ping-restart), restarting
majd újra indul ...
A szerver konfigban pedig van egy ilyen:

# The keepalive directive causes ping-like
# messages to be sent back and forth over
# the link so that each side knows when
# the other side has gone down.
# Ping every 10 seconds, assume that remote
# peer is down if no ping received during
# a 120 second time period.
keepalive 10 120

Mára? én is befejezem mert kifolyik a szemem ;(

* Én egy indián vagyok. Minden indián hazudik.

Nincs tls kulcsod (ez elsőre nem is baj).
Legyen
option tls_server '0'
és - gondolom -
option tls_client '0'
a kliens oldalon.

Amúgy apróság, de szopatós: az openvpn a saját konfigjában a kötőjeleket szereti, azaz tls-server, tls-client, stb.

Ellenben ha openvpn uci konfiggal csinázod, akkor ott minden kötőjelet aláhúzásra kell cserélni, azaz tls_server, tls_client, stb.

A bővebb megfejtés a /etc/init.d/openvpn tartalma, abban írja át a /var/etc/valamilófasz alá az uci-s konfigot openvpn formátumba.

A push "route 192.168.2.0 255.255.255.0"
az nem kell a server konfigba.
Az a kliens oldal tartománya, ezzel azt mondod meg neki, hogy azt is a vpn server-en keresztül akarja elérni saját magát.

Ide inkább iroute kellene, de olvass inkább utána mert most én nem fogok, és rég csináltam ilyet: https://community.openvpn.net/openvpn/wiki/RoutedLan

Köszönöm, azt a push -t már az első figyelmeztetésre kivettem.
Most már csak a '--script-security 2' -re írja hogy NOTE - de ez gondolom nem lehet akadály. Viszont az openvpn-status.log továbbra is üres :(
A statikus route, ami a "tun -ba tömi" a csomagokat az nem hiszem hogy kellene a kapcsolathoz? - még nem állítottam be.
Mi a rák baja lehet most már nincs hiba é még sem működik!?
A linket megnézem.

* Én egy indián vagyok. Minden indián hazudik.

Alapban a kapcsolathoz nem kellenek a route-ok.

Ezek ahhoz kellenek, hogy a csatlakozó kliensnek megmondjuk, hogy milyen IP tartományokat talál meg a túloldalon. Pl. a szerver belső tartománya 192.168.5.0/24, az openvpn által használt tartomány pedig a 172.16.5.0/24. Itt ha szerver oldalról push-olod neki ezt (uci konfig):
list push 'route 192.168.5.0 255.255.255.0'
Akkor a kliensen létrehoz egy route szabályt, hogy a 192.168.5.0/24 tartományt az openvpn interface-en keresztül próbálja elérni.

Örülök, hogy az asszonynak okoztam pár jó pillanatot :)

Más, pontokban:
- a vi-t nem kedvelem, akkor már inkább nano (tudom, shame on me :)
- nem szükséges az uci szintaxis szerintem, grep -A 20 "for path" /etc/init.d/openvpn
- az openvpn tényleg egyszerű ha egyszer átlátod. Mostanában volt hogy valami rsa tokenes cisco vpn-el küzdöttem úgy, hogy a server oldalra nem láttam rá, de legalább se doksim se igazán használható segítségem nem volt. Nos, az a szopás

A kedvencem az mc szövegszerkesztője (ebben a műfajban) de ide azt nem tudom feltenni. Még azt lehet csinálni, átmásolom, ott szerkesztem majd vissza, de amikor csak egy-egy valamit piszkálsz akkor a vi gyorsabb.
Én egyenlőre letettem az uci szintaxisról - ha jól értem ez inkább a Luci -hoz kell, de ebben a verzióban még nem támogatja az openvpn -t akkor meg minek küzdjek.
30 éves szakmai pályafutásom alatt rengeteg alkalmam volt küzdeni mint villamosmérnök, programozó és informatikus. Sokszor mondtam magamnak, hogy nem érthetek mindenhez, így aztán eljutottam oda hogy nem értek semmihez, kivéve azt a bizonyos sportot :D

* Én egy indián vagyok. Minden indián hazudik.

Esetleg sshfs-el is felcsatolhatod, bár nem tudom openwrt-vel mennyire megy. Én a vi-tól lábrázást kapok, ha lehetőség van rá inkább nano. Amúgy van mc openwrt alá, mcedit nélkül...
(Meg még rengeteg más, ezért is kell nekem extroot.)

Az UCI az openwrt "belső", egységes konfig rendszere. Lehet parancssorból is nyesztetni, a luci (azaz a webui) nem szükséges hozzá, de erre épül.
És van openvpn piszkáló luci modul is, de sallangmentesen kivágja a konfigból a kikommentezett sorokat, szóval csak óvatosan vele.

( tovis v | 2016. 02. 06., szo – 18:16 )

Azt hittem ezen már tulvagyok.
Van lehetőségem egy másik soho -hoz kapcsolódnom.
Kezdeményeztem onnan az ssh kapcsolódást a routeremhez é meglepődtam, mert kapásból visszautasít. Eddig abban a hitben voltam, ha a dropbear -nek nem definiálok interface -t akkor mindegyiken ott van. Hát nem. Sőt még wan -on is, azaz kívülről is lehet csatlakozni - hát nem, kell a portforward?
Belenéztem a logba, és amikor a belső hálóról csatlakozom a külső interfészre akkor is a belső ip címemet kapom, azaz a router visszafogatja a kapcsolatot.
Lehet az egész "teszt" felállás hibás?
Én most ugye a külső címre próbálok kapcsolódni a hálózatom legbelső részéből. A router beforgatja a lan -ról jött kapcsolódási kérést -
mennyire lesz ez ekvivalens?

* Én egy indián vagyok. Minden indián hazudik.

Ezt az egészet nem értem.
Amit felfogtam belőle arra válasz.
- dropbear-nek meg kell adnod, hogy milyen interface-ről engeded a csatlakozást. Szóval a lan-t fel kell venni, port forward imho nem kell
- ha jól emlékszem van valami beállítás, amivel a külső interface-es dolgokat belülről is elérhetővé teszi, de rég volt és tán igaz se
- én vpn-t kintről teszteltem, szerintem bentről nem is megy nekem. Legalábbis sose próbáltam.

A leírások szerint, a dropbear csatlakozhat lan, wan és "undefined". Az utolsó (én így értettem) az amikor minden interfészen figyel.
Most elvileg "undefined" (azaz nincs megadva interfész a konfigban) ennek ellenére úgy működik, mintha csak a lan -on figyelne.
Most, úgy tapasztaltam, hogy nem kell még egy portforward is - valami nem stimmel, ezt is meg kell vizsgálnom.

* Én egy indián vagyok. Minden indián hazudik.

Köszönöm!
Idétlen idők óta használom a netstat parancsot, de rám jellemző módon nem vagyok képes megtanulni az összes kapcsolóját (leggyakrabban az -ie kapcsolókat használom, ifconfig helyett mint user).
Az eredmény: dropbear, uhttpd, dnsmasq és az openvpn mind a 0.0.0.0 címen lóg a beállított portokon. Így elvileg minden interfészen ott lógnak, de mégsem - a wan felé ott áll a tűzfal.
Annyit tudtok súgni, hogy lehet "engedni" egy szolgáltatást a tűzfallal vagy, amit most használok, portforwardot kell csinálni?

* Én egy indián vagyok. Minden indián hazudik.

( tovis v | 2016. 02. 06., szo – 21:25 )

Úgy tűnik, a routolás körül lesz a baj.
Eddig a kliensnek a külső router internetes címét adtam meg "remote tovis-lab.port0.org 1194". Csak próba képpen "remote 192.168.1.254 1194" és voila, a kapcsolat felállt :)
/tmp/openvpn-status.log

OpenVPN CLIENT LIST
Updated,Sat Feb 6 20:55:39 2016
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
client,192.168.1.252:37282,4228,6275,Sat Feb 6 20:54:24 2016
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
10.8.0.6,client,192.168.1.252:37282,Sat Feb 6 20:54:24 2016
GLOBAL STATS
Max bcast/mcast queue length,0
END

A 192.168.2.252 a belső gw gép címe.
Elvileg, az /etc/firewall.user tartalmazza a megfelelő bejegyzéseket, vagy mégsem:

iptables -t nat -A prerouting_wan -p udp --dport 1194 -j ACCEPT
iptables -A input_wan -p udp --dport 1194 -j ACCEPT

iptables -I INPUT -i tun+ -j ACCEPT
iptables -I FORWARD -i tun+ -j ACCEPT
iptables -I OUTPUT -o tun+ -j ACCEPT
iptables -I FORWARD -o tun+ -j ACCEPT

Tény ha kérek egy "#iptables -L" nincs benne se "tun" sem a 1194 -es portra utalás. Lehet ez is az uci szintaxis kellene hogy legyen (úgy kellene kezdődnie, hogy "option")? A /lib/firewall/core.sh amit az init script includol, includolja a firewall.usert. Ezt még ki kell bogarászni :(
Mentek.
SZERK: Még valami. A kliens routeren, ami egy gw gépen át látja a belső hálót, ha fut az openvpn nem tudom pingelni a 192.168.1.251 címet (ami a szerverkém) ha leállítom megint látja.
Minden arra mutat, hogy valami életszerűbb teszt felállást kell csinálnom!

* Én egy indián vagyok. Minden indián hazudik.

Hát itt valami el van b***va rendesen szerintem.

Amúgy belülről próbálod a külső interface-edet elérni, és úgy tesztelsz? Mert az egy romantikus téma.
Bár összehozható (első tippre kell egy prerouting és egy postrouting szabály, dupla nat rulz), de nekem mindig egyszerűbb volt a telón bekapcsolni a wifi hotspot-ot, arra rácsatlakozni notival és úgy tesztelni.

A pingelési probléma oka pedig valamilyen hibás vagy hiányzó push

"Amúgy belülről próbálod a külső interface-edet elérni, és úgy tesztelsz?" Úgy gondoltam, a csatlakozásig ez a felállás biztos jó lesz. De most már jól látszik hogy ez becsapós.
A terv, hogy mobil netet fogok használni, de ez egy másik vesszőfutás lesz (nekem).

* Én egy indián vagyok. Minden indián hazudik.

Hát elvileg ott a másik "telephelyed", onnan szerintem tudsz tesztelni.
Vagy veszel valahol 1 hónapra egy vps-t (digitalocean, stb.), alap install-ra raksz egy ovpn csomagot, feltolod a kliens konfigot és tesztelsz onnan. Jelen árfolyamon kb. 1400 Ft az ára, ennél olcsóbb mobilnetet nem találsz.
(A mobilnet nálam adottság, céges elvárás és a cég is fizeti. Az adatkorlát tizedét se szoktam elérni, így könnyű nekem ilyesmire is használni.)

A másik telephely autóval olyan 30 perc.
Mobil internetem mindig is volt - nálam is sokszor kell és én vagyok a cég :)
A gond az hogy Linuxra az USB mobil netet feltenni azért mindig amolyan kihívás volt (nekem). Lehet megint lesz egy új topik HUAWEI E3372 LTE egy RPI -re (régi adósságom magamnak). Eddig meglepően egyszerű volt, feltettem a 2015.05. Wheezy imaget, feltettem a modeswitchet és a modem-managert, de kapcsolódni még nem sikerült :(
A napló itt látható http://pastebin.com/dRsipvqQ
Valami még hiányzik/hibádzik.

* Én egy indián vagyok. Minden indián hazudik.

A link jó! Köszönöm.
Kicsit tipródom még a Luci, uci történeten. Azért a html server is vizi a memóriát - ez a legszűkebb keresztmetszet. Forog rajta az agyam hogy kicserélem a RAM -ot 32M -> 64M itt látható a cikk vége felé:
https://wiki.openwrt.org/toh/tp-link/tl-wr1043nd
(Az i2c sem lenne haszontalan de most próbálok egy dologra koncentrálni)

* Én egy indián vagyok. Minden indián hazudik.

( tovis v | 2016. 02. 13., szo – 14:31 )

Végre összeraktam egy jobb teszt környezetet. RPI+E3372 gateway - WR1043 - PC.
A két router gond nélkül összekapcsolódott felállt a tun interfész.
Kliens oldali route tábla (végre látom milyennek kéne lennie): 


Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         172.16.3.254    0.0.0.0         UG    0      0        0 eth0.2
10.8.0.1        10.8.0.5        255.255.255.255 UGH   0      0        0 tun0
10.8.0.5        *               255.255.255.255 UH    0      0        0 tun0
172.16.3.0      *               255.255.255.0   U     0      0        0 eth0.2
192.168.1.0     10.8.0.5        255.255.255.0   UG    0      0        0 tun0
192.168.2.0     *               255.255.255.0   U     0      0        0 br-lan

A kliens routerről tudom pingelni a szerver oldali hálózat gépeit, a 192.168.1.x címeken. Viszont a router -re kapcsolt gép nem lát ebből semmit :( Most akkor a kliens oldali gépen kell beállítani egy routot?

A szerver oldal mit sem tud a kliens mögötti hálózatról, még router sem :(
Szerver oldali route tábla: 


Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         catv-80-98-106- 0.0.0.0         UG    0      0        0 eth0.2
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
10.8.0.2        *               255.255.255.255 UH    0      0        0 tun0
80.98.106.0     *               255.255.255.0   U     0      0        0 eth0.2
192.168.1.0     *               255.255.255.0   U     0      0        0 br-lan

Ha jól értelmezem ezt a táblát, akkor a kliens router a 10.8.0.2 című tun interfészen elérhető?
Az openvpn oldalain vannak példa konfigurációk.
https://openvpn.net/index.php/open-source/documentation/howto.html#exam…
Itt a szerver konfigurációban lehet beállítani olyat, hogy "client-config-dir ccd" és ott minden egyes klienshez kell egy fájl ami tartalmaz egy route -ot? nálam valahogy így: iroute 192.168.2.2 255.255.255.0 (a példában 248 a maszk vége - nem tudom mire jó)
Lehet tévedek, de mintha kapcsolatot csak a kliens oldalról lehetne kezdeményezni a szerver oldal felé?
Első lépésben megpróbálom a kliens oldalt rendbe tenni - szeretném ha a kliens oldali PC legalább pingelni tudná a szerver oldali gépeket.

* Én egy indián vagyok. Minden indián hazudik.

Kliens oldal:
Ha jól értem a kliens oldalon az RPI a router és a 'mögötte' lévő gép nem lát semmit. Lehet, hogy az rpi-n nem csináltad meg az openvpn-től független, alap router funkciókat. Lehet csak az ip_forwarding engedélyezése elég, meg nyilván a pc-nek az rpi legyen a def gw-e, más routot a kliens oldali gépen nem kell álltani. A default miatt elmegy az rpi-ig, az rpi a saját táblája alapján tudja, hogy a túloldali tartományt a tunelbe kell nyomni. (ha engedve van neki a forward).

Ha ezek mégis megvannak, akkor csak simán az a baj, hogy odafelé elmegy a ping kérése, csak a szerver oldalon nincs még meg a vissza route és nem talál vissza a válasz hozzá.

"Ha jól értelmezem ezt a táblát, akkor a kliens router a 10.8.0.2 című tun interfészen elérhető?" annak igen, aki tudja, hogy merre keresse (benne van a routing tablajaban, vagy a def gw-e routing tablajaban, és a válasz útja visszafelé is elér hozzá.

Mi a kliens-nek a tun-os IP-je? Kliensen nézd meg ifconfig-gal, azt próbáld pingelni, annak menni kellene. Ha megy, attól még a túloldali LAN-t nem látod, ahhoz kell az iroute.

A CCD-t felejtsd el, ebben a konfigban nem lesz rá szükség. Ez olyankor kell, amikor egyes klienseknek különböző konfigot akarsz letolni.
Nálam pl. a VPS-es gépemnek fix IP-t akarok adni és nem akarok belemászni mélyebben a hálózatába, szóval a neki csinált konfigfile így néz ki: 


ifconfig-push a.b.c.2 255.255.255.0

A "normális" klienseknél pedig nem fontos az IP, viszont akarok DNS-t és default gw-t állítani, szóval az övék ilyen: 


push "dhcp-option DNS d.e.f.g"
push "dhcp-option DOMAIN mylan.mydomain.tld"
push "redirect-gateway"

Na erre kell a CCD, amihez kell egyébként kliensenként külön kliens cert is.

Mivel csak 1 kliensed lesz, ezért a CCD teljesen fölösleges, simán tedd be az iroute-odat a "fő" konfigba.

Elkéstem az olvasással. Az openvpn site https://openvpn.net/index.php/open-source/documentation/howto.html#conf… alapján beraktam a ccd/tovis-lak klienst fájlt:
iroute 192.168.2.0 255.255.255.0

Illetve a szerver konfigba beírtam a következő bejegyzéseket:
client-config-dir ccd
route 192.168.2.0 255.255.255.0

Az ifconfig, egyetlen tun0 interfészt mutat, aminek a címe 10.8.0.1 illetve P-t-P: 10.8.0.2
Ebből csak a 10.8.0.1 címet tudom pingelni a szerver oldali lan -ról.

Van egy olyan bejegyzés a szerver konfigba, hogy "ifconfig-pool-persist /tmp/ipp.txt" ami most a következőket tartalmazza:
client,10.8.0.4
tovis-lak,10.8.0.8
De ezenkívül a /tmp/openvpn-status.log ban van még egy ip cím:

OpenVPN CLIENT LIST
Updated,Sat Feb 13 16:50:36 2016
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
tovis-lak,37.76.56.214:40053,7853,9356,Sat Feb 13 16:39:57 2016
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
10.8.0.10,tovis-lak,37.76.56.214:40053,Sat Feb 13 16:41:33 2016
GLOBAL STATS
Max bcast/mcast queue length,0
END

A szerver mögötti LAN -ról a 10.8.0.10 -et tudom pingelni.

De még a szerver router -ről sem tudom pineglni a kliens címeket :(
A kliens oldali router -ről tudom pingelni a szerver oldali ip címeket, a mögötte lévő gépről nem.
Mondhatnám semmi nem változott :(

* Én egy indián vagyok. Minden indián hazudik.

Még mindig ott toporgok, hogy:
A vpn kapcsolat felállt a kér router között (szerver a UPC közvetlen IP -vel, a kliens gsm közvetett IP -vel).
Kliens oldali router (ami a klienst futtatja) képes a szerver oldali LAN (192.168.1.0) gépeit pingelni, de a kliens oldali lan -ról (gép) nem tudom pingelni a szerver oldali LAN gépeit.
Szerver oldali router (ami szervert futtatja) nem képes pingelni a kliens oldali LAN címeket (192.168.2.0) még a router belső IP -jét sem, nemhogy az ott található gépet.
"A CCD-t felejtsd el" - gondolod hogy bezavar? Inkább megtartanám, a további bővíthetőséghez jobbnak tűnik a ccd opció.
Próbálom összerakni magamban a képet.
Ha jól értem, a szerver oldali push "" utasításokkal a klienst, rá lehet bírni, hogy elvégezzen bizonyos, leginkább route feladatokat?
A szervernek ezeket az utasításokat egyenesbe kellene kiadni?
A kliens oldal áll a legközelebb az elvárt működéshez, jelenleg ilyen a helyzet a routeren: 


Sun Feb 14 11:52:22 CET 2016

br-lan    Link encap:Ethernet  HWaddr 74:EA:3A:C2:79:62  
          inet addr:192.168.2.254  Bcast:192.168.2.255  Mask:255.255.255.0
--
eth0      Link encap:Ethernet  HWaddr 74:EA:3A:C2:79:62  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
--
eth0.1    Link encap:Ethernet  HWaddr 74:EA:3A:C2:79:62  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
--
eth0.2    Link encap:Ethernet  HWaddr 74:EA:3A:C2:79:62  
          inet addr:172.16.3.191  Bcast:172.16.3.255  Mask:255.255.255.0
--
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.8.0.6  P-t-P:10.8.0.5  Mask:255.255.255.255

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         172.16.3.254    0.0.0.0         UG    0      0        0 eth0.2
10.8.0.1        10.8.0.5        255.255.255.255 UGH   0      0        0 tun0
10.8.0.5        *               255.255.255.255 UH    0      0        0 tun0
172.16.3.0      *               255.255.255.0   U     0      0        0 eth0.2
192.168.1.0     10.8.0.5        255.255.255.0   UG    0      0        0 tun0
192.168.2.0     *               255.255.255.0   U     0      0        0 br-lan

Az utolsó sor a szerver oldali "iroute 192.168.2.0 255.255.255.0" -nek köszönhető (ezt le kell ellenőriznem). De ez továbbra sem oldja meg, hogy a kliens oldali gép képes legyen pingelni egy szerver oldali gépeket :(
A 192.168.1.0 sor, elvileg minden a szerver oldali lan felé irányuló forgalmat elküld a tun -ba, de ez a kliens oldali gépnek nem segít :(

MEGJEGYZÉSEK:
Én eddig úgy tudtam, hogy a "Gateway" felé indul az összes, nem a LAN -hoz tartozó ip című csomag - azaz jelen esetben a router felé. A router mégsem továbbítja a vpn felé? Nem értem miért nem ez történik?

Szokatlan számomra, hogy a kliens oldali gép route táblájában a Gateway címe (default) helyett az jelenik meg, hogy "tovis-lak.lan" ha megpingelem, helyesen az általam adott címet pingeli 192.158.2.254. Összehasonlítottam a szerver oldali lanon lévő gépemmel ott csak az IP cím szerepel 192.168.1.254 - ez számomra a megszokott. Mitől lehet ez?

* Én egy indián vagyok. Minden indián hazudik.

( tovis v | 2016. 02. 14., v – 18:14 )

Számos kisebb módosítás/próbálkozás után sem tudok továbblépni :(
A legutolsó konfiguráció itt van: http://pastebin.com/dRsipvqQ
Akármilyen route -okat állítok a zerver oldalon, még a szerver oldali router -ről sem tudok pingelni, semmit a kliens oldalon.
A kliens oldali router -ről tudok pingelni mindent ami a szerver oldalon van.
A kliens oldal bármely gépéről nem tudom pingelni a szerver oldalt.
Létezhet, hogy a router -re telepített openvpn tunnelt a router nem tudja megosztani, illetve a szerver oldal nem "láthat" bele a kliens oldalba?

* Én egy indián vagyok. Minden indián hazudik.

/etc/openvpn/ccd/tovis-lak
push "route 192.168.1.0 255.255.255.0"
iroute 192.168.1.0 255.255.255.0
# redirect-gateway

Ööö.
Itt iroute-tal a kliens LAN tartományát kellene letolnod, azaz a 192.168.2.0/24-et
http://backreference.org/2009/11/15/openvpn-and-iroute/

Illetve tűzfal és hasonlók is okozhatnak problémát

Köszönöm!
Ez csak egy elfuserált próba volt - # client-config-dir ccd - azaz ez nem játszik. Talán épp te mondtad hogy nem kell nekem az a kliensenkénti profil - egyelőre tényleg csak bezavar.
A tűzfal lehet probléma. De nagyon nem tudom, hogy találjam azt meg :(
Az egész történettel az a bajom, hogy keserves hibát keresni benne.
Hogy tudnék rájönni arra hol akad le. A kapcsolat tutira meg van. A kliens oldali router -en tudom pingelni a szerver oldali LAN gépeit, de már a kliens oldali LAN -ról nem. Elakad a router -en, kézzel is próbáltam néhány dolgot, de nem segített - minden a tűzfal/iptables szabályokra utal. Gondolom, amikor a routeren pingelek a csomagok átjutnak de belülről nem jut át, elakad ... mit kéne kinyitni?

* Én egy indián vagyok. Minden indián hazudik.

1 klienses VPN-hez tényleg fölösleges a CCD (én írtam).

Viszont az aktuális pastebin alapján nem találtam iroute szabályt a ccd-n kívül, csak kikommentezve, pedig az kell. (Bár nélküle snat-tal is megoldható a fenti doksi szerint, de azt inkább hagyjuk most.)

ip route show talán mond valami okosat.

A tűzfalra a legegyszerűbb az lenne - nyilván csak teszt környezetben - hogy kikapcsolod a tűzfalat, azaz minden szabályt kivágsz a fenébe és mindenhol accept a policy.
Ha így megy, akkor a tűzfal a baj. Ha nem, akkor más.

++ Amit már rég javasoltam: openvpn loglevel fel az égbe, hátha látunk valamit.
És persze pastebin, vagy valami hasonló.

Még nem tudom mi az "ip route show" de majd megkeresem/elolvasom.
szinte minden az iptables beállítására utal és gondolkodtam, hogy is tudom kikapcsolni/kiiktatni. Ez jó lesz?
http://www.cyberciti.biz/tips/linux-iptables-how-to-flush-all-rules.html
Eddig mindig csak egy-egy apró módosítást csináltam ezeken a szabályokon, ilyen mértékű "rombolást" nem kellett csinálni.
Mi lesz a szerver oldallal - ott muszáj valahogy kiforgatni a 1194 -es portot (ha jól emlékszem)?
A log level mindkét oldalon 7 - talán pont te javasoltad ezt az értéket, ami kicsit moderáltabb mint a 9.
OFF: Most megyek a fogorvoshoz, komoly kínzásnak nézek elébe.

* Én egy indián vagyok. Minden indián hazudik.

Egy-két órát csak kibír?
Szeretem érteni mit is csinálok - legalább amíg csinálom :)
OFF: Bár egyszer, amikor XP -n távoli elérést csináltam és első lépésben még a port számot is megtartottam, viszont beállítottam, hogy a sikertelen azonosítást is naplózza. Percek múlva belenéztem már valaki "brute force" próbálgatott belépni? uer1, user2 ...

* Én egy indián vagyok. Minden indián hazudik.

( tovis v | 2016. 02. 15., h – 11:24 )

Na már megint beblogosodtam! Mit vétettem?
Urak! Szerintetek egyáltalán el lehet ezzel a módszerrel (OpenWrt+OpenVpn) érni azt hogy a két hálózatban lévő gépek lássák egymást?
Kézileg is próbáltam route -kat betenni de nem vezetett célra. Ha pl. a "működő" router kliens mögötti gépről akartam pingelni, vagy elérni a másik (szerver) hálózatot már a kliens leakad a dolog (traceroute).

* Én egy indián vagyok. Minden indián hazudik.

( tbs v | 2016. 02. 15., h – 20:10 )

Tudom, későn szólok, de tinc. :) Több openwrt-t is kötöttem már össze vele, alhálókkal együtt.

Az alhálón lévő gépek látják a szerver oldali gépeket és vissza?
Nem tudom mit higgyek, semmi extra nincs konfigomban, azon kívül hogy egy-egy router -en fut a kliens és a szerver.
(Az hogy a kliens router látja a szerver oldali gépeket arra utal, hogy lehet, de nem az openvpn konfigurációjában kell keresnem a hibát.

* Én egy indián vagyok. Minden indián hazudik.

( tovis v | 2016. 02. 17., sze – 14:09 )

A tűzfal kikapcsolása a kliens routeren nem vezetett eredményre.
A kikapcsolás az OpenWrt roppant egyszerű:
# /etc/init.d/firewall stop
Az eredmény pont ugyanaz mint a feljebb idézett cikkben szépen leírták.
Viszont semmilyen módon nem befolyásolta a kliens oldal működését:
A routerről tudom pingelni a szerver router mögötti LAN -t de a LAN -ról (egy gépről) nem. A route -al kell valamit csinálnom.

A kliens router jelenleg így néz ki: 


br-lan    Link encap:Ethernet  HWaddr 74:EA:3A:C2:79:62  
          inet addr:192.168.2.254  Bcast:192.168.2.255  Mask:255.255.255.0
--
eth0      Link encap:Ethernet  HWaddr 74:EA:3A:C2:79:62  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
--
eth0.1    Link encap:Ethernet  HWaddr 74:EA:3A:C2:79:62  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
--
eth0.2    Link encap:Ethernet  HWaddr 74:EA:3A:C2:79:62  
          inet addr:172.16.3.191  Bcast:172.16.3.255  Mask:255.255.255.0
--
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.8.0.6  P-t-P:10.8.0.5  Mask:255.255.255.255

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         172.16.3.254    0.0.0.0         UG    0      0        0 eth0.2
10.8.0.1        10.8.0.5        255.255.255.255 UGH   0      0        0 tun0
10.8.0.5        *               255.255.255.255 UH    0      0        0 tun0
172.16.3.0      *               255.255.255.0   U     0      0        0 eth0.2
192.168.1.0     10.8.0.5        255.255.255.0   UG    0      0        0 tun0
192.168.2.0     *               255.255.255.0   U     0      0        0 br-lan

traceroute to 192.168.1.251 (192.168.1.251), 30 hops max, 38 byte packets
 1  10.8.0.1 (10.8.0.1)  48.146 ms  28.514 ms  30.911 ms
 2  192.168.1.251 (192.168.1.251)  25.567 ms  27.690 ms  28.752 ms

Vagyis ha a kliens routerről indítom a ping 192.168.1.251 parancsot, akkor működik, de ha egy gépről a 192.168.2.2 címről akkor eltűnik a router belében.
A kliens hálózaton űlő gép, nyilvánvalóan nem látja a tun0 interfész egyik címét sem (10.8.0.1 és 10.8.0.5). A routernek kellene "elintézni" hogy a 192.168.1.0/24 háló felé irányuló csomagokat a tun0 interfészbe küldje.
Itt jönnek azok a dolgok amiket nem értek, látok át:
Miét kell a tun0 szegmensben ennyi virtuális ip cím?
10.8.0.1, 10.8.0.5 és 10.8.0.6
A kliens router route táblájában a 192.168.1.0 tartomány számára a 10.8.0.5 cím van kijelölve mint gateway. Ennek ellenére a belső lan -ról érkező érkező csomagok nem jutnak el oda? A 10.8.0.5 cím nem pingelhető.
A kliens hálózat gépén lévő gép semmit nem tud pingelni a 10.8.0.0 (.1 .5 .6) címtartományból. Nem értem, hogy kéne ennek működnie?

* Én egy indián vagyok. Minden indián hazudik.

( tovis v | 2016. 02. 17., sze – 16:19 )

Blog szerűen :)
Mint már eddig sokszor az derült ki hogy nem olvastam eléggé figyelmesen eleget.
Ezen az oldalon:
https://wiki.openwrt.org/doc/howto/vpn.overview
Egy külön bekezdésben az openvpn -el foglalkoznak, ahol erre hivatkoznak:
https://wiki.openwrt.org/doc/howto/vpn.client.openvpn.tun
Itt szépen (mint a bölcsiben) végigvezetnek a kliens oldal beállításain, tun interfészre vonatkoztatva.
A kliens oldali gép tudja pingelni a szerver oldali gépeket :D
(Ez az uci dolog még mindig zavar)
Amint azt a szakavatottak tudhatták, a tűzfalon kellett állítani, ráadásul mindezt a Luci WEB -es interfészen. Persze én a "nehezebb" módját választottam, vi és szerkesztettem az /etc/config/firewall állományt. Minő meglepetés - nem sikerült.
A WEB -es felületen viszont igen.
Most még meg kell fejtenem a szerver oldali beállításokat - ott még az openvpn configba is bele kellhet nyúlnom - de azért a lényeg a tűzfal szabályokon van.
Utána persze ki kell analizálnom hova is nyúlt és hogy a Luci -s felület - nem mindig tudok Luci -val belenézni a konfigurációba.

* Én egy indián vagyok. Minden indián hazudik.

( tovis v | 2016. 02. 17., sze – 20:42 )

A szerver oldallal nagyobb gondok vannak. Itt a routerről sem tudom pingelni a kliens routert és mögötte lévő hálózatot. 


# kliens oldal
# ifconfig
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.8.0.6  P-t-P:10.8.0.5  Mask:255.255.255.255

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         172.16.3.254    0.0.0.0         UG    0      0        0 eth0.2
10.8.0.1        10.8.0.5        255.255.255.255 UGH   0      0        0 tun0
10.8.0.5        *               255.255.255.255 UH    0      0        0 tun0
172.16.3.0      *               255.255.255.0   U     0      0        0 eth0.2
192.168.1.0     10.8.0.5        255.255.255.0   UG    0      0        0 tun0
192.168.2.0     *               255.255.255.0   U     0      0        0 br-lan


# szerver oldal
# ifconfig
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.8.0.1  P-t-P:10.8.0.2  Mask:255.255.255.255

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         catv-80-98-106- 0.0.0.0         UG    0      0        0 eth0.2
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
10.8.0.2        *               255.255.255.255 UH    0      0        0 tun0
80.98.106.0     *               255.255.255.0   U     0      0        0 eth0.2
192.168.1.0     *               255.255.255.0   U     0      0        0 br-lan
192.168.2.0     10.8.0.2        255.255.255.0   UG    0      0        0 tun0

A szerver oldali tun interfész ip címe a kliens oldal route táblájának 2. ik sorában ott van. A címet mindkét oldalról elérem és pingelni is tudom (jól látszik az időkből - ck. 10x annyi - hogy ez a szerver oldalán él).
Valószínűleg a szerver oldalon meg kellene hogy jelenjen a kliens tun interfészének a címe. Mi kellhet hogy megkapjam?

* Én egy indián vagyok. Minden indián hazudik.

Ahogy korábban írtam: konfig, log, mindenlófasz pastebin-re.
Két route tábla alapján senki se fog okosat mondani. iroute van amúgy?

Amúgy nekem kicsit furcsa, hogy az egyik oldalon 10.8.0.1/2 van, a másikon pedig 10.8.0.5/6. Ez is lehet probléma.

(Most blogolok én is: sose értettem ezeket a /30-as dolgokat, mármint ilyen kategóriában legalábbis. Van 3 privát IP tartomány, mindegyik legalább /16 szóval ne faszkodjunk már ilyesmivel. Topology subnet, adni neki legalább egy /24-et, szerintem legalábbis.)

Openvpn-nél a kliens - szerver között azért ennyi a subnet mask, mert eleve ptp kapcsolat, illetve minden kapcsolatot külön kezel, nem egy 'tartományban' vannak a kliensek, default config szerint nem is érik el egymást, erre külön engedélyező kapcsoló van szerver config-ban emlékeim szerint.

Átnéztem este az enyémet. Szerver mögötti netem nincs most, csak két kliensem a mögöttük lévő hálókkal. A szerver az belát mindkét kliens hálójába pl. ping-gel, illetve a kliensek belső hálóiból átlátnak a gépek a túloldalra. Nálam még bent van a 'client-to-client' kapcsoló bent van a server conf-ban, nem tudom, hogy nálad lenne-e ennek jelentősége.
Korábban a server egy vps-en volt, a vason több vps-sel belső hálón összekötve. A kliensek tartományából elértem a server mögötti lan-ban lévő vps-eket, úgy manageltem őket. Szerintem nem volt már más extra beállítva hozzá.
Ami érdekes és eddig nem tűnt fel, de már tcpdumpltam meg wiresharkoztam tegnap én is, mert egyik irányba használtam eddig, fel sem tűnt, hogy másikba nem megy. A trükk az, hogy ha indítasz egy pinget (pl) egyik oldalról a másikra, a túloldalon kilépő csomagon NAT-olas lesz. A túlsó oldalon a forrás az ottani vpn klines belső ip-je és nem az itteni küldő gép, és az ottani gép arra az ip-re küldi vissza a választ, nem közvetlenül erre az oldalra, csak az ottani kliens fordítja vissza az ip-t és küldi tovább. Nálam azért zavart be, mert az egyik oldalon nem a default gw-en van az openvpn, hanem egy teljesen más gépen, így a vpn belső ip-jét is oda kell route-olnom a belső gépekről, nem csak a távoli tartományokat. Amíg nem tettem, addig a nat-olt című csomagra a választ nem az openvpn-es gépnek küldte, hanem a def gw-nek, ami persze eldobta.

Nem fog megjelenni a kliens P-t-P ip-je közevetlenül a szerver routing táblájában. Nem közvetlenül a tun-ok kapcsolódnak egymáshoz. Több kliens esetén is csak ez az egy tun lesz a szerveren. A 10.8.0.0 default alapján beleküldi a tun-ba, azt az openvpn megcsócsálja és eldönti, hova küldje tovább, melyik kliens felé. A szerveren a 10.8.0.6-ot tudnod kellene pingelni, ha nem megy, akkor valami tűzfal fogja azt is.

A tűzfalat tuti meg kell piszkálni - valami hasonló mint amit a kliensnél kell csinálni (ACCEPT,ACCEPT,ACCEPT).
Egyébként azért a route táblát csaptam ki mert az rövidebb. Illetve jó lenne ha érteném mi is zajlik - a kliensnél mintha derengene :)
OFF: Sajna most megint lesz egy fölösleges kör - mehetek a másik lakásomba mert jön a kéményseprő 12:00 ... 16:00 ott kell sz'pnom :(
Jó dolog ha az embernek van mindenféléje, de ez kötelezettségekkel is jár.

* Én egy indián vagyok. Minden indián hazudik.

A 10.8.0.6 -ot tudom pingelni a szerver routerről, sőt a mögötte lévő hálózatról is.
Viszont, ha beteszem az "iroute 192.168.2.0 255.255.255.0" opciót akkor el sem indul :(
Konfiguráció + napl itt: http://pastebin.com/dRsipvqQ

* Én egy indián vagyok. Minden indián hazudik.

A ccd -t egyelőre parkolóba tettem. Most így néz ki a konfig, de most én is látok egy hibát? - a 192.168.2.0 -s kliens címtartomány így kétszer is szerepel. 


	port 1194
	proto udp
	dev tun
	ca /etc/openvpn/ca.crt
	cert /etc/openvpn/server.crt
	key /etc/openvpn/server.key
	dh /etc/openvpn/dh1024.pem
#	tls-server 0
	server 10.8.0.0 255.255.255.0
	ifconfig-pool-persist /tmp/openvpn-ipp.txt
	push "route 192.168.1.0 255.255.255.0"
	route 192.168.2.0 255.255.255.0
#	route 192.168.2.0 255.255.255.0 net_gateway
	iroute 192.168.2.0 255.255.255.0
#	client-config-dir ccd
#	client-to-client
#	comp-lzo no
	keepalive 10 120
	max-clients 3
#	user nobody
#	group nobody
	persist-key 1
	persist-tun 1
	status /tmp/openvpn-status.log
	log /tmp/openvpn.log
	# 9 is extremely verbose
	verb 7 
	mute 5

* Én egy indián vagyok. Minden indián hazudik.

https://community.openvpn.net/openvpn/wiki/RoutedLans
Ez egy egész jó leírás a ccd és iroute-ról (nekem is tisztult a kép), miért is kell az neked kliensenként és miért nem jó a server conf-ba. Az még nekem sem teljesen világos, hogy a server mögötti lan-nal kell-e valami ilyet csinálni és hogyan.

Mindenesetre most "visszaszerveztem" a ccd -t.
A minta szerint:
https://openvpn.net/index.php/open-source/documentation/howto.html#exam…
ahhoz, hogy szerverről (mögötte lévő hálóról?) látható legyen a kliens, kell egy route meg egy iroute is ugyan oda - nálam a 192.168.2.0 255.255.255.0
Be is épül egy ilyen route, de még a routerről (aki futtatja a szervert) sem lehet pingelni a kliens hálózatot :) 


# a szerver konfig fájl:
	port 1194
	proto udp
	dev tun
	ca /etc/openvpn/ca.crt
	cert /etc/openvpn/server.crt
	key /etc/openvpn/server.key
	dh /etc/openvpn/dh1024.pem
#	tls-server 0
	server 10.8.0.0 255.255.255.0
	ifconfig-pool-persist /tmp/openvpn-ipp.txt
	push "route 192.168.1.0 255.255.255.0"
	client-config-dir ccd
	route 192.168.2.0 255.255.255.0
#	client-to-client
#	comp-lzo no
	keepalive 10 120
	max-clients 3
#	user nobody
#	group nobody
	persist-key 1
	persist-tun 1
	status /tmp/openvpn-status.log
	log /tmp/openvpn.log
	# 9 is extremely verbose
	verb 7 
	mute 5

# ccd -ben az egy darab kliens számára készített konfig

# push "route 192.168.1.0 255.255.255.0"
iroute 192.168.2.0 255.255.255.0
# redirect-gateway

Sajna ez mit sem változtat a helyzeten - a szerver oldalról nem lehet elérni a klienst :(

* Én egy indián vagyok. Minden indián hazudik.

( tovis v | 2016. 02. 19., p – 16:12 )

Megint blog szerűen :) (Utálom amikor a kérdések és a válaszok olvashatatlanokká válnak)
Letöltöttem az "OpenVP 2 Cookbook" -ot (ha jól emlékszem) innen: https://www.ebooks-it.net/ebook/openvpn-2-cookbook
A 49. oldalon egy hasonló hálót ír le mint az enyém. 2 változás van, az egyik a "topology subnet" és a hozzátartozó route, ami náloam most így fest:
route 192.168.2.0 255.255.255.0 10.8.0.1
Az első cím a kliens oldali LAN a második a tun0 címe a szerver oldalon.
Ha a route beállításban nincs a tun0 címe akkor hibát dob az indításnál.
Semmi változás :(
A kliens oldalról jól látszik a szerver oldali lan de a szerver oldalából nem látom a kliens oldalt :(
Mi zavarhat be? A nat - masquerade?
A mostani teszt felállásban, a kliens router egy RPI -re van kötve ami egy HUAWEI E3372 -es sticket használ a kapcsolódásra, ppp -vel. Az RPI -n a ppp0 interfésznek valami 100.x.x.x címe van, ha viszont ssh -n csatlakozom a másik routerhez, a naplóban vlamai 37.76.x.x cím jelenik meg. Az RPI a dnsmasq DHCP szerverét használva biztosít kapcsolatot a kliens router számára - a router természetesen natol/masquerade.
Most akkor a kliens router szemszögéből, ez hányszoros nat?
Működhet így a vpn egyáltalán?

* Én egy indián vagyok. Minden indián hazudik.

( tovis v | 2016. 02. 19., p – 17:24 )

Most csak a próba kedvéért kikapcsoltam a routereken a firewall -t.
Semmi változás leszámítva, hogy kliens oldalon csak a routerről tudtam pingelni a szerver oldali lan -t.

* Én egy indián vagyok. Minden indián hazudik.

( xclusiv v | 2016. 02. 19., p – 19:32 )

Ma volt egy kis időm és összeraktam egy játszós környezetet, sikerült megoldanom a dolgot.

Kliens: szűz openwrt telepítés (chaos calmer x86), aztán
opkg install openvpn-openssl

(Mondanom se kell, hogy pont ekkor dőlt le a download.openwrt.org vagyegy órára)

Ami bekerült:

/etc/config/network
config interface 'VPN'
option proto 'none'
option ifname 'tun0'

/etc/config/firewall
config zone
option input 'ACCEPT'
option forward 'REJECT'
option output 'ACCEPT'
option name 'vpn'
option network 'VPN'
option masq 1

config forwarding
option dest 'lan'
option src 'vpn'
config forwarding
option dest 'vpn'
option src 'lan'

És egy működő kliens konfig, de olyanod már van. (Ha kell publikálom, nem titok.)
A kliens tartománya a default, 192.168.1.0/24 volt. (Ez nálad pont a szerveré.)

Szerver oldal:
A kliens CCD-s konfigjába (1 kliensnél ez szerintem nem fontos, de nálam ide került) 1 sor került:
iroute 192.168.1.0 255.255.255.0
Bekerült a server konfigba egy sor (ezt anno én húzattam ki veled, ezúton is bocsánat):
route '192.168.1.0 255.255.255.0'

Nálad ugye a 192.168.2.0/24 kell ebbe a 2 sorba, mert az a kliens oldali lan tartományod. (Illetve én az openwrt uci-s konfigot használom, szóval nekem list route kellett ide.)

Ezzel már majdnem meg is van oldva a dolog, ugyanis...

és most egy kis blog, ugord át ha nem érdekel. Szóval én notin virtualbox-ba telepítettem egy openwrt-t, és hogy legyen valaki a hálózatában egy turnkey linux core-t is feltelepítettem egy másik VM-be. Internal network-ben összehoztam őket, ez a gép 192.168.1.137 IP-t a virtualizált router-től. Innen elértem a vpnserver router-t, onnan viszont nem értem el ezt a gépet, még a kliens router-t sem ha nem a VPN-es IP címét pingettem.
Aztán véletlenül rossz terminálban kezdtem el pingetni ezt a nyavalyát és legnagyobb meglepetésemre ment. Ugyanis a noti amin az egész miskulancia ment, na az szintén be volt csatlakozva erre az ovpn server-re, itt lett nyilvánvaló hogy a vpn belül már tudja hogy merre kellene menni a csomagoknak.
Abba most ne menjünk bele, hogy hány nat és hurok is volt abban a körben, hogy tkcore VM -> openwrt client VM -> virtualbox NAT -> openvpn server -> openwrt kliens (itt már a host van) -> wifi router. Kicsit volt csak beteg.

... itt a vpn kliensek között már mentek a dolgok, csak a vpn server-nek kellett megmondani, hogy merre is van a vpn kliens tartomány:
route add -net 192.168.1.0 netmask 255.255.255.0 dev tun0
És voila:

root@lofaszjoska:~# ssh 192.168.1.137

Host '192.168.1.137' is not in the trusted hosts file.
(ssh-rsa fingerprint md5 f2:83:53:a2:bb:2c:46:34:8e:05:37:68:4d:f3:33:f5)
Do you want to continue connecting? (y/n) ^C

A következő 1-2 napban szűken leszek, remélem ez alapján sikerül megtákolni, de ha mégse akkor próbálok még segíteni.

Sajnálom hogy ennyi munkád benne van, de nem látok változást.
Mint azt pastebin -ben láthatod a jelenlegi route tábla így néz ki: 


# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         catv-80-98-106- 0.0.0.0         UG    0      0        0 eth0.2
10.8.0.0        *               255.255.255.0   U     0      0        0 tun0
80.98.106.0     *               255.255.255.0   U     0      0        0 eth0.2
192.168.1.0     *               255.255.255.0   U     0      0        0 br-lan
192.168.2.0     10.8.0.1        255.255.255.0   UG    0      0        0 tun0

# route add -net 192.168.2.0 netmask 255.255.255.0 dev tun0
# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         catv-80-98-106- 0.0.0.0         UG    0      0        0 eth0.2
10.8.0.0        *               255.255.255.0   U     0      0        0 tun0
80.98.106.0     *               255.255.255.0   U     0      0        0 eth0.2
192.168.1.0     *               255.255.255.0   U     0      0        0 br-lan
192.168.2.0     *               255.255.255.0   U     0      0        0 tun0
192.168.2.0     10.8.0.1        255.255.255.0   UG    0      0        0 tun0

Sajnos ez sem jött be.
A konfigurációmnak működnie kellene. Már kezdenek összefolyni a szemem előtt de semmi releváns különbséget nem látok az általam átnézett konfigurációkban.
Találtam egy ilyen cikket:
https://theitdepartment.wordpress.com/2009/06/08/openwrt-openvpn-routed…
Itt is utólagos route -kel manipulál.
Már annak is tudnék örülni, ha azt tudnám, hogy a csomag kimegy a szerver oldali routerből vagy sem.
Sajnos a virtualizáció nem a kenyerem, de felpiszkálhatok egy gépen, a router mögött egy openvpn szervert - ha ott is előjön a probléma, akkor bevethetem a csomag figyelő cuccokat, az openwrt -n egyszerűen nem marad hely.

* Én egy indián vagyok. Minden indián hazudik.

Nem 100% teszt, de
Ha a kliens naplózási szintjét feltekerem 9 -re és a szerver oldali routerről pingelek a kliens meg sem nyikkan. Előzőleg, a fordítottját már csináltam és akkor a szerver oldalon láttam ha a kliens oldalról pingelnek.
A csomagok valahol a szerverben tűnnek el. Route vagy tűzfal.

* Én egy indián vagyok. Minden indián hazudik.

Bekerült a server konfigba egy sor (ezt anno én húzattam ki veled, ezúton is bocsánat):
route '192.168.1.0 255.255.255.0'

Ez benne van?

Ráadásul van 2 route szabályod a 192.168.2.0/24-re, ez így nem lesz jó.

Amúgy azért csináltam a tesztet - már leszámítva azt, hogy ritka nyugis nap volt a melóban - mert tudom, hogy anno mindenféle utólagos route-os téma nélkül megoldottam ilyet.

Illetve ami még régről furcsa volt nekem, hogy 2 /30-as tartományt is láttam a logjaidban, 2 és 3 illetve 5 és 6 végű IP-ket.
Elvileg csak az egyiknek kellene lenni ptp kapcsolatnál.

Bekerült a server konfigba egy sor (ezt anno én húzattam ki veled, ezúton is bocsánat):
route '192.168.1.0 255.255.255.0'
Ezen már rég túl vagyunk, próbálkozunk, nem jött be - a kísérletezés ezzel jár, ne törődj vele. Természetesen benne van, az összes általam átnézett konfigban ez benne van.
"Ráadásul van 2 route szabályod a 192.168.2.0/24-re, ez így nem lesz jó."
Persze, hiszen ezt javasoltad, kipróbáltam, nem működik.
Ha belenézel az aktuális konfigurációba akkor ott van, hogy "topology subnet" - így ez nem ptp.
A számos tun -ra utlaó cím 2,3,5 és 6 engem is zavarba ejt, de sajnos a neten fellelhető receptekben, mindenki csak a működő konfigurációt jeleníti meg az eredő route tábla nem :( Ezért is lenne érdekes, hogy néz ki ez ott ahol minden rendben működik,
Amit még nem igazán értek, az ebben a cikkben megjelenített szerver oldali tűzfal beállítás: https://wiki.openwrt.org/inbox/vpn.howto 


# /etc/firewall.user

iptables -t nat -A prerouting_wan -p udp --dport 1194 -j ACCEPT
iptables -A input_wan -p udp --dport 1194 -j ACCEPT

iptables -I INPUT -i tun+ -j ACCEPT
iptables -I FORWARD -i tun+ -j ACCEPT
iptables -I OUTPUT -o tun+ -j ACCEPT
iptables -I FORWARD -o tun+ -j ACCEPT

1. Mi az a "tun+"? - tun0 -m van.
2. Az "#iptables -L" outputjában a 1194 -port nem jelenik meg, de ha kiveszem ezt a beállítást akkor a kliens nem is tud kapcsolódni (gondolom, elsősorban a port forward miatt) - vagyis mégis ott van.
OFF: Így vagy úgy de köszönöm, hogy ennyi időt szánsz rám úgy, hogy a magad részéről már megoldottad ezt a problémát és nem ütköztél ilyen szokatlan "ellenállásba" mint amit az én szitumban van.

* Én egy indián vagyok. Minden indián hazudik.

1. A + wildcard, tun* iface-ként fogd fel
2. valszeg azért, mert nem portszámot ír, hanem "beszédes nevet".
iptables -L | grep -i openvpn
iptables -L -n | grep 1194

OFF: szerintem az a baj, hogy már annyi dolgot kipróbáltál, hogy valahol maradt valami, ami agyonvágja azt amivel próbálkozol. Esetleg az is lehet, hogy nagyon régi (AA) openwrt-vel próbálkozol, én a legújabbal (CC) mindkét oldalon. Lehet hogy ami nálam megy iptables/route tábla nyesztetés nélkül, az a régi még nem.
Próbaként szerintem csináld meg azt, amit én csináltam.
https://wiki.openwrt.org/doc/howto/virtualbox
Aztán opkg update és amit írtam.

Annyiban tértem el a leírástól, hogy nálam az eth0 lett a br-lan-ra "kötve", szóval az 1. hálózati kapcsolat lett az internal network (intnet) a virtualbox-ban, a 2. pedig a nat-os.

"tun+" - sejtettem.
1194 helyett "openvpn" - úgy van ahogy mondod, csak a parancsotz kellett kicsit módosítani "# iptables -L -n" és akkor már ott van a 1194.
Na most meglepődtem. Az utolsó (elkeseredett) kísérletem az volt, hogy átrakom az openvpn -t a 20001 -es portra. Ki is javítottam mindenütt, beleértve az /etc/firewall.user fájlt is. Most hogy belenéztem a szerver oldali állapotba, úgy hogy az openvpn nem fut, mindkét port benne van? ... 


# iptables -L -n | grep 1194
ACCPET  udp  --  0.0.0.0/0  0.0.0.0/0  udp  dpt:1194
# iptables -L -n | grep 20001
ACCEPT  udp  --  0.0.0.0/0  0.0.0.0/0  udp  dpt:20001

Nagyon gyanús. Valamit lehet ki kellene venni a tűzfal szabályok közül - gyanítom a firewall.user bejegyzés felesleges, ha amúgy a fő /etc/config/firewall -ba uci módban már ott vannak a szabályok.

Valóban nem a legfrissebb csomagokat használom - az elején erről már volt szó:
1. A 15.x OpenWrt túl sok memóriát zabál - a 32M -ból olyan 6M marad és tapasztaltam olyat, hogy azért áll le nincs elég RAM :(
(Ezért van az a kósza gondolat, hogy kibővítem 32 -> 64M -ra, de ez nem egyszerű - kell egy forró levegős páka)
2. A 15.x OpenWrt -ben azt látom fő különbségnek, hogy kezeli az IPv6 -ot (és szerintem erre megy a memória), nem lehet tőle megszabadulni :(
(A 12.09 openwrt -ben is már ott az IPv6 támogatás, de nem zavar sok vizet)
3. Az OpneWrt 2.2 verziója nem lehet annyira rossz.
Tény, hogy a különféle howto -k különféle verziókhoz íródtak, így ez is bezavar a történetbe. De az általam "hajtott" site-to-site konfigurációt már akkor is tudtak összerakni, elvileg nekem is mennie kell.
Még azt fontolgatom, hogy a szerver oldalt a kis soho szerveremen kellene megoldanom - viszont az sem egy egyszerű játék. A házi szerveremen Squeeze van és nem mostanra terveztem frissíteni, márpedig ez a probléma ott is előjöhet.

OFF: Az újabb WR1043 -ok már 64M RAM -ot tartalmaznak, viszont, a legújabb regula szerint nem piszkálhatod a szoftverét :(

* Én egy indián vagyok. Minden indián hazudik.

1-2. Azért van a memória, hogy használja. Nálam is 1043nd van, igaz 8 mega swap-et még tettem mellé. Bár nálam tele van aggatva rendesen, apcupsd is eszi a memóriát, az openvpn is. De ha nem swap-elnék akkor inkább azt nézném meg, hogy mi az amit ki lehet kapcsolni. Pl. luci (uhttpd) kell-e, ilyesmi. Én nem kockáztatnék régi, nem támogatott, lyukas rendszerrel gateway-en.
3. Nem állítom, hogy a verzióval van probléma, viszont fordíthatsz is új openvpn-t ha arra van gusztusod. PC-n szerintem nem lehet nagy feladat. Vagy akár futtathatod virtualizálva is, akár az egész gateway témát "kiszervezve" a router alól (akár openwrt x86), és akkor a 1043ND lesz egy sima switch +wifi AP.

A Luci kikapcsolása jó ötletnek tűnik. Avval együtt nagyon zavar az IPv6 ami nekem nem kell és közeljövőben nem hiszem hogy kellene.
Hogy lyukas? - ezt így nem hinném bár nem kizárható. Viszont, ha úgy vesszük lehet az újabb lyukas - azért a Linux történetében volt ilyen. Inkább arról lehet beszélni, ha kiderül egy új lyuk akkor az újat javítják, a régivel nem fog foglalkozni senki.
Még egy kicsit küzdök ezzel a verzióval.
Épp most nézem, Luci -n keresztül, hogy valami nem stimmel a vpn - tun beállításnál, az interfészeknél - "Static address" de nincs címe?
Egyébként, az RPI gateway -ra feltettem egy tcpdump -ot, a szerver felől küldött a ping csomagokat nem látom, a kliens felőliek jönnek, mennek. (No meg az ntp, a keep alive? -stb.)

* Én egy indián vagyok. Minden indián hazudik.

( tovis v | 2016. 02. 21., v – 17:58 )

Még egy hibalehetőséget nem vizsgáltam.
A kliens router és a net között van egy Raspberry PI, ami egy HUAWEI E3372 LTE -n keresztül kapcsolódik. A gateway beállítás, a ppp0 -ra kapcsolódó stick kommunikációhoz itt van: http://pastebin.com/UkBwpA72
Azon gondolkodom, nem ez blokkolja valahogy meg a történetet?
A szerver irányába minden OK -nak tűnik, a kliens irányába van a hiba.

* Én egy indián vagyok. Minden indián hazudik.

( tovis v | 2016. 02. 21., v – 19:32 )

RPI kiejtve - ha lekapcsolom a firewallt akkor sem működik a ping a kliens irányába.

* Én egy indián vagyok. Minden indián hazudik.

( tovis v | 2016. 02. 21., v – 22:03 )

Mint kicsit feljebb írtam, a Luci azt mutatta, a tun static ip címe hiányzott - beállítottam (10.8.0.1)
Most valami változott! - a 10.8.0.6 ami a kliens tun címe pingelhető.
A mögötte lévő hálózat még nem pingelhető :(
Már annyi mindent kipróbáltam, hogy nem vagyok biztos a dolgomban de mintha eddig ez sem ment volna.
A klines még mindig jól működik - tudom a szerver mögötti lan -t pingelni :)

* Én egy indián vagyok. Minden indián hazudik.

( tovis v | 2016. 02. 22., h – 13:05 )

A probléma továbbra is áll:
A kliens jól látja a szervert, de a szerver nem látja a klienst.
Annyi javulás történt, hogy látom a kliens oldali tun interfészt a 10.8.0.6 címet, tudom pingelni de a hostokat nem (kliens oldali router lan felőli oldala és más gép 192.168.2.0 255.255.255.0 háló)
Az aktuális konfiguráció, illetve az eredő iptables szabályok itt: http://pastebin.com/3VRAadXz
Valami még hiányzik, abban sem vagyok biztos, hogy csak a tűzfal konfigurációjából.
Ha valaki lát benne valami kiegészíteni valót kérem szóljon.

A Luci -n keresztül elkezdtem piszkálni a konfigurációt rögtön elértem, hogy a kliens oldalt megint ne tudjam pingelni. Gyorsan visszatettem, a mentett konfigurációt - megint kezdhetem megtanulni az iptables -t.

* Én egy indián vagyok. Minden indián hazudik.

( tovis v | 2016. 02. 23., k – 11:20 )

Végül ötlet híjján, írtam az OpenWrt levelező listájára.
Természetesen megkaptam hogy a régi verzió nem támogatott.
Kaptam egy egyszerű módszert, amivel kikapcsolhatom az IPv6 -ot, íme:

uci del network.globals.ula_prefix
uci commit network
/etc/init.d/odhcpd disable
reboot

(hátha másnak is jól jön)
A kliens oldal láthatatlanságára ezt javasolta:

That is because there is no route to the clients LAN via the clients VPN IP 10.8.0.6. Take a look at
https://community.openvpn.net/openvpn/wiki/RoutedLans.

De ez tetszik a legjobban (nem szarkazmus, tényleg először látom ezt):

I know that people love to blame firewalls for any network problem but
in general you can roughly categorize the problem like that:

If you get no ping result at all or if you get "Destination network
unreachable" then you have a routing problem.

If you get "destination port unreachable" then your traffic is firewalled.

Már csak az a baj, hogy a mostani beállításokkal egyiket sem kapom, Ctrl+C -vel megszakítom, mire kapok egy üzenetet, hogy elküldött x csomagot, vett 0 csomagot. Na ilyenkor mi van?
Összességében, a levél jó ötlet volt, kaptam még egy löketet ami tovább lendíthet :)
SZERKESZTVE
Megint kaptam egy választ :)

> What if I do not have any of these? - I could only break the command using
> Ctrl+C and I have a message that it was send x packages and receive 0
> packages :(

That qualifies as "no result at all".

Hát ettől nem lettem okosabb :(

* Én egy indián vagyok. Minden indián hazudik.

A baj csak az hogy nem változott semmi :(
Feltekertem a verbosity -t 9-re, mindkét oldalon.
Ha a szerver oldali lan -ból pingelem a 10.8.0.6 címet a kliens oldal szépen zörög, megy a ping.
Ha a szerver oldali lan -ból pingelem a kliens oldali 192.168.2.2 címet a kliens oldal meg sem nyikkan, a szerver oldal nem jelez hibát, csak ilyen homályos üzenetek vannak hogy az UDPv4 írás valami értéket dobott.
Az iroute beállításnak megfelelően a 192.168.2.0 -ás net a 10.8.0.2 címre és a tun0 -ra megy de nem megy át a szerveren :(
Teljesen fegyvertelen vagyok, hova tűnnek el a csomagok.

* Én egy indián vagyok. Minden indián hazudik.

Ha a szerver oldali lan -ból pingelem a 10.8.0.6 címet a kliens oldal szépen zörög

Az iroute beállításnak megfelelően a 192.168.2.0 -ás net a 10.8.0.2 címre

Most akkor a kliens az 6 vagy 2?
Ez már régebben is feltűnt valamelyik valamiben, hogy van egyszer egy 10.8.0.1/2 és 10.8.0.5/6, ami elvileg két külön /30 tartomány lenne, de azóta - ha jól emlékszem - már subnet-ezel.

A "topology subnet" -et egyelőre kivettem - nem változtatott semmin :(
Így az iroute csak a kliens lan ip és mask adatot tartalmazza.
A kliens tun0 címe, a mostani beállítások szerint, 10.8.0.6
A szerver tun0 címe 10.8.0.1
A szerver route táblájába az áll hogy
192.168.2.0 10.8.0.2 255.255.255.0 ... tun0

* Én egy indián vagyok. Minden indián hazudik.

1. Ha az egyik IP .1 a másik pedig .6, akkor asszem továbbra is subnet a topology és nem net30.
2. Bár a net30 lenne a default. Ebben az esetben egy /30-as tartományban tudsz operálni, tehát a lehetséges IP párosok ezek:
- 10.8.0.1 és 10.8.0.2
- 10.8.0.5 és 10.8.0.6
stb.
3. Szóval itt valami kavarás van
4. A route sorod viszont egyértelműen rossz! Mert a 10.8.0.2 "gw" felé küldenéd a kliens tartomány felé menő forgalmat, márpedig a kliens IP-je 10.8.0.6, szóval persze hogy nem megy.
Szóval töröld ki ezt a szabályt és add ki azt, amit én használtam:
route add -net 192.168.2.0 netmask 255.255.255.0 dev tun0
Vagyis ne adj meg gw-t, csak interface-t.

Így is, úgy is megpróbáltam.
Viszont kaptam egy másik tippet (most az openvpn levelezőlistáról) nem látszik (a szerver naplóban), hogy beolvasná a ccd könyvtár alatti "tovis-lak" fájlt, ami az iroute szabályt tartalmazza.
A PUSH üzeneteket látom, de ezt nem találom én sem.

* Én egy indián vagyok. Minden indián hazudik.

Már az nagy segítség szokott lenni, ha tcpdumpal megnézed, hol és meddig jut el a ping.
pl.:
1. szerverről indítasz egy pinget
2. közben nézed a szerveren: tcpdump -i tun0 icmp
3. ha az előző jó, mész a kliens tun-ra: tcpdump -i tun0 icmp
4. ha az előző jó, mész a kliens eth-ra: tcpdump -i eth0 icmp vagy tcpdump -i br-lan icmp
5. ha az előző jó, mész a kliens mögött gép megfelelő interfészére.

--------------------
http://grant-it.com/

( tovis v | 2016. 02. 24., sze – 15:21 )

"Remarkba" tettem a "client-config-dir ccd" bejegyzést, majd vissza.
1. A route táblában nem látok különbséget.
2. A naplófájlban nem látom hogy olvasná a kliens fájlt

Megjegyzés: A szerveren fut a cplay amivel épp most rádiócsatornákat hallgatok. Minden alkalommal, ha elindítom a szerver oldalon az openvpn -t "ugrik" egyet a listában.

* Én egy indián vagyok. Minden indián hazudik.

Szerintem igen. A szerver naplófájl idevágó része: 


us=617265 37.76.65.105:39381 VERIFY OK: depth=1, /C=HU/ST=BP/L=Budapest/O=tovis-lab/OU=changeme/CN=tovis-lab.some_dns.org/name=tovis/emailAddress=tovises@freemail.hu
us=620574 37.76.65.105:39381 VERIFY OK: depth=0, /C=HU/ST=Budapest/L=Budapest/O=tovis-lak/OU=houskeeping/CN=tovis-lak/name=tovis/emailAddress=tovises@freemail.hu

Viszont megint kaptam egy hasznos választ. A szerver naplóban valami ilyesmit kellene látnom: 


us=208238 home-router/xx.xx.xx.xx:51087 OPTIONS IMPORT: reading client specific options from: ccd/home-router

Én bizony nem találok ilyet. Pedig, elvileg ott van.

* Én egy indián vagyok. Minden indián hazudik.

De sajnos nem látom. Már az is megpróbáltam hogy bemásolom az /etc/config/ könyvtárba is, de ez sem használt :(
Azt is kipróbáltam, hogy bemásolom a "tovis-lak" fájlt egy "DEFAULT" nevű fájlba (a 2.2.x openvpn manualja alapján) de nem segített.
Betettem a szerver konfigurációba az "iroute" utasítást "csak úgy" akkor hibával kilép az openvpn.
Miért nem olvassa be ezt a nyavajás fájlt?
Egyébként, a szerver konfigurációjában volt egy fölösleges route utasítás a 192.168.2.0 -s netre, ami a "topology subnet" -hez kellett - töröltem. Így alapból akár kapcsolódik a kliens kár nem nincs route a 192.168.2.0 -ra. Próbáltam megint kézzel bevinni az általad javasoltat és még más verziókat is de nem segített.

* Én egy indián vagyok. Minden indián hazudik.

Na most megvan.
[code]
us=886691 37.76.65.105:60361 [tovis-lak] Peer Connection Initiated with 37.76.65.105:60361
us=887110 tovis-lak/37.76.65.105:60361 OPTIONS IMPORT: reading client specific options from: /etc/openvpn/ccd/tovis-lak
[code]
Mint az látszik a naplóból végül a szerver konfigurációba megadtam a teljes path -t. Így már olvassa, de nem csinál semmit.
A kliens fájl, semmi mást nem tartalmaz, mint
iroute 192.168.2.0 255.255.255.0
De a route táblában nem jelenik meg semmi a 192.168.2.0 -netre.
Most meg mi van?
SZERKESZTVE:
Na most már működik, ha hozzáadom, hogy
route add -net 192.168.2.0 netmask 255.255.255.0 dev tun0

Most csak azt kellene kitalálnom, hogy tudom ezt a route -ot automatikusan beépíteni ha kliens kapcsolódik.

* Én egy indián vagyok. Minden indián hazudik.

Mindkettőtöknek köszönöm a segítséget!
Utólag visszagondolva, szinte már az első konfigurációm működhetett volna, ha jobban odafigyelek.
Az iptables beállításához kell az a zóna definíció (nem csak a 1194 -es portot kell "kinyitni").
A szerver konfigurációban minden path abszolút!

* Én egy indián vagyok. Minden indián hazudik.