abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
včera 21:21 | Nová verze Ladislav Hagara | Komentářů: 0
včera 11:44 | Zajímavý projekt

Na Indiegogo byla spuštěna kampaň na podporu herní mini konzole a multimediálního centra RetroEngine Sigma od Doyodo. Předobjednat ji lze již od 49 dolarů. Požadovaná částka 20 000 dolarů byla překonána již 6 krát. Majitelé mini konzole si budou moci zahrát hry pro Atari VCS 2600, Sega Genesis nebo NES. Předinstalováno bude multimediální centrum Kodi.

Ladislav Hagara | Komentářů: 0
včera 00:10 | Nová verze

Byla vydána verze 4.7 redakčního systému WordPress. Kódové označením Vaughan bylo vybráno na počest americké jazzové zpěvačky Sarah "Sassy" Vaughan. Z novinek lze zmínit například novou výchozí šablonu Twenty Seventeen, náhledy pdf souborů nebo WordPress REST API.

Ladislav Hagara | Komentářů: 1
6.12. 12:00 | Zajímavý projekt

Projekt Termbox umožňuje vyzkoušet si linuxové distribuce Ubuntu, Debian, Fedora, CentOS a Arch Linux ve webovém prohlížeči. Řešení je postaveno na projektu HyperContainer. Podrobnosti v často kladených dotazech (FAQ). Zdrojové kódy jsou k dispozici na GitHubu [reddit].

Ladislav Hagara | Komentářů: 24
6.12. 11:00 | Bezpečnostní upozornění

Byly zveřejněny informace o bezpečnostní chybě CVE-2016-8655 v Linuxu zneužitelné k lokální eskalaci práv. Chyba se dostala do linuxového jádra v srpnu 2011. V upstreamu byla opravena minulý týden [Hacker News].

Ladislav Hagara | Komentářů: 2
5.12. 22:00 | Komunita

Přibližně před měsícem bylo oznámeno, že linuxová distribuce SUSE Linux Enterprise Server (SLES) běží nově také Raspberry Pi 3 (dokumentace). Obraz verze 12 SP2 pro Raspberry Pi 3 je ke stažení zdarma. Pro registrované jsou po dobu jednoho roku zdarma také aktualizace. Dnes bylo oznámeno, že pro Raspberry Pi 3 je k dispozici také nové openSUSE Leap 42.2 (zprávička). K dispozici je hned několik obrazů.

Ladislav Hagara | Komentářů: 6
5.12. 06:00 | Zajímavý software

OMG! Ubuntu! představuje emulátor terminálu Hyper (GitHub) postavený na webových technologiích (HTML, CSS a JavaScript). V diskusi k článku je zmíněn podobný emulátor terminálu Black Screen. Hyper i Black Screen používají framework Electron, stejně jako editor Atom nebo vývojové prostředí Visual Studio Code.

Ladislav Hagara | Komentářů: 50
5.12. 06:00 | Zajímavý článek

I letos vychází řada ajťáckých adventních kalendářů. QEMU Advent Calendar 2016 přináší každý den nový obraz disku pro QEMU. Programátoři se mohou potrápit při řešení úloh z kalendáře Advent of Code 2016. Kalendáře Perl Advent Calendar 2016 a Perl 6 Advent Calendar přinášejí každý den zajímavé informace o programovacím jazyce Perl. Stranou nezůstává ani programovací jazyk Go.

Ladislav Hagara | Komentářů: 10
3.12. 16:24 | Nová verze

Byla vydána Mageia 5.1. Jedná se o první opravné vydání verze 5, jež vyšla v červnu loňského roku (zprávička). Uživatelům verze 5 nepřináší opravné vydání nic nového, samozřejmě pokud pravidelně aktualizují. Vydání obsahuje všechny aktualizace za posledního téměř půldruhého roku. Mageia 5.1 obsahuje LibreOffice 4.4.7, Linux 4.4.32, KDE4 4.14.5 nebo GNOME 3.14.3.

Ladislav Hagara | Komentářů: 17
3.12. 13:42 | Pozvánky

V Praze probíhá konference Internet a Technologie 16.2, volné pokračování jarní konference sdružení CZ.NIC. Konferenci lze sledovat online na YouTube. K dispozici je také archiv předchozích konferencí.

Ladislav Hagara | Komentářů: 0
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (8%)
 (5%)
 (3%)
Celkem 785 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

Dotaz: VN místo VPN

17.3. 10:07 Petr_70 | skóre: 5
VN místo VPN
Přečteno: 891×
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...

Řešení dotazu:


Odpovědi

17.3. 10:24 NN
Rozbalit Rozbalit vše Re: VN místo VPN
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.
17.3. 11:19 Slota
Rozbalit Rozbalit vše Re: VN místo VPN
...a idealne aj s pritupovymi menami a heslami, treba mi rychlo nieco vytlacit :-D
17.3. 11:37 Petr_70 | skóre: 5
Rozbalit Rozbalit vše Re: VN místo VPN
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.
17.3. 12:49 NN
Rozbalit Rozbalit vše Re: VN místo VPN
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.
17.3. 13:18 Petr_70 | skóre: 5
Rozbalit Rozbalit vše Re: VN místo VPN
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.
17.3. 13:36 NN
Rozbalit Rozbalit vše Re: VN místo VPN
Tady prece neni co resit, verejne adresy jsou dostupne z venku. Nic ti nebrani pristupovat na ne primo.
17.3. 14:10 nelson | skóre: 16 | blog: jakesi_cosi
Rozbalit Rozbalit vše Re: VN místo VPN
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.
17.3. 15:09 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: VN místo VPN

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ě.

