Dotaz: propojení dvou sítí pomocí VPN

[Tom13]

Zdravím, již několik dní se peru s problémem propojení dvou LAN sítí přes internet pomocí openVPN, než se ale zeptám úplně konkrétně, rád bych věděl, jestli se vůbec ubírám správným směrem.

Mám dvé domácí sítě, jedna má veřejnou IP adresu, co se nemění, tak mě napadlo, že si je propojím přes openVPN - před několika lety jsem ho využíval na připojení z domova do práce, po připojení jsem si spustil VNC a v podstatě pracoval z domova, ale to probíhalo na Windows a bylo to pouze propojení server - klient. Nyní bych rád ty své domácí sítě propojil tak, aby to vypadalo jako jedna síť. Koupil jsem si tedy 2x Raspberry Pi 3 a začal - v sítích se až tolik nevyznám a v Linuxu už vůbec ne, ale podařilo se mi dopracovat až do fáze, kdy mám částečně funkční openVPN tunel. Částečně proto, že se tunel vytvoří, ale daří se mi ping pouze z klienta na server - to ale zatím není co mě zajímá.

Našel jsem si, že openVPN může pracovat buď jako routovaný tunel tun, nebo jako bridgovaný tap - routovaný podle všeho potřebuje dvě různé sítě, ale má menší zatížení provozem, bridgovaný naopak pracuje s jedním rozsahem IP adres, ale díky tomu je více vytížený - pokud jsem to pochopil správně.

To co mě zajímá je, který tunel by byl v mém případě lepší, když bych chtěl, aby se obě sítě po propojení chovaly jako jedna - abych poté z Windows v okolní síti viděl všechny zařízení z obou sítí.

A teď k těm sítím

první: modem poskytovatele s veřejnou IP -> můj router -> domácí síť - v ní by byl i umístěný první Raspberry jako VPN server

druhá: modem poskytovatele s veřejnou IP -> můj router -> domácí síť - v ní by byl i umístěný druhý Raspberry jako VPN klient

Obě sítě mám teď na IP 10.11.12.0 255.255.255.0 - první síť cca 6 zařízení, druhá cca 8 zařízení, něco s pevnou IP a něco přes DHCP - není problém ale podle potřeby změnit IP sítě - při routování jsem chtěl použít u druhé sítě IP 10.20.30.0 255.255.255.0

Abych to lépe otestoval, protože sítě samozřejmě nejsou u sebe, vzal jsem si dva routery, ty na WAN propojil, na jednom dal tu veřejnou IP na kterou bych se připojoval reálně a u toho druhého IP o jednu vyšší, vnitřní rozsahy jsou oněch 10.11.12.0 a tam je VPN server, druhá má těch 10.20.30.0 a je v ní klient - ping na WAN mi jde z obou podsítí, routovaný tunel se mi vytvoří, ale ping projde pouze směr klient -> server, opačně nikoli a nevím proč, do tunelu mi ping projde jen na určité adresy tunelu - ale jak jsem psal, jedná se o routovaný tunel a teď nevím, jestli by mi vyhovoval. Bridgovaný jsem zkoušel také, ale tam mi ping neprošel nikam i když se tunel vytvořil. V této chvíli mě ale hlavně zajímá, kterým tunelem se mám zabývat, aby mi to fungovalo tak, jak jsem popsal výše - všechno bude dostupné a viditelné všude.

---

---

Odpovědi

[Matlák]

Jak mnozí píší třeba tady (nejsi ten stejný Tom?) tak jde čistě o problém směrování. Pokud se chceš "dopingat" z jedné sítě do druhé, směrovací tabulky v zůčastněných strojích musí vědět že packety určené do té druhé sítě musí jít přes tu mašinu s openvpn. To jestli je ta mašina klient nebo server není až tak důležité, důležité je aby směrování fungovalo v obou směrech.

Sítě se takto dají spojovat celkem pohodlně. Důležité je jen vědět kde která zařízení jsou (aby se dalo jednoznačně říct že cesta z A do B je přes VPN a cesta z B do A taktéž, ovšem třeba A do C jde přes internet mimo openvpn). A je jedno kde se to směrování nastaví. Může to být na "endpointech" - koncových PC kde se jednotlivé adresy nastaví jako pevné routy přes ten openvpn stroj, nebo (asi pohodlnější) na openvpn strojích a "endpointy" potom budou mít tyto openvpn stroje nastavené jako výchozí brány sítě..

[Tom13]

Nejsem stejný Tom - i když možná řešíme stejný problém :) - tu diskuzi jsem si prošel ale moc jsem z toho nezmoudřel.

Z toho co píšeš mi přijde pro mě jednodušší, aby jsem měl ten tunel bridgovaný, protože ten by sám o sobě měl fungovat všesměrově - vše jde všude - takže asi odpadá problém s routováním, navíc je vše i na jednom IP rozhraní, ale zase si to vybírá daň v tom větším zatížení tunelu - snad to chápu správně :)

Samozřejmě u toho routování jsem i zkoušel přidat na router s bránou statickou routu do té druhé sítě - v té 10.11.12.0 to bylo cíl: 10.20.30.0 maska 255.255.255.0 brána 10.11.12.111 (VPN server) - v té druhé naopak, ale moc mi to nepomohlo, protože ten tunel nefungoval nějak uvnitř - třeba při výpisu routovací tabulky jsem měl cestu na IP tunelu, ale na to IP mi nešel ping, naopak mi prošel na adresu, která ani v té tabulce nebyla - nevím, původně jsem myslel, že se to propojení konců tunelu vytvoří samo a ping na eth rozhraní server - klient a opačně bude bez problémů, fungovalo mi jen ve směru klient - server, to další, jako ping někam dál za server jsem neřešil, když mě nefungoval ten základ, zkusil jsem ho, ale nešlo.

Teď zkouším vytvořit bridgovaný tunel, myslel jsem si, že to bude jednoduché, že se i ty vnitřní adresy tunelu nastaví na adresy 10.11.12.0 a tím se to vyřeší, ale není to tak, vnitřek tunelu má zase úplně jiné IP - blbnu s tím už skoro týden a už moc nevím co s tím, co kde dělám špatně, jak jsem psal, v linuxu se nevyznám, možná by to chtělo jen někde přidat pravidlo pro firewall - i když to dělám, zkoušel jsem postupovat podle návodů a stejně nic, tak už vážně moc nevím.

