Dotaz: VN místo VPN

[Petr_70]

Dobrý den všem,

Prosím vás, rád bych znal vaše názory, zdali je nějak řešitelný následující problém:

Mám firemní veřejný subnet 1.2.3.0/24 a na serveru v tomto veřejném subnetu bych rád postavil virtuální tunel pomocí OpenVPN pro připojení z domu nebo jiné privátní sítě. Odtud bych měl rád dostupné sdílené tiskárny, adresáře ve firemní veřejné síti přes OpenVPN (proto v nadpisu uvádím VN namísto VPN) v režimu bridge - tedy vlastně jakoby z domácí privátní sítě "natáhnout" dlouhý virtuální kabel do switche ve veřejném firemním subnetu (tedy domácí PC/notebook by přes OpenVPN dostal přidělenu firemní veřejnou IP adresu z uvedeného rozsahu).

Konkrétně to je nakonfigurováno tak, že server má dvě ethernet rozhraní eth0 s IP 1.2.3.15/24 a eth1 s IP 1.2.3.16/24 a na tomto eth1 rozhraní je vytvořen bridge (eth1+br0) a do něj přidáno zařízení tap0 - jeden konec tunelu (VPN server).

Server není současně default gateway subnetu - ten je na adrese 1.2.3.1/24 a nemám k němu žádnou možnost přístupu (nastavení/konfigurace).

A nyní k podstatě problému: Po připojení z domácí privátní sítě klient sice obdrží veřejnou IP adresu z rozsahu 1.2.3.0, ale pripojení nefunguje, protože IP serveru (eth0 s IP 1.2.3.15/24) na který se připojuji je současně v rozsahu VPN. Viz část výpisu logu klienta:

Wed Mar 02 23:14:19 2016 WARNING: --remote address [1.2.3.15] conflicts with --ifconfig subnet [1.2.3.17, 255.255.255.0] -- local and remote addresses cannot be inside of the --ifconfig subnet. (silence this warning with --ifconfig-nowarn).

Jak by bylo možné to vyřešit, bez nutnosti zrušení přemostění do veřejné LAN a nutnosti přeadresovat VPN na privátní rozsah adres na eth1 a použití NAT?

Bohužel nemohu použít ani proxy-ARP, protože bych musel mít naroutovánu a ve vlastní správě část veřejného firemního subnetu... Chápu-li to správně.

Děkuji předem za rady a případný nástin možných řešení. Pokud by v této konfiguraci řešení nebylo možné v rámci OpenVPN (což předpokládám, i když by to bylo lepší), přivítám alternativní řešení "tunel-bridge" do veřejné sítě, např. PPTP, IPSec...

---

---

Odpovědi

[NN]

Odtud bych měl rád dostupné sdílené tiskárny, adresáře ve firemní veřejné síti přes OpenVPN

Pocitam, ze nemate tiskarny s dostupne z internetu, takze bych navrhoval tvuj cely dotaz preformulovat tak aby daval vetsi smysl ve veci adres. Plus dolozit aktualni konfiguraci a idealne i schema.

[Slota]

...a idealne aj s pritupovymi menami a heslami, treba mi rychlo nieco vytlacit

[Petr_70]

Pocitam, ze nemate tiskarny s dostupne z internetu, takze bych navrhoval tvuj cely dotaz preformulovat tak aby daval vetsi smysl ve veci adres. Plus dolozit aktualni konfiguraci a idealne i schema.

Ano, tiskárny mají veřejnou IP v rozsahu subnetu také, jejich zabezpečení je na jinou debatu. Aktuální konfiguraci jsem myslím dostatečně popsal, co je vám nejasné? Chci jen návrh funkčního přístupu ve smyslu jak jsem popsal.

Děkuji za věcné příspěvky.

[NN]

Nekolik veci, Nebudu spekulovat nad tim, ze tiskarny maji verejnou IP. Jeste bych se pozastavil napriklad nad timto:

server má dvě ethernet rozhraní eth0 s IP 1.2.3.15/24 a eth1 s IP 1.2.3.16/24