17.3. 15:44 Petr_70 | skóre: 5
Rozbalit Rozbalit vše Re: VN místo VPN
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
17.3. 15:13 Petr_70 | skóre: 5
Rozbalit Rozbalit vše Re: VN místo VPN
..., 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.
17.3. 17:08 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: VN místo VPN

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
17.3. 10:31
Rozbalit Rozbalit vše Re: VN místo VPN
Můžeme si u vás taky něco vytisknout?
pavlix avatar 17.3. 11:20 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: VN místo VPN
Použití vysokého napětí místo virtual private network doporučuju.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
17.3. 11:41 Petr_70 | skóre: 5
Rozbalit Rozbalit vše Re: VN místo VPN
Použití vysokého napětí místo virtual private network doporučuju.

:)

pavlix avatar 17.3. 12:02 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: VN místo VPN
To ovšem není odpověď na skrytou otázku, co že se myslí tím VN?
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
17.3. 13:03 Petr_70 | skóre: 5
Rozbalit Rozbalit vše Re: VN místo VPN
To ovšem není odpověď na skrytou otázku, co že se myslí tím VN?
VPN = virtual private network

VN = virtual network
17.3. 14:31 Filip Jirsák
Rozbalit Rozbalit vše Re: VN místo VPN
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 avatar 17.3. 21:16 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: VN místo VPN
Jasně, takže si vymýšlíme nové pojmy pro zmatení nepřítele.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
17.3. 11:56 tuxmartin | skóre: 37 | blog: tuxmartin | Jicin
Rozbalit Rozbalit vše Re: VN místo VPN

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.

17.3. 12:00
Rozbalit Rozbalit vše Re: VN místo VPN
Debata je o tom, že používá veřejné ip adresy.
17.3. 12:03
Rozbalit Rozbalit vše Re: VN místo VPN
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.
17.3. 13:21 Petr_70 | skóre: 5
Rozbalit Rozbalit vše Re: VN místo VPN
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... :(
17.3. 14:24 Filip Jirsák
Rozbalit Rozbalit vše Re: VN místo VPN
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í.
17.3. 15:05 Petr_70 | skóre: 5
Rozbalit Rozbalit vše Re: VN místo VPN
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ěď.
17.3. 15:12
Rozbalit Rozbalit vše Re: VN místo VPN
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?
17.3. 15:29 Petr_70 | skóre: 5
Rozbalit Rozbalit vše Re: VN místo VPN
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. :)
17.3. 16:03 Filip Jirsák
Rozbalit Rozbalit vše Re: VN místo VPN
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.
17.3. 17:11 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: VN místo VPN
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".

17.3. 21:36
Rozbalit Rozbalit vše Re: VN místo VPN
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 avatar 17.3. 21:40 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: VN místo VPN
Ono to patrně nefunguje proto, že se jedná o veřejné IP adresy.
Uh?
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
17.3. 21:45
Rozbalit Rozbalit vše Re: VN místo VPN
vole přečti si to celé a uvažuj.
17.3. 21:51 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: VN místo VPN
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ě.
17.3. 22:00
Rozbalit Rozbalit vše Re: VN místo VPN
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.
17.3. 22:04 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: VN místo VPN
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".

17.3. 22:12
Rozbalit Rozbalit vše Re: VN místo VPN
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.
18.3. 06:50 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: VN místo VPN
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.

18.3. 07:16
Rozbalit Rozbalit vše Re: VN místo VPN
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.
17.3. 22:30 Filip Jirsák
Rozbalit Rozbalit vše Re: VN místo VPN
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.
17.3. 22:46
Rozbalit Rozbalit vše Re: VN místo VPN
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 avatar 18.3. 07:27 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: VN místo VPN
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.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
pavlix avatar 18.3. 07:20 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: VN místo VPN
Mně tahle jedna věta bohatě stačila. Máte dost zvláštní smysl pro humor. :)
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
18.3. 07:23
Rozbalit Rozbalit vše Re: VN místo VPN
;-)
18.3. 14:39 izidor
Rozbalit Rozbalit vše Re: VN místo VPN
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.
20.3. 01:57 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: VN místo VPN

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á. :-)

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
20.3. 08:07 Filip Jirsák
Rozbalit Rozbalit vše Re: VN místo VPN
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.
21.3. 17:33 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: VN místo VPN

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.

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
24.3. 17:23 Petr_70 | skóre: 5
Rozbalit Rozbalit vše Re: VN místo VPN
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.
24.3. 18:31 Filip Jirsák
Rozbalit Rozbalit vše Re: VN místo VPN
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.
24.3. 23:00 Petr_70 | skóre: 5
Rozbalit Rozbalit vše Re: VN místo VPN
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í.

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.