Možná je to nějaká blbost v nastavení openVPN, možná pravidlo pro firewall v linuxu, v každém případě tunel se mi vytváří, ale vázne mi v něm ta komunikace.

[Matlák]

vše jde všude - takže asi odpadá problém s routováním

Tomuhle se teda raději vyhýbám. Jak myslíš že by se v té síti ty mašiny domlouvaly? Kam by ty pakety lítaly, snad ne ven? Prostě něco musí říct tomu směrovači v síti A že ten stroj který je v síti B je přístupný přes VPN bránu AG.

Dávám přednost tomu že sítě normálně načísluju tak aby každá měla jiný rozsah a bylo jasné co je v síti A a co je v B a pak není nic triviálnějšího než říct (zamaskovat) které adresy mají jít na bránu do internetu a které na bránu do VPN, případně jinam (lokální stroje).

Doufám že přispěchá někdo fundovanější, každopádně za mě je "všesměrové" routování návrhový nesmysl - prostě nějaká maska jde do podsítě A nějaká do podsítě B, "lepit" k sobě dvě sítě tak že se jim nastaví stejné masky vede do pekel - v každé síti je jiný směrovač, jiný DHCP server... možná leda zkrz VPN propojit obě sítě do jedné společné, s jedním DHCP který by pak nařídil těm strojům přes kterou bránu mají chodit ven, ale jak by to ten DHCP server poznal (kde jsou výstupní brány do internetu v těch sítích) když podle rozsahu nepozná ve které síti ten který stroj je?

[Tom13]

Asi jsem to napsal špatně - nejde o všesměrové routování (jestli to vůbec existuje), ale o tu konfiguraci openVPN jako bridge. To by mělo právě umět to, že se to pak chová jako jedna síť na jednom rozsahu, proto je to náročnější a víc to zatěžuje tunel, protože jím jde veškerý provoz z obou sítí.

Jsou tam pak dvě možnosti - jak jsi psal, buď se používá DHCP z jedné části (většinou asi z té kde je VPN server), nebo se dá určitý rozsah adres na VPN server a ten je pak přiděluje klientům z té připojené sítě přes VPN klienta - samozřejmě musí být mimo DHCP.

Co jsem našel asi by šla i třetí možnost, protože by mělo jít snad i nastavit, aby VPN tunel nepouštěl DHCP pakety, takže by teoreticky šlo mít dva DHCP servery samozřejmě každý s jinou částí rozsahu IP sítě - tím by se vlastně vyřešila i ta brána, protože pak by každá část sítě mohla mít z DHCP přidělenou jinou bránu ven.

Ten tunel je pak asi i o rychlosti a teď nevím, jak by to bylo - například, pokud bych používal jednu bránu na straně serveru a chtěl se připojit na internet z druhé části od klienta, jakou rychlostí by to připojení bylo? Bude to stejné, jako když se připojím rovnou z druhé části na internet, protože ten tunel by měl mít příchozí rychlost stejnou, nebo se to zpomalí na rychlost jakou má upload toho připojení, protože v tunelu probíhá obousměrná komunikace, takže se to zpomalí právě na tuhle rychlost? Snad jsem to napsal srozumitelně :)

[Matlák]

Na bridging jsem koukal - zní to jako ideální způsob propojení dvou sítí - ale dávám přednost očíslování sítí. Asi proto aby člověk věděl, kde se "fyzicky" zrovna nachází stroj s nějakou adresou.

například, pokud bych používal jednu bránu na straně serveru a chtěl se připojit na internet z druhé části od klienta, jakou rychlostí by to připojení bylo?

Limit tvého stahování (download) by byl určený mimo jiné i limitem klientova uploadu. Což by nemusel být takový problém, záleží na tom jaké má klient připojení.

[Tom13]

Ano, to bridgování se mi líbí víc - jak jsem psal, mám tam dohromady 2x notebook (každý v jedné síti), 3x chytrá TV (2x jedna síť, 1x druhá), 2x tiskárna na print serveru - každá v jedné síti, 1x PC v jedné síti, 2x WiFi každé v jedné síti, 1x multimediální centrum v jedné síti, a pak hlavně mobily, ty jsou podle situace :) Takže bych ten bridge klidně udělal, provoz je minimální, ve větší síti bych asi spíš použil to routování, už jen proto, že by třeba stačila komunikace mezi servery, nebo jen routování serverů, aby byly vidět v obou sítích...

S tou rychlostí jsem si to tak myslel - takže pokud je to připojení třeba 10/3, půjde tunel maximálně 3.

[Matlák]

Jen abych to shrnul - nastavil bych DHCP servery v těch dvou sítích tak, aby přidělovaly adresy do oddělených rozsahů a pak bych přidal do každé z těch sítí routovací pravidla pro ten druhý rozsah do VPN. Rozsahů v IPv4 (ať už /24 nebo dokonce /16) je na to dost. Pokud je požadavek na některé "výjimky" pro pevné adresy bez možnosti přestěhování, tak ty bych do routování zadal "natvrdo".

Tohle bude fungovat aniž by bylo nutné ručně nastavovat routování v každé mašině zvlášť a nebo nějakým způsobem replikovat celý provoz vnitřní sítě na obou stranách tunelu. A jako bonus člověk při přehrabování se v provozu hned uvidí, které packety šly do které sítě a kde bude případný problém.

Jak říkám, nejsem povoláním síťař a možná to jde i jinak, ale logicky se mi to zdá správné a přitom jednoduché. A takhle to taky kolem mě prakticky funguje. Možná ale někdo z místních bude o tomhle tušit víc.

[Tom13]

Zatím ale není co nastavovat, protože můj hlavní problém je openVPN - když zkusím bridgovaný přes tap0, tunel se vytvoří, vznikne tap0 na obou stranách, přidělí se IP, ale na některé IP tunelu mi ping jde a na některé ne a ping mi tunelem neprojde ani z jedné strany.

Když vytvořím routovaný tunel pomocí tun, tak opět - tunel se vytvoří, tun0 vznikne a má IP, ale opět ping na IP tunelu jde jen někam a projde mi pouze ping na IP client - server. Až rozběhnu tunel, abych mi prošel ping z obou stran na rozhraní eth0 druhého stroje na konci tunelu, budu řešit, co dál. Ale nějak netuším, co s tím - třeba mi to ráno fungovalo následovně:

první síť (server) IP 10.11.12.111 tun0 10.8.0.2

druhá síť (klient) IP 10.20.30.111 tun0 10.8.0.14

ping z 10.20.30.111 na 10.11.12.111 OK

ping z 10.11.12.111 na 10.20.30.111 NE ale ping vypisuje že skočil na IP 10.8.0.15

ping z 10.20.30.111 na 10.8.0.2 NE

ping z 10.20.30.111 na 10.8.0.14 OK

ping z 10.11.12.111 na 10.8.0.2 OK

ping z 10.11.12.111 na 10.8.0.14 NE ale ping vypisuje že skočil na IP 10.8.0.1

ping z 10.11.12.111 na 10.8.0.15 NE

ping z 10.11.12.111 na 10.8.0.1 OK

ping z 10.20.30.111 na 10.8.0.1 OK

ping z 10.20.30.111 na 10.8.0.15 OK

Routovací tabulky nemám, ale kdyby chtěl někdo pomoct, klidně to zprovozním zase routovaný tunel a dám to sem - a s tímhle prostě dál nehnu.

[Matlák]

"Routovaný" tunel můžeš mít i s tap rozhraním. Možná sem hoď link na návod/návody kterým ses řídil.

druhá síť (klient) IP 10.20.30.111 tun0 10.8.0.14

vs ping z 10.11.12.111 na 10.20.30.111 NE ale ping vypisuje že skočil na IP 10.8.0.15

Není na tomhle něco divného? Každopádně, asi bych zkontroloval jestli jsou přítomná pravidla (v síti A) 10.20.30.0/24 via 10.8.0.14 a (v síti B) 10.11.12.0/24 via 10.8.0.2 (tedy, pokud jsou adresy z rozsahu 10.8.0.0/24 přímo adresy VPN uzlů) na těch vpn stanicích, a (v případě že vpn stanice nejsou výchozími bránami) pravidla na bránách (směrovačích) (v síti A) 10.20.30.0/24 via 10.11.12.111 a (v síti B) 10.11.12.0/24 via 10.20.30.111.. ale jak říkám za tak moc do toho nevidím..

[Tom13]

Divné to právě je - ten tunel používá celkem 4 IP adresy a já nevím jestli není potřeba ještě někde něco povolit v systému nebo tak - s Linuxem jsem nikdy nedělal - aby to mezi sebou fungovalo...

[Matlák]

s Linuxem jsem nikdy nedělal

tak sem hoď linky kterými ses řídil - třeba to pomůže někomu dalšímu. Nějak se mi nechce věřit, že ses dostal tak daleko bez návodu a bez znalostí potřebných k základní síťařině na *nixech.

Víš jak funguje routovací tabulka na Linuxu? Jak se přidávají odebírají pravidla? Jak nastavené firewally případně mohou na moderních distrech stát v cestě? Ono je dost snadné to poplést a ne vždycky všechno funguje tak jak v návodu na první pokus.

[Matlák]

Jinak to divné na tom výpisu bylo to že adresy nesouhlasily. Ze sítě A to směruje packety na adresu 10.8.0.15 místo 10.8.0.14 a ze sítě B pro změnu packety padají do černé díry 10.8.0.1 místo 10.8.0.2. Ale to je možná jen špička routovacího špagetového ledovce (špagetovce)..

[Tom13]

Teď zkouším openVPN routovaný tunel.

vpn klient 10.11.12.112/24 -> router 10.11.12.2/24 WAN 55.55.55.55/24

vpn server 10.11.12.111/24 -> router 10.11.12.1/24 WAN 55.55.55.56/24

na WAN jsou routery propojené přímo mezi sebou.

Pospuštění skriptu pro bridgování, který jsem našel na stránkách openVPN

má br0 dvě adresy 10.11.12.111/24 a 169.254.19.93/16 po spuštění openVPN serveru dostane tap0 adresu 169.254.58.101/16

po spuštění openVPN klienta dostane tap0 adresu 169.254.115.186/16

ping z 10.11.12.112 na 10.11.12.111 NE ale ping se vrací z 10.11.12.112

ping z 10.11.12.112 na 169.254.115.186 OK

ping z 10.11.12.112 na 169.254.19.93 NE ale ping se vrací z 169.254.115.186

ping z 10.11.12.112 na 169.254.58.101 NE ale ping se vrací z 169.254.115.186

ping z 10.11.12.111 na 10.11.12.112 NE ale ping se vrací z 10.11.12.111

ping z 10.11.12.111 na 169.254.19.93 NE ale ping se vrací z 169.254.58.101

ping z 10.11.12.111 na 169.254.58.101 OK

ping z 10.11.12.111 na 169.254.115.186 NE ale ping se vrací z 169.254.58.101

[Matlák]

Doporučuju nejdřív zkusit jestli si vůbec rozumí oba VPN uzly mezi sebou (ping mezi oběma malinami). A pak bych se koukl na to co je v routovacích tabulkách (ip r l).. Třeba tenhle řádek

ping z 10.11.12.112 na 10.11.12.111 NE ale ping se vrací z 10.11.12.112 

bych si vyložil jako neschopnost 10.11.12.112 vůbec nasměrovat ten packet do té sítě. Nevypsalo to náhodou něco jako "Network is unreachable"? Možná by stálo za to kdybys zkopíroval celý ten výpis pingů a k tomu přidal výpis příkazu ip r l na obou uzlech VPN.

Samozřejmě celou dobu předpokládám, že víš kde je openvpn log, máš ho na obou stranách tunelu zkontrolovaný a že celou dobu pracuješ s funkční spojenou VPN, nad kterou už jenom definuješ routy (a takový ping mezi VPN uzly sis vyzkoušel už dávno).

[Tom13]

Teď nevím jak to myslíš s tím, jestli si rozumí oba uzly - ping mi mezi nima nefunguje, pokud bych měl ping obousměrně server - klient, nebylo by už moc co řešit :)

Je to jak píšeš - není schopné to správně nasměrovat ten packet, ale co si tak matně vzpomínám, když jsem si s tím hrál před lety na Windows, tak mám pocit, že ten tunel používá pár IP na každé straně - jeden pro vstup a druhý pro výstup z tunelu, takže i když je vidět to IP, tak jedno odezvu má a druhé ne, tak mi to myslím na těch Windowsech i fungovalo s pingem, ale to byl routovaný tunel a jak jsem už psal, využíval jsem ho jen k propojení na VNC, které běželo na PC s klientem a připojoval jsem se k němu z PC kde běžel server, takže žádné další směrování ani nic podobného nebylo třeba.