To je prece ukazkova kolize, nemuzes mit na dvou rozhranich stejnou IP sit, to uz ti musi zahlasit i system pri konfiguraci. Zadruhuhe je ti jasne, ze VPN funguje tak, ze mas jednu sit pro tunel a jednu sit tunelujes. Tvuj navrh totiz nemuze fungovat uz z principu veci. Zatreti, chtel jsem te pozadat aby jsi dolozil aktualni konfiguraci openvpn.conf pokud to neni problem..

Tzn. jeden teoreticky navrh padl verejnou sit rozdelit a pres jeden protlacit ten druhy. Otazka je jestli je to vubec realne.

[Petr_70]

Jeste bych se pozastavil napriklad nad timto:

server má dvě ethernet rozhraní eth0 s IP 1.2.3.15/24 a eth1 s IP 1.2.3.16/24

To je prece ukazkova kolize, nemuzes mit na dvou rozhranich stejnou IP sit, to uz ti musi zahlasit i system pri konfiguraci. Zadruhuhe je ti jasne, ze VPN funguje tak, ze mas jednu sit pro tunel a jednu sit tunelujes. Tvuj navrh totiz nemuze fungovat uz z principu veci. Zatreti, chtel jsem te pozadat aby jsi dolozil aktualni konfiguraci openvpn.conf pokud to neni problem..

Tzn. jeden teoreticky navrh padl verejnou sit rozdelit a pres jeden protlacit ten druhy. Otazka je jestli je to vubec realne.

Ano, tohle všechno je pravda.

Ale mě šlo právě o to jak to udělat (netrvám na VPN) abych bez nutnosti přeadresování a tedy bez použití NAT, mohl být doma součástí firemní PUBLIC sítě (proto režim bridge) - s využitím volného rozhraní eth1 na serveru, který by fungoval jako "port switche", jestli mi rozumíte?

Rozdělit veřejnou síť reálné opravdu není, jak jsem už napsal v dotazu.

[NN]

Tady prece neni co resit, verejne adresy jsou dostupne z venku. Nic ti nebrani pristupovat na ne primo.

[nelson]

Bez vazby na puvodni dotaz :) Kolize to neni, linuxovy kernel dovoli nastavit na dvou ifacech ruzne adresy ze stejne site. Dokonce to pak i funguje.

root@artemis:~# ip a add 172.20.0.1/24 dev eth0
root@artemis:~# ip a add 172.20.0.2/24 dev dummy0
root@artemis:~# ip -4 a
1: lo    inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
...
2: eth0    inet 172.20.0.1/24 scope global eth0
valid_lft forever preferred_lft forever
...
21: dummy0    inet 172.20.0.2/24 scope global dummy0
valid_lft forever preferred_lft forever
root@artemis:~# ip r
...
172.20.0.0/24 dev eth0  proto kernel  scope link  src 172.20.0.1 
172.20.0.0/24 dev dummy0  proto kernel  scope link  src 172.20.0.2 

Nevyhody reseni jsou jasne, chovani trochu nepredikovatelne (hlavne zdrojova adresa pri zacatku komunikace), lepsi by bylo rozhrani bondovat a nastavit adresu na bond.

[Michal Kubeček]

Pokud budou obě rozhraní připojena do stejného segmentu (což je podle popisu pravděpodobné), bude přinejmenším potřeba trochu poladit sysctl, aby stroj neodpovídal na ARP dotazy na "špatném" rozhraní.

Jinak souhlasím, bond/team by byl lepší a pokud bude tazatel chtít používat dvě různé adresy pro různé účely, není problém je na něm nastavit obě.

[Petr_70]

Michal Kubeček:

Ano jsou ve stejném segmentu:

1.2.3.15/24 Na tohle rozhraní se připojuji

1.2.3.16/24 na tomto je tunelovaná/přemostěná síť (eth1+br0)+tap0 VPN

[Petr_70]

..., lepsi by bylo rozhrani bondovat a nastavit adresu na bond.

Nějak nerozumím. Můžete mi prosím trochu objasnit, co tím myslíte?

Děkuji.

[Michal Kubeček]

bonding, teaming

V praxi by to vypadalo např. nějak takhle:

modprobe bonding max_bonds=0
ip link add bond1 type bond mode active-backup miimon 100
ip link set eth0 master bond1
ip link set eth1 master bond1
ip link set bond1 up
ip link set eth0 up
ip link set eth1 up
ip addr add 1.2.3.4/24 brd + dev bond1
ip addr add 1.2.3.5/24 brd + dev bond1

Můžeme si u vás taky něco vytisknout?

[pavlix]

Použití vysokého napětí místo virtual private network doporučuju.

[Petr_70]

Použití vysokého napětí místo virtual private network doporučuju.

:)

[pavlix]

To ovšem není odpověď na skrytou otázku, co že se myslí tím VN?

[Petr_70]

To ovšem není odpověď na skrytou otázku, co že se myslí tím VN?

VPN = virtual private network

VN = virtual network

[Filip Jirsák]

To „private“ neznamená, že by to běželo na IP adresách ze speciálních rozsahů, které bývají označovány jako „privátní IP adresy“. „Private“ znamená, že komunikace v tom tunelu je šifrovaná, takže ji nikdo z venku nemůže odposlouchávat – je privátní.

Je smutné, jak jsou někteří ostatní komentující tak zblblí NATy, že komunikaci na veřejných IP adresách považují za anomálii a neustále vymýšlejí, jak někam ty privátní rozsahy IP adres nacpat. Už aby IPv4 zaniklo, dokud si ještě někteří lidé pamatují, jak vypadá normální IP síť.

[pavlix]

Jasně, takže si vymýšlíme nové pojmy pro zmatení nepřítele.

[tuxmartin]

Wed Mar 02 23:14:19 2016 WARNING: --remote address [1.2.3.15] conflicts with --ifconfig subnet [1.2.3.17, 255.255.255.0] -- local and remote addresses cannot be inside of the --ifconfig subnet. (silence this warning with --ifconfig-nowarn).

To je jednoduche. Na obou stranach pouzivate neverejne IP a nahodou obe site pouzivaji stejne

Mate v zasade dve moznosti:

1. IPv6 - hezke, ale zatim ne moc realne.
2. Pouzit takovy neverejny subnet, u ktereho je minimalni pravdepodobnost kolize.

Takze zvolit pro firemni sit 192.168.0.0/24, pripadne 192.168.1.0/24 je spatny napad. Vetsina domacich routeru ma stejny rozsah.

Ja aktualne pouzivam 10.123.0.0/16 a zatim jsem nemel problem.

Chcete-li, mam na blogu nejake navody na OpenVPN.

Debata je o tom, že používá veřejné ip adresy.

Nástřel. Musíte si tu síť /24 rozseknout na nějaké podsítě /25, /26 ... a připojovat se na ip adresu z jiné podsítě, než ze které rozdáváte ip adresy klientům připojeným přes VPN.

[Petr_70]

Nástřel. Musíte si tu síť /24 rozseknout na nějaké podsítě /25, /26 ... a připojovat se na ip adresu z jiné podsítě, než ze které rozdáváte ip adresy klientům připojeným přes VPN.

Ano, kdyby ten subnet /24 bylo možné rozdělit, tak není co řešit.