Log jsem prohlížel, ale moc jsem z toho nevyčetl - pro mě je to takové učení se a objevování za pochodu, takže postupně jak na něco přijdu nebo najdu něco na netu, vyzkouším a buď mi to funguje, nebo ne - teď mluvím o tom nastavování openVPN a Linuxu :)

[Matlák]

Teď nevím jak to myslíš s tím, jestli si rozumí oba uzly

Tím myslím, že v logách na obou stranách je "Initialization Sequence Completed" a že tunel se opravdu vytvořil. Chápu že jsi nezkušený, ale snad chápeš že zkoušet pingy a "pokročilejší" směrování nad nespojeným tunelem je jako startovat auto bez benzínu a bez baterie. Prostě doporučuju tohle nepřeskakovat. Až si budeš jistý že tunel funguje (triviálně, bez nějakých bridge komplikací, ping server-klient), pak můžeš řešit další směrování (a problémy s ním spojené).

[Tom13]

Tunel se vytvoří a je funkční a mám jistou, že problém je v routování.

jak jsem psal, před spuštěním serveru se spouští skript, který vytváří zařízení br0, v něm je ještě odvolání na skript, který přidá definice pro firewall, vše je stejné jako v postupu na stránkách openVPN

br0 je nastavené úplně stejně jako karta eth0 na adresu 10.11.12.111/24 brána 10.11.12.1, po spuštění openVPN serveru pak vznikne ještě tap0, tomu se přiřadí adresa 169.254.127.7/16

na straně klienta po spuštění openVPN vznikne tap0, to má dvě IP adresy 10.11.12.x/24 (přidělená z rozsahu DHCP serveru, který běží na straně openVPN serveru a bránu by měl tedy mít 10.11.12.1) a druhou 169.254.x.x/16 - samozřejmě je tam ještě adresa eth0 10.11.12.112/24 brána 10.11.12.10

v této fázi mi funguje pouze ping ze strany klienta na stranu serveru, ale pouze na IP 169.254.127.7, pak funguje ping na IP ze sítě klienta včetně i nově přiřazené adresy ze strany serveru 10.11.12.x, ale nefunguje ping na adresu tap0 169.254.x.x

u serveru funguje ping na adresy ze sítě serveru včetně adresy tap0 169.254.127.7

když na klientovy dám route add -net 10.11.12.0 netmask 255.255.255.0 gw 10.11.12.x (ip adresa přidělená ze strany serveru pro tap0), tak začne fungovat z klienta ping kamkoliv do sítě serveru, ale přestane fungovat ping na pc v síti klienta a nefunguje už ani ping ze sítě klienta na adresy 10.11.12.112 a 10.11.12.x

prostě mi to přijde, jako kdyby přestalo v lokální síti "poslouchat" eth0 na 10.11.12.112 a 10.11.12.x, přitom když si na začátku před přidáním route dám výpis rounte -n vypíše se mi 10.11.12.0 255.255.255.0 eth0 a 10.11.12.0 255.255.255.0 tap0 - což chápu tak, že pokud přijde něco co je směrováno pro síť 10.11.12.x jde to jak na eth0, tak na virtuální tap0, tedy teoreticky by to mělo jít i do druhé části sítě i bez přidání té route

problém je, že nevím, jak bych monitoroval pakety na všech rozhraní, abych zjistil, jestli třeba ping projde na druhou stranu tunelu, ale pak nezná adresu zpět, proto je to pak bez odezvy...

myslím si, že by to fungovalo, pokud bych měl na obou stranách stejnou bránu, což je ale nesmysl, protože i kdyby nevznikl konflikt, nedalo by se nastavit, přes kterou bránu mají pc třeba přistupovat do internetu...

[NN]

Pokud se nekde objevi 169.254.0.0/16 tak to vetsinou znamena, ze mas na rozhrani dostat adresu z DHCP, ale zadnou nedostanes. Pises o smerovani, ale vytvaris premosteni. K sledovani rozhrani pouzij tcpdump. Jak vypada konfigurace na obou stranach?

[Tom13]

Podle toho co jsem vyčetl na stránkách openVPN, tak je to takhle asi správně, protože když se vytváří routovaný tunel, používá IP v rozsahu 10.8.0.0/16 a když bridgovaný, tak je to ten rozsah 169.254.0.0/16.

strana serveru:

*******************
konfigurace serveru
*******************
port 1194
proto tcp
dev tap0

ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key 
dh /etc/openvpn/easy-rsa/keys/dh2048.pem

up bridge-start
down bridge-stop

server-bridge
push "route 10.11.12.0 255.255.255.0"

client-to-client

tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0
cipher AES-128-CBC

keepalive 10 600
comp-lzo
persist-key
persist-tun
verb 6
mute 20
status openvpn-status.log
script-security 2

****************
vípis route -n
****************

Směrovací tabulka v jádru pro IP
Adresát         Brána           Maska           Přízn Metrik Odkaz  Užt Rozhraní
0.0.0.0         10.11.12.1      0.0.0.0         UG    205    0        0 br0
10.11.12.0      0.0.0.0         255.255.255.0   U     205    0        0 br0
169.254.0.0     0.0.0.0         255.255.0.0     U     204    0        0 tap0

****************
výpis ifconfig
****************

br0       Link encap:Ethernet  HWadr 66:bc:11:e1:55:74  
          inet adr:10.11.12.111  Všesměr:10.11.12.255 Maska:255.255.255.0
          inet6-adr: fe80::64bc:11ff:fee1:5574/64 Rozsah:Linka
          AKTIVOVÁNO VŠESMĚROVÉ_VYSÍLÁNÍ BĚŽÍ MULTICAST  MTU:1500  Metrika:1
          RX packets:4923 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4087 errors:0 dropped:0 overruns:0 carrier:0
          kolizí:0 délka odchozí fronty:1000 
          RX bytes:380681 (371.7 KiB)  TX bytes:766854 (748.8 KiB)