Ale bohužel nelze... :(

[Filip Jirsák]

Ten „konflikt“ IP adres není důvod, proč by připojení nefungovalo – prakticky v každé routovací tabulce máte pro některé IP adresy víc záznamů, a platí pravidlo, že přednost má specifičtější záznam (podle masky sítě). Pravděpodobně máte v routovací tabulce záznam 0.0.0.0/0, který pokrývá všechny IPv4 adresy – a jakýkoli další záznam v routovací tabulce je s tímto záznamem „v konfliktu“, a ničemu to nevadí.

Ten výpis v logu klienta je jen varování, a ve vašem případě je ta konfigurace správná – v tom logu máte také napsáno, jak ho vypnout.

Dejte sem výpis ip route, ať vidíme, jak s tím navázaným tunelem vypadá routovací tabulka. Co přesně znamená „připojení nefunguje“? Zkuste po připojení ping na tu protistranu VPN spojení (1.2.3.15) a na nějaké jiné zařízení v té vzdálené síti. Ideální by bylo, pokud můžete na tom 1.2.3.15 spustit tcpdump na ICMP echo pakety a zároveň ověřit, které ty vaše pingy dorazí a zda k nim dorazí nějaká odpověď.

Mimochodem, když v popisu změníte IP adresy, je dobré to uvést, může to být matoucí.

[Petr_70]

Co přesně znamená „připojení nefunguje“? Zkuste po připojení ping na tu protistranu VPN spojení (1.2.3.15) a na nějaké jiné zařízení v té vzdálené síti. Ideální by bylo, pokud můžete na tom 1.2.3.15 spustit tcpdump na ICMP echo pakety a zároveň ověřit, které ty vaše pingy dorazí a zda k nim dorazí nějaká odpověď.

To že připojení nefunguje znamená přesně to, že není ze na strany serveru odezva na ping (žádná "živá" adresa z toho subnetu). Klient se sice připojí a také přidělí adresu, masku i DNS z veřejného subnetu (direktiva "push"), ale ping nejde...

Jak už tady vícekrát zaznělo, vidím problém prostě v tom, že pro připojení k serveru je použita adresa z rozsahu stejné sitě, kterou připojuji.

Bohužel nevím, jak to obejít. Opravdu si myslíte, že to může fungovat?

Jinak vám děkuji za odpověď.

Tzn. že openvpn jako takové funguje, spojí se, vytvoří VPN a přidělí nějakou adresu, kterou jste nadirigoval. Nefunguje ale spojení po vytvořené VPN.

Kde mizí pingy? Dojdou na druhou stranu? Kam se dostanou? tcpdump je váš přítel.

Není ta chyba prostě jenom v nastavení firewalu na vašem serveru/klientu?

[Petr_70]

Není ta chyba prostě jenom v nastavení firewalu na vašem serveru/klientu?

Tak na serveru jsem měl při testech skript s pravidly firewallu vypnutý, ale ne tak doma na klientu s Windows.

Doma zkusím připojení po jeho vypnutí a podívám se s pomocí tcdump, kde se to ztrácí...

Prozatím vám moc děkuji, dám vědět jak to dopadlo. :)

[Filip Jirsák]

Zkontrolujte také, že zdrojová adresa toho pingu je ta IP adresa přidělená přes VPN. Pokud by to byla jiná IP adresa, dorazí ping sice správně na server, ale ten o té zdrojové adrese nebude nic vědět a pošle odpověď na bránu místo do VPN. Sice by ping měl tuhle adresu zvolit sám, ale bůhví, jak se chová Windowsovský ping.

[Michal Kubeček]

Sice by ping měl tuhle adresu zvolit sám

Jediná situace, kdy si ping určuje zdrojovou adresu sám, je když mu ji explicitně zadáte pomocí "-I".

Ono to patrně nefunguje proto, že se jedná o veřejné IP adresy. Takže klient se bez problémů připojí k serveru, openvpn na obou stranách se dohodnou a poté server přidělí klientu ip adresu. V okamžiku, kdy ji klient u sebe aktivuje, je pro něj rázem server nedostupný, protože se mu změní routa k serveru. Původně byl openvpn server dostupný přes default gateway. Ale jakmile dostane klient ip adresu ze vzdáleného veřejného rozsahu 1.2.3.xx/24, snaží se posílat pakety k serveru vpn tunelem, což ale nejde.

Takže je na to třeba myslet a nastavit si routu k openvpn serveru přes defaultní gateway.

Rozchodil jsem to i bez přidané druhé ip adresy na openvpn serveru.

[pavlix]

Ono to patrně nefunguje proto, že se jedná o veřejné IP adresy.

Uh?

vole přečti si to celé a uvažuj.

[Michal Kubeček]

Ať uvažuji, jak uvažuji, pořád v tom nevidím problém "veřejných" adres, ale toho, že se pro implementaci tunelu jako "vnější" adresy použijí takové, které zároveň spadají do rozsahu, který se má tunelovat. Když totéž uděláte s "neveřejnými" adresami, dopadnete úplně stejně.

Kdyby se jednalo o neveřejné ip adresy, tak se tazatel neptá v diskusi, ale dávno mu to chodí. Tady patrně zapomněl na to routování a v důsledku toho mu to nechodilo.

Když je vám to tak jasné, mohl jste na tento problém upozornit sám.

[Michal Kubeček]

Kdyby se jednalo o neveřejné ip adresy, tak se tazatel neptá v diskusi, ale dávno mu to chodí.

Ne. Ten problém je naprosto nezávislý na tom, jestli jsou adresy "veřejné" nebo ne. Není problém vyrobit fungující konfiguraci s "veřejnými" adresami, stejně jako nefungující s "neveřejnými".

Nějak jsem si nevšiml, že byste zde poradil něco smysluplného.

Problém se dá vyrobit všude. Například doporučit bonding, aby se to ještě více zatemnilo.

[Michal Kubeček]

Nějak jsem si nevšiml, že byste zde poradil něco smysluplného.

V době, kdy to mělo smysl, jsem neměl čas snažit se zorientovat ve zmateném a mlhavém popisu situace a odhadovat, co asi měl tazatel skutečně na mysli. Když se to vyjasnil (a já se k diskusi dostal znovu), nemělo smysl psát znovu to, co už napsal někdo přede mnou.

A aspoň nepíšu věci, které nejsou pravda. Jako třeba že problém je v použití "veřejných" adres. To je prostě zjevný nesmysl a nadáváním ani jinými výpady na tom nic nezměníte.

Například doporučit bonding, aby se to ještě více zatemnilo.

Rozhodně je to rozumnější, než bez potřebných opatření připojit dvě rozhraní do stejného segmentu a divit se, proč mám problémy s ARP.

Už se s vámi nebudu hádat. Neměl jsem psát tu větu tak, jak jsem ji napsal. Měl jsem to napsat jinak. Tipnul jsem, že chyba je v routování. A díky tomu, že se jedná o veřejné ip adresy, které jsou normálně routovatelné, tazatel zapomněl zajistit, aby po vzniku tunelu zůstala ip adresa openvpn serveru nadále routovatá přes původní bránu.

[Filip Jirsák]

Je smutné, jak jsou někteří ostatní komentující tak zblblí NATy, že komunikaci na veřejných IP adresách považují za anomálii a neustále vymýšlejí, jak někam ty privátní rozsahy IP adres nacpat. Už aby IPv4 zaniklo, dokud si ještě někteří lidé pamatují, jak vypadá normální IP síť.

Ano, bylo to i na vás.

No, vy jste aspoň naznačil, že problém může být i v routování .

Obávám se, že vámi nenáviděné ipv4 tady ještě nějakou dobu bude (včetně privátních rozsahů), protože spousty dosud používaných zařízení prostě ipv6 neumí.

[pavlix]

Nenáviděné IPv4? Co to je za pitomost? Bavíme se o technologických a praktických důvodech vycházejících z rozšíření internetu mezi běžné obyvatelstvo, ne o nějakých citech. To zavání cargo kultem.

[pavlix]

Mně tahle jedna věta bohatě stačila. Máte dost zvláštní smysl pro humor. :)

[izidor]

jo, fungovat to teoreticky muze. Melo by stacit vyrobit pro to pripojeni specifickou routu. Tedy:

server:
...15 adresa eth0
...16 adresa br0
br0 je bridge mezi eth1 a tap0

routa server: ...0/24 -> eth0
              ...17/32 -> br0