eth0      Link encap:Ethernet  HWadr b8:27:eb:db:fc:a7  
          inet6-adr: fe80::9a:bf8e:56d0:d9fc/64 Rozsah:Linka
          AKTIVOVÁNO VŠESMĚROVÉ_VYSÍLÁNÍ BĚŽÍ PROMISK MULTICAST  MTU:1500  Metrika:1
          RX packets:5464 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4778 errors:0 dropped:0 overruns:0 carrier:0
          kolizí:0 délka odchozí fronty:1000 
          RX bytes:485622 (474.2 KiB)  TX bytes:1062836 (1.0 MiB)

lo        Link encap:Místní smyčka  
          inet adr:127.0.0.1 Maska:255.0.0.0
          inet6-adr: ::1/128 Rozsah:Počítač
          AKTIVOVÁNO SMYČKA BĚŽÍ  MTU:65536  Metrika:1
          RX packets:85 errors:0 dropped:0 overruns:0 frame:0
          TX packets:85 errors:0 dropped:0 overruns:0 carrier:0
          kolizí:0 délka odchozí fronty:1 
          RX bytes:7052 (6.8 KiB)  TX bytes:7052 (6.8 KiB)

tap0      Link encap:Ethernet  HWadr 66:bc:11:e1:55:74  
          inet adr:169.254.127.7  Všesměr:169.254.255.255 Maska:255.255.0.0
          inet6-adr: fe80::e623:f0a:fdb4:cafe/64 Rozsah:Linka
          AKTIVOVÁNO VŠESMĚROVÉ_VYSÍLÁNÍ BĚŽÍ PROMISK MULTICAST  MTU:1500  Metrika:1
          RX packets:130 errors:0 dropped:0 overruns:0 frame:0
          TX packets:197 errors:0 dropped:0 overruns:0 carrier:0
          kolizí:0 délka odchozí fronty:100 
          RX bytes:19472 (19.0 KiB)  TX bytes:40105 (39.1 KiB)


**************
výsledky ping
**************

pi@PC-SERVER:~ $ sudo ping -c5 169.254.127.7
PING 169.254.127.7 (169.254.127.7) 56(84) bytes of data.
64 bytes from 169.254.127.7: icmp_seq=1 ttl=64 time=0.174 ms
64 bytes from 169.254.127.7: icmp_seq=2 ttl=64 time=0.058 ms
64 bytes from 169.254.127.7: icmp_seq=3 ttl=64 time=0.086 ms
64 bytes from 169.254.127.7: icmp_seq=4 ttl=64 time=0.060 ms
64 bytes from 169.254.127.7: icmp_seq=5 ttl=64 time=0.051 ms
--- 169.254.127.7 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3996ms
rtt min/avg/max/mdev = 0.051/0.085/0.174/0.047 ms

************************
ping na IP tap0 klienta
************************
pi@PC-SERVER:~ $ sudo ping -c5 169.254.218.227
PING 169.254.218.227 (169.254.218.227) 56(84) bytes of data.
From 169.254.127.7 icmp_seq=1 Destination Host Unreachable
From 169.254.127.7 icmp_seq=2 Destination Host Unreachable
From 169.254.127.7 icmp_seq=3 Destination Host Unreachable
From 169.254.127.7 icmp_seq=4 Destination Host Unreachable
From 169.254.127.7 icmp_seq=5 Destination Host Unreachable
--- 169.254.218.227 ping statistics ---
5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4003ms
pipe 3

*************************************************************************
ping na IP tap0 klienta, které dostal od DHCP umísěného v síti PC-SERVER 
*************************************************************************
pi@PC-SERVER:~ $ sudo ping -c5 10.11.12.211
PING 10.11.12.211 (10.11.12.211) 56(84) bytes of data.
--- 10.11.12.211 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4008ms

*********************************************************
ping na IP eth0 klienta - tu má klient přidělenou napevno
*********************************************************
pi@PC-SERVER:~ $ sudo ping -c5 10.11.12.112
PING 10.11.12.112 (10.11.12.112) 56(84) bytes of data.
--- 10.11.12.112 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4001ms

up bridge-start u serveru spouští skript, který vytváří br0 - z něj se ještě spouští pravidla pro firewall, oba zápisy jsou kopie těch na stránkách openVPN

strana klienta:

*******************
konfigurace klienta
*******************
client
dev tap0
proto tcp
remote x.x.x.x 1194
resolv-retry infinite
nobind
persist-key
persist-tun
mute-replay-warnings
ns-cert-type server
key-direction 1
cipher AES-128-CBC
comp-lzo

verb 6
mute 20

pak následují kódy certifikátů - jsou vložené rovnou do conf a ne jako odkaz na soubory

****************
vípis route -n
****************

Směrovací tabulka v jádru pro IP
Adresát         Brána           Maska           Přízn Metrik Odkaz  Užt Rozhraní
0.0.0.0         10.11.12.10     0.0.0.0         UG    202    0        0 eth0
10.11.12.0      0.0.0.0         255.255.255.0   U     202    0        0 eth0
10.11.12.0      0.0.0.0         255.255.255.0   U     204    0        0 tap0

****************
výpis ifconfig
****************

eth0      Link encap:Ethernet  HWadr b8:27:eb:9c:ad:b1  
          inet adr:10.11.12.112  Všesměr:10.11.12.255 Maska:255.255.255.0
          inet6-adr: fe80::a0ad:d562:7a40:6448/64 Rozsah:Linka
          AKTIVOVÁNO VŠESMĚROVÉ_VYSÍLÁNÍ BĚŽÍ MULTICAST  MTU:1500  Metrika:1
          RX packets:484 errors:0 dropped:0 overruns:0 frame:0
          TX packets:457 errors:0 dropped:0 overruns:0 carrier:0
          kolizí:0 délka odchozí fronty:1000 
          RX bytes:50274 (49.0 KiB)  TX bytes:67205 (65.6 KiB)

lo        Link encap:Místní smyčka  
          inet adr:127.0.0.1 Maska:255.0.0.0
          inet6-adr: ::1/128 Rozsah:Počítač
          AKTIVOVÁNO SMYČKA BĚŽÍ  MTU:65536  Metrika:1
          RX packets:90 errors:0 dropped:0 overruns:0 frame:0
          TX packets:90 errors:0 dropped:0 overruns:0 carrier:0
          kolizí:0 délka odchozí fronty:1 
          RX bytes:7612 (7.4 KiB)  TX bytes:7612 (7.4 KiB)

tap0      Link encap:Ethernet  HWadr d2:c6:06:c4:42:77  
          inet adr:10.11.12.211  Všesměr:255.255.255.255 Maska:255.255.255.0
          inet6-adr: fe80::f662:c610:5980:a995/64 Rozsah:Linka
          AKTIVOVÁNO VŠESMĚROVÉ_VYSÍLÁNÍ BĚŽÍ MULTICAST  MTU:1500  Metrika:1
          RX packets:51 errors:0 dropped:0 overruns:0 frame:0
          TX packets:78 errors:0 dropped:0 overruns:0 carrier:0
          kolizí:0 délka odchozí fronty:100 
          RX bytes:9808 (9.5 KiB)  TX bytes:10273 (10.0 KiB)

****************************************************************************
tap0 má ještě přidělenou druhou adresu 169.254.218.217/16 - ta tu není vidět
****************************************************************************


**************
výsledky ping
**************

*****************************
druhá IP adresa tap0 klienta
*****************************
pi@PC-CLIENT:~ $ sudo ping -c5 169.254.218.227
PING 169.254.218.227 (169.254.218.227) 56(84) bytes of data.
--- 169.254.218.227 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4005ms


**********************
IP adresa tap0 serveru
**********************
pi@PC-CLIENT:~ $ sudo ping -c5 169.254.127.7
PING 169.254.127.7 (169.254.127.7) 56(84) bytes of data.
--- 169.254.127.7 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4007ms

*************************************************************************
ping na IP tap0 klienta, které dostal od DHCP umísěného v síti PC-SERVER 
*************************************************************************
pi@PC-CLIENT:~ $ sudo ping -c5 10.11.12.211
PING 10.11.12.211 (10.11.12.211) 56(84) bytes of data.
64 bytes from 10.11.12.211: icmp_seq=1 ttl=64 time=0.173 ms
64 bytes from 10.11.12.211: icmp_seq=2 ttl=64 time=0.064 ms
64 bytes from 10.11.12.211: icmp_seq=3 ttl=64 time=0.072 ms
64 bytes from 10.11.12.211: icmp_seq=4 ttl=64 time=0.104 ms
64 bytes from 10.11.12.211: icmp_seq=5 ttl=64 time=0.085 ms
--- 10.11.12.211 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3996ms
rtt min/avg/max/mdev = 0.064/0.099/0.173/0.040 ms

*********************************************************
ping na IP eth0 klienta - tu má klient přidělenou napevno
*********************************************************
pi@PC-CLIENT:~ $ sudo ping -c5 10.11.12.112
PING 10.11.12.112 (10.11.12.112) 56(84) bytes of data.
64 bytes from 10.11.12.112: icmp_seq=1 ttl=64 time=0.160 ms
64 bytes from 10.11.12.112: icmp_seq=2 ttl=64 time=0.053 ms
64 bytes from 10.11.12.112: icmp_seq=3 ttl=64 time=0.053 ms
64 bytes from 10.11.12.112: icmp_seq=4 ttl=64 time=0.102 ms
64 bytes from 10.11.12.112: icmp_seq=5 ttl=64 time=0.108 ms
--- 10.11.12.112 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3996ms
rtt min/avg/max/mdev = 0.053/0.095/0.160/0.040 ms

*********************************************************
ping na IP eth0 serveru - tu má server přidělenou napevno
*********************************************************
pi@PC-CLIENT:~ $ sudo ping -c5 10.11.12.111
PING 10.11.12.111 (10.11.12.111) 56(84) bytes of data.
From 10.11.12.112 icmp_seq=1 Destination Host Unreachable
From 10.11.12.112 icmp_seq=2 Destination Host Unreachable
From 10.11.12.112 icmp_seq=3 Destination Host Unreachable
From 10.11.12.112 icmp_seq=4 Destination Host Unreachable
From 10.11.12.112 icmp_seq=5 Destination Host Unreachable
--- 10.11.12.111 ping statistics ---
5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4000ms
pipe 3

už jsem toho vyzkoušel spoustu, ale prostě mi to pořád nefunguje - když přidám u klienta tu routu jak jsem psal výše, začne mi fungovat ping do sítě serveru, ale přestane mi fungovat ping do sítě, ve které je klient - proto jsem psal, že to bude v routování - vím, že se pokouším o bridge, ale podle všeho openVPN k tomu interně používá ty adresy z rozsahu 169.254.0.0/16 (podobně jako u routovaného tunelu, kde používá pro komunikaci tunelem také svůj rozsah 10.8.0.0/16) - zkoušel jsem i spouštět skript pro vytvoření br0 na straně klienta, ale pak se tunel vůbec nevytvoří a když zkusím ručně přiřadit IP pro tap0 na straně serveru z rozsahu 10.11.12.0/24, tak pak přijdu o spojení se serverem (jsem k němu připojený přes VNC), na straně klienta se tap0 adresa přiřadí buď z DHCP od NATu, nebo mu ho přidělí sám openVPN server ze svého přiděleného rozsahu - záleží na konfiguraci - ale ve výsledku se nic nemění, samozřejmě rozsahy DHCP se nepřekrývají a každá síť má jinou bránu - strana serveru 10.11.12.1/24, strana klienta 10.11.12.10/24 a žádné zařízení nemá shodnou IP adresu s jiným z té druhé sítě - ještě jsem přišel na to, že pokud přidám tu zmiňovanou routu u klienta, sice pak funguje ping do sítě serveru, ale nejsem schopný se třeba připojit k internetu, protože se nejspíš stále pokouší jít přes bránu klienta a ta je v tu chvíli nedostupná...

[Josef Kufner]

Jo, to routování máš nějaké divné.

Nakresli si to.

Kdo má jakou IP? Jaká je kde síť (rozsah)? Kdo kam vidí? Kam má co poslat?

[Tom13]

Tak původně jsem si myslel, že si tohle všechno nastaví openVPN samo - ono je to vlastně od něj takhle divně nastavené a mě není jasné proč, když jsem ho kdysi používal na Windowsech, fungovalo to vlastně okamžitě bez nějakého dalšího nastavování z mé strany...

[NN]

No a problem je na svete. Push route na klienta nepomuze, protoze jeho default routa ma nizsi metriku:

10.11.12.0      0.0.0.0         255.255.255.0   U     202    0        0 eth0
10.11.12.0      0.0.0.0         255.255.255.0   U     204    0        0 tap0

Pocitam, ze ping ze serveru odejde, ale uz se nevrati. U klienta jeste chybi routa pro 169.254.0.0, takze taktez vse odchazi pres default GW a uz se nevrati. Pokud to budes chtit takto rozseknout asi by se vyplatilo definovat oboustrane staticke routy pro jednotliva zarizeni tak, aby specificky provoz neodchazel pres vychozi brany, ale tunelem.

[Tom13]

V routování se moc nevyznám, jak bych tedy změnil tu metriku, nebo měl nastavit to routování?

Jinak u toho klienta ta routa 169.254.0.0 by možná ani být nemusela, protože mám pocit, že ty rozsahy 169.254.0.0 slouží jako výstup z toho tunelu - někde jsem na to narazil, ale už nevím kde - takže by možná stačilo jen směrovat ten provoz u klienta jak na eth0, tak na tap0 a u serveru je to možná i správně, ale vzhledem k tomu, že má tap0 nižší prioritu, tak se ta odpověď na ping ze strany server -> klient nevrátí, protože to jde jen na eth0 díky té metrice.

[Tom13]

když jsem to teď ještě tak prohlížel, napadla mě jedna věc - co by se stalo, pokud bych nějak u těch routovacích tabulek změnil ty metriky tak, aby to bylo všude stejné - co jsem si našel, tak se to bere od nejnižšího k nejvyššímu, takže třeba u klienta to podle toho vůbec nejde na tap0 - pokud bych tam měl všude metriku 202, poslal by se pak ten paket jak na eth0 tak na tap0? Protože pokud ano, nejspíš by to vyřešilo ten můj problém, ale v sítích se až tak nevyznám...

[Tom13]

a ještě jedna věc

většina příkladů, co jsem našel a podle kterých postupuji má odlišnou topologii sítě, než mám já - openVPN server je buď v nějakém NATu, nebo je to PC, které současně slouží i jako brána...

druhá věc je ta, že jsem zatím nikde nezjistil, jestli je vlastně ten openVPN klient funkční jako propojovací mezičlánek, mezi lokální sítí a tunelem do jiné sítě, protože co jsem našel, bylo to buď jako koncový klient, který se připojí a dál už nic, nebo opět jako cosi v NATu, nebo jako PC, které bylo zase současně i jako brána dané podsítě

ani jedno z toho není můj případ a vlastně jsem ani nenarazil na to, že by někdo řešil stejné uspořádání jako mám já - tedy:

PC v síti a openVPN server zapojené do NATu -> kabelový modem poskytovatele -> internet <- modem poskytovatele <- NAT a z něj připojený openVPN klient a ostatní PC v síti

[Tom13]

Postup instalace Raspberry:

stáhnul jsem si img obraz - ne verzi LITE

pak jsem dal image na kartu, spustil Raspberry, upravil nastavení, změnil IP

aktualizoval systém pomocí sudo apt-get update a pak sudo apt-get upgrade

abych viděl Raspberry ve skupině a mohl případně sdílet přidal jsem sambu sudo apt-get install samba samba-common-bin

pak jsem spustil sudo nano /etc/samba/smb.conf a upravil řádek workgroup = WORKGROUP na workgroup = DOMA v návodu ještě psali o povolení wins support, ale to jsem nedělal, wins mi nikde neběží, tak mi to přijde zbytečné a sdílení i viditelnost ve skupině funguje i bez toho

pak jsem nainstaloval openVPN pomocí sudo apt-get install openvpn -y

dál jsem pro routování použil tenhle postup

u klienta jsem pak jen povolil ten ip4 forwarding a dokopíroval si conf soubor vygenerovaný na serveru a přidal ta pravidla pro firewall

pro bridgování jsem postupoval takhle - tedy ne úplně, protože certifikáty mám zálohované, zkoušel jsem použít jak ten skript pro bridge z těch stránek, tak i ten jednodušší z openVPN stránek a samozřejmě ty utility pro bridge jsem také doinstaloval a pravidla pro firewall nastavil na obou strojích - udělal jsem to podle návodu routování, přidáním toho odkazu na sh soubor

[knizmi]

Pouzivam OpenVPN k necemu podobnemu, takze nastaveni by u tebe melo byt skoro stejne. Domaci sit mam za NATem a abych se do ni dostal, tak jsem si za par korun poridil VPS s verejnou adresou, na nem rozjel OpenVPN server, ke kteremu je stale pripojeny klient doma + kdyz potrebuju, tak se pripojim z nejake jine lokality.

V podstate tam neni nic sloziteho, je k tomu hromada tutorialu, akorat bych vypichnul nasledujici:

• v konfiguraci OpenVPN na serveru musi byt povoleno, aby klienti mohli navzajem komunikovat (client-to-client)
• na klientovi v domaci siti mam zapnutou maskaradu, na firewallu je povoleny forwarding z tun0 na fyzicke rozhrani (jak je popsano uplne dole na https://community.openvpn.net/openvpn/wiki/BridgingAndRouting) a v /etc/sysctl.conf je samozrejme povoleny IP forwarding
• v konfiguraci OpenVPN na serveru pomoci route 10.20.30.0 255.255.255.0 10.8.0.9 posilam vsem klientum, ze do site 10.20.30.0/24 se leze pres 10.8.0.9
• v CCD pro vzdalene klienty mam akorat ifconfig-push s jejich adresou a maskou, abych mel jistotu, ze kazdy klient dostane adresu, kterou chci (i kdyz by to asi stacilo jen u toho klienta v domaci siti)
• pro klienta v domaci siti mam v CCD navic jeste iroute 10.20.30.0 255.255.255.0 a v konfiguraku ma zakazano prebirat routy ze serveru

Pozn. jak vyplyva z textu vyse, domaci sit je 10.20.30.0/24 a OpenVPN pouziva 10.8.0.0/24. Rozhodne se nejedna o jedinou moznost, jak to nastavit a s nejvetsi pravdepodobnosti to neni ani idealni moznost. Ale funguje to :)

[Tom13]

No myslím, že to "skoro stejné" je asi ten problém :)

Obě sítě mám za NATem, jak jsem psal a za ním jsou i openVPN server i klient, port 1194 se směruje v NATu na IP klienta a serveru.

- client-to-client mám povolené