klient:
...17 adresa br0

routa klient: ...0/24 -> tap0
              ...15/32 -> eth0

Takze kdyz jde paket z klienta ...17, tak se posle do tap0. Tam jej openVPN zabali a posle na adresu ...15. Na serveru ...15 se paket vybali a dorazi pres eth0 k cili. Cil posle paket na ...17, ten OpenVPN zabali a posle a adresu klienta.

Tolik k teoreticke rovine. Prakticky by bylo potreba videt vypisy routovacich tabulek a kazdy krok odsledovat tcpdumpem, zda kazdy krok posle paket tam, kam ma.

[Andrej]

Tohle je klasický use case pro IPv6 z roku 1995, který by jistě posloužil lépe než IPv4 z roku 1975.

Nemá smysl bojovat s nepoužitelností IPv4. Ta už byla velmi dobře popsaná a prozkoumaná.

[Filip Jirsák]

V síti, kam se tazatel chce připojit, jsou veřejné IPv4 adresy. Tazatel pouze potřebuje bezpečně obejít firewall. IPv6 samotné by mu tedy nijak nepomohlo.

[Andrej]

Možná by pomohlo, možná ne. To už záleží na konkrétní konfiguraci sítě. K samotnému obcházení firewallu se těžko najde něco lepšího než IPSec a tam IPv6 vskutku exceluje, například tím, že se dá použít stejná (samozřejmě veřejná) adresa pro IPSec i pro nešifrovanou komunikaci (tedy něco jako %dynamic ve StrongSwan) a na routeru nastavit, co k zařízením ve vnitřní síti projde a co ne. Takže například z nešifrovaného Internetu se spojení do vnitřní sítě navazovat nedají, zatímco z IPSec připojení (ke stejné veřejné IPv6 adrese) už ano.

Jenže opět je tady celá diskuse zaplevelená OpenVPN, protože některé uživatele magicky přitahuje to „VPN“ v názvu, přestože pro 999‰ případů VPN je nejlepším řešením IPSec. IPSec je prostě součástí síťového stacku přímo v kernelu, se všemi jeho efektivními vymoženostmi. OpenVPN je řešení s minimálně dvěma extra context-switchi kvůli každému paketu a s multi-threadingem v nedohlednu. To je snad horší případ než OpenBSD, co se týká efektivity, a to už je co říct.

[Petr_70]

Všem přispěvovatelům moc děkuji za reakce a současně se moc omlouvám za avizovanou opožděnou odpověď, z důvodu nutnosti řešit jiné věci. :)

Tak se mi to nakonec podařilo rozfungovat. První chyba, která měla za následek, "nulovou" odezvu z lokální sítě, byla způsobena tím, že server OpenVPN nepřidělil klientu žádnou Default Gateway (její hodnota v ipconfig klienta byla prázdná!), přestože v konfiguraci serveru byly direktivy push "route-gateway 1.2.3.1", push "redirect-gateway def1".. deklarovány (viz výpis dále).

Když jsem je vložil do konfiguráku klienta Windows (tedy bez "push"), bránu klient obdržel a ping do lokální sítě již šel.

Nicméně jsem dále zjistil, že ping do firemního subnetu 1.2.3.0/24 sice jde, ale už nikam dál (internet). Řešením bylo povolení IP forvardingu mezi rozhraními, protože podle routovací tabulky je výchozí brána subnetu 1.2.3.1/24 dostupná přes rozhraní eth0 (alespoň to je moje vysvětlení - viz opět výpis dále). Následně jsem direktivy push "route-gateway 1.2.3.1", push "redirect-gateway, vrátil zpět do konfigurace serveru a poté již vše funguje!

pozn.: ne, že bych na zapnutý echo "1" > /proc/sys/net/ipv4/ip_forward předtím zapoměl, ale bohužel jsem si neuvědomil, že server byl mezitím několikrát restartován. :)