- když jsem testoval routovaný tunel, zkoušel jsem to přidávat, ale nepomohlo mi to, ale abych byl upřímný v tu dobu jsem ještě nevěděl, jak si ověřit, že se ty pravidla opravdu provádí, IP forwarding mám zapnutý

- to jsem tam měl taky a fungoval mi i ping klient - server, dál ale ne

- CCD jsem zatím nezkoušel a nepoužíval, v tom návodu co jsem používal ani není a asi to ani nic, co by to nějak zásadně ovlivnilo

- to přebírání routy ze serveru nevím, jak moc by to ovlivnilo, ale nic v tom návodu o tomhle není, takže to nemám vyzkoušené

To o co se pokouším, je propojení dvou sítí stejného IP rozsahu pomocí bridgování přes openVPN, takže se to pak opticky bude jevit jako jedna síť, jakoby tam ani žádné propojení nebylo a bohužel zatím mi to nefunguje :)

[fghj]

A nebylo by jednodušší mít jenom jeden vpn server s veřejnou ip a všecko ostatní připojovat jako klienty? Takto musíš mít furt minimálně dvě mašiny online aby ti to fungovalo a když se náhodou něco posere na stroji který děla bridge tak ti vypadne celá půlka sítě.

[Tom13]

Server VPN mám jen jeden a pokud bude výpadek je to jedno, ty části sítě fungují nezávisle, jen bych je prostě rád spojil přes bridge. Navíc je to pořád stejný problém, prostě se ten klient nepřipojí k serveru tak, aby to fungovalo, zatím se mi to nepovedlo ani pomocí routovaného tunelu, ani pomocí bridge, to jestli to celé pak bude přes server - klient sloužit jako propojení sítí není podstatné, protože to zatím nefunguje ani jako propojení server - klient ve smyslu, který navrhuješ.

[fghj]

Hm openvpn moc neznám, používám spíš toto. Je tam několik možností jak ty lan sítě propojit. Navíc se to dá docela jednoduše naklikat v gui, tak je daleko menší šance že ti to třeba nebude chodit jenom proto, že zapomněls napsat nějakou pitomou tečku nebo závorku do konfiguráku. Minimálně pro inspiraci stojí za to na to mrknout.

[Tom13]

Jde o to, že nevím, jestli bych tohle nějak dostal na ty Raspberry, protože openVPN to má přímo jako balíček, takže se to instaluje přes apt-get - v Linuxu se moc nevyznám, tak nevím, jak instalovat věci, co to nemá v těch repozitářích (nebo jak se to jmenuje) :)

Důležitá věc je, že to už funguje - zkoušel jsem měnit metriku, ale to nejde, když jsou metriky stejný, bere to tap0, takže pak nevidím stejně do sítě klienta, ale zkusil jsem na klientovy spustit ten skript na tvorbu br0 (musí se mu pak přidělit ručně IP adresa jakou má eth0 - to se musí i na straně serveru), pak pravidla pro firewall, a pak se připojit a normálně se to spojilo - už jsem to párkrát zkoušel, ale předtím se mi to nechtělo spojit), ping funguje obousměrně a z Windows vidím obě sítě jako jednu, když se připojím přes tu druhou bránu (tunelem) na net, tak to běží cca 2Mb namísto cca 8Mb - trochu to nechápu, protože jsem myslel, že to půjde pouze tou nejpomalejší rychlostí - připojení na straně serveru je cca 30Mb/3Mb a na straně klienta cca 8Mb/1Mb a při měření mi přes tunel vyšlo 2Mb/256b - tak nevím, čekal bych že to bude tím tunelem max. 1Mb/1Mb - podle nejpomalejší odchozí rychlosti - ale to už je jedno, hlavně že to jde :)

Díky moc všem za snahu o pomoc při řešení problému :)

[Tom13]

Tak jsem trochu pokročil - včera jsem zjistil, že při vytváření tunelu si klient na virtuálním rozhraní tun0 vezme IP adresu z DHCP, který běží v síti serveru. Když si tam dám seznam DHCP klientů, je tam vidět jak vpn klient, tak i server, ten si vezme IP pro virtuální rozhraní br0.

Když spustím openVPN na Raspberry, které má sloužit jako server, tak se nejdřív spustí skript, který vytvoří virtuální rozhraní br0, to si načte IP z DHCP serveru a ještě rozhraní tap0 a to má IP z rozsahu 169.254.0.0/16, takže openVPN server má celkem tři IP adresy:

10.11.12.111 - adresa eth0 adaptéru nakonfigurovaná natvrdo, ale u ní je napsáno expired - ping OK

10.11.12.x - adresa virtuálního br0 - tu si vezme od DHCP, který je ve stejné síti na 10.11.12.1 - ping OK

169.254.x.x - adresa virtuálního tap0 - tu načte nevím kde - ping OK

Na straně klienta se po spuštění vytvoří virtuální rozhraní tap0, které má dvě IP adresy, tu první má přidělenou od DHCP serveru, který je v síti serveru openVPN, druhá je z rozsahu 169.254.0.0/16, takže má také celkem tři IP adresy:

10.11.12.112 - adresa eth0 konfigurovaná natvrdo - ping OK

10.11.12.x - adresa virtuálního tap0, kterou mu přidělil DHCP server ze sítě openVPN serveru - ping OK

169.254.x.x - adresa virtuálního tap0 - ta se načte nevím kde - ping NE

ping server - klient

10.11.12.112 - ping NE - pokouší se jít přes svou adresu 10.11.12.111

10.11.12.x - ping NE - pokouší se jít přes svou adresu 10.11.12.111

169.254.x.x - ping NE - pokouší se ale jít přes svou IP 169.254.x.x

ping klient - server

10.11.12.111 - ping NE - pokouší se jít přes svou adresu 10.11.12.112

10.11.12.x - ping NE - pokouší se jít přes svou adresu 10.11.12.112

169.254.x.x - ping NE

Když jsem experimentoval s přidáváním routovacích cest, dostal jsem se pak z klienta na server a i do jeho sítě, dokonce pak i z jiného PC s Windows mi prošel jak ping, tak bylo vidět i ostatní zařízení v síti serveru openVPN, ale po poklepání na ně to vypsalo, že jsou nedostupné. Nevím, ale napadlo mě, jestli to není tím, že je openVPN server jinde než brána a DHCP...