Jedinou řekněme "vadou na kráse" je, že klient nedostává Default Gateway subnetu 1.2.3.1/24, jak je deklarováno, ale adresu vpn serveru 1.2.3.16/24. Změnit se mi to žádným nastavením v konfig. souboru nepodařilo, což mi nevadí, vzhledem k tomu, že jsou požadavky předány dál.

viz např. i tady: Dotaz: openvpn jako brige - jak nastavit default gateway?

Přikládám výpisy nastavení - IP adresy z veřejného subnetu jsem změnil v kontextu popisu..

Log OpenVPN serveru a routovací tabulka:

server:/etc/openvpn # openvpn --config  prvni_bridge.conf
server:/etc/openvpn # tail /var/log/openvpn.log
Tue Mar 22 16:30:12 2016 Socket Buffers: R=[212992->131072] S=[212992->131072]
Tue Mar 22 16:30:12 2016 TUN/TAP device tap0 opened
Tue Mar 22 16:30:12 2016 TUN/TAP TX queue length set to 100
Tue Mar 22 16:30:12 2016 GID set to nogroup
Tue Mar 22 16:30:12 2016 UID set to nobody
Tue Mar 22 16:30:12 2016 UDPv4 link local (bound): [undef]
Tue Mar 22 16:30:12 2016 UDPv4 link remote: [undef]
Tue Mar 22 16:30:12 2016 MULTI: multi_init called, r=256 v=256
Tue Mar 22 16:30:12 2016 IFCONFIG POOL: base=1.2.3.17 size=2, ipv6=0
Tue Mar 22 16:30:12 2016 Initialization Sequence Completed
server:/etc/openvpn # route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         1.2.3.1         0.0.0.0         UG    0      0        0 eth0
1.2.3.0         0.0.0.0         255.255.255.0   U     0      0        0 eth0
1.2.3.0         0.0.0.0         255.255.255.0   U     0      0        0 br0
server:/etc/openvpn #

Konfigurace OpenVPN serveru:

dev tap0

proto udp

  server-bridge 1.2.3.16 255.255.255.0 1.2.3.17 1.2.3.18
# secret secret.key
  push "route-gateway 1.2.3.1"
  push "redirect-gateway def1"
  push "dhcp-option DNS 1.2.244.2"

# certifikat certifikacni autority
ca /etc/openvpn/ca.crt

# certifikat serveru
cert /etc/openvpn/server.crt

# klic serveru
key /etc/openvpn/server.key

# parametry pro Diffie-Hellman protokol
dh /etc/openvpn/dh1024.pem

# Verbosity level
verb 3

daemon

# logy serveru
log-append /var/log/openvpn.log

# status serveru
status /var/run/vpn.status 10

# uzivatel pod kterym bezi server
user nobody

# skupina pod kterou bezi server
group nogroup

# udrzuje spojeni nazivu, 10 (ping) a 120 (ping-restart)
keepalive 10 120 

Za případné nepřesnosti ohledně popisu se předem omlouvám a prosím o shovívavost ze strany odborníků.. :)

A za reakce či upozornění na chyby předem děkuji.

[Filip Jirsák]

Jedinou řekněme "vadou na kráse" je, že klient nedostává Default Gateway subnetu 1.2.3.1/24, jak je deklarováno, ale adresu vpn serveru 1.2.3.16/24.

To je ale správně. V routovací tabulce máte záznamy, že nějaká síť je dostupná přes „next hop“. Platí to i pro výchozí bránu (což je jen speciální případ, kdy ta „síť“ je 0.0.0.0/0, tedy celý Internet). „Next hop“ vždy musí být dosažitelný přímo – routování probíhá tak, že se v tabulce najde nejspecifičtější síť a paket se přímo odešle na odpovídající „next hop“. Kdyby „next hop“ mohla být libovolná IP adresa, kterou by bylo nutné znova routovat, snadno by vznikla konfigurace, ze které by nebylo možné určit, kam se má paket poslat.

[Petr_70]

Ano, když nad tím zpětně přemýšlím, tak vám musím dát za pravdu...

Děkuji za upozornění.