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í
×
dnes 17:11 | Komunita

Byl proveden bezpečnostní audit svobodného IMAP a POP3 serveru Dovecot (Wikipedie). Audit byl zaplacen z programu Mozilla Secure Open Source a provedla jej společnost Cure53. Společnost Cure53 byla velice spokojena s kvalitou zdrojových kódu. V závěrečné zprávě (pdf) jsou zmíněny pouze 3 drobné a v upstreamu již opravené bezpečnostní chyby.

Ladislav Hagara | Komentářů: 0
dnes 15:30 | IT novinky

Nadace Raspberry Pi představila na svém blogu Raspberry Pi Compute Module 3 (CM3 a CM3L), tj. zmenšené Raspberry Pi vhodné nejenom pro průmyslové využití. Jedná se o nástupce Raspberry Pi Compute Module (CM1) představeného v dubnu 2014. Nový CM3 vychází z Raspberry Pi 3 a má tedy dvakrát více paměti a desetkrát větší výkon než CM1. Verze CM3L (Lite) je dodávána bez 4 GB eMMC flash paměti. Uživatel si může připojit svou vlastní. Představena byla

… více »
Ladislav Hagara | Komentářů: 0
dnes 01:23 | Nová verze

Oficiálně bylo oznámeno vydání verze 3.0 multiplatformního balíku svobodných kancelářských a grafických aplikací Calligra (Wikipedie). Větev 3 je postavena na KDE Frameworks 5 a Qt 5. Krita se osamostatnila. Z balíku byly dále odstraněny aplikace Author, Brainstorm, Flow a Stage. U Flow a Stage se předpokládá jejich návrat v některé z budoucích verzí Calligry.

Ladislav Hagara | Komentářů: 5
včera 15:25 | Nová verze

Bylo oznámeno vydání první RC (release candidate) verze instalátoru pro Debian 9 s kódovým názvem Stretch. Odloženo bylo sloučení /usr jako výchozí nastavení v debootstrap. Vydán byl také Debian 8.7, tj. sedmá opravná verze Debianu 8 s kódovým názvem Jessie.

Ladislav Hagara | Komentářů: 6
včera 13:37 | Zajímavý projekt

1. ledna byl představen projekt Liri (GitHub). Jedná se o spojení projektů Hawaii, Papyros a původního projektu Liri s cílem vyvíjet operační systém (linuxovou distribuci) a aplikace s moderním designem a funkcemi. Včera byl představen Fluid 0.9.0 a také Vibe 0.9.0. Jedná se o toolkit a knihovnu pro vývoj multiplatformních a responzivních aplikací podporující Material Design (Wikipedie) a volitelně také Microsoft Design Language (designový jazyk Microsoft) [reddit].

Ladislav Hagara | Komentářů: 5
14.1. 00:33 | Zajímavý software

Google na svém blogu věnovaném open source představil knihovnu pro komprimaci a dekomprimaci 3D grafiky s názvem Draco. Knihovna bude využívána například v aplikacích pro virtuální a rozšířenou realitu. Porovnání Draco s gzip na YouTube. Zdrojové kódy Draco jsou k dispozici na GitHubu pod licencí Apache 2.0.

Ladislav Hagara | Komentářů: 5
13.1. 17:27 | IT novinky

V loňském roce proběhla úspěšná kampaň na Indiegogo na podporu GPD Win. Jedná se o malý 5,5 palcový notebook a přenosnou herní konzoli v jednom. Předinstalované Windows 10 lze nahradit Linuxem. V únoru by se na Indiegogo měla objevit kampaň na podporu 7 palcového notebooku GPD Pocket.

Ladislav Hagara | Komentářů: 32
13.1. 02:00 | Nová verze

Po pěti měsících od vydání verze 1.0.0 (zprávička) byla vydána verze 2.0.0 frameworku Kirigami (HIG) pro vytváření uživatelských rozhraní mobilních a konvergentních aplikací nad toolkitem Qt. Pro vyzkoušení je určena aplikace pro Android Kirigami gallery.

Ladislav Hagara | Komentářů: 0
12.1. 23:28 | Zajímavý software

Akční hra Lugaru HD od Wolfire Games (recenze) byla uvolněna jako svobodný software, a to včetně dat (pod licencí Creative Commons Attribution – Share Alike). Linuxový port byl v roce 2010 součástí první akce Humble Indie Bundle a engine byl krátce poté uvolněn pod licencí GNU GPL, což vedlo mj. k portu na AmigaOS. Autor mezitím pracuje na pokračování nazvaném Overgrowth.

Fluttershy, yay! | Komentářů: 0
12.1. 14:49 | Bezpečnostní upozornění

Na serveru Jabb.im bylo zveřejněno vyjádření k úniku dat z Jabbim Archive (pastebin). Dump databáze obsahuje komunikaci uživatelů, jejich IP adresy a logy aplikace od října 2015 do března 2016. Celkově se jedná o 8 GB dat, převažujícím jazykem zpráv je čeština a slovenština. O úniku informoval jako první server Motherboard. Jabbim Archive byla službou volitelnou, dostupnou pouze pro VIP uživatele. Podle provozovatele serveru Jabb.im k

… více »
Michal Makovec | Komentářů: 68
Jak se stavíte k trendu ztenčování přenosných zařízení (smartphony, notebooky)?
 (10%)
 (2%)
 (75%)
 (3%)
 (10%)
Celkem 295 hlasů
 Komentářů: 19, poslední 13.1. 22:02
    Rozcestník
    Reklama

    Dotaz: VN místo VPN

    17.3.2016 10:07 Petr_70 | skóre: 5
    VN místo VPN
    Přečteno: 900×
    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.2016 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.2016 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.2016 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.2016 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.2016 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.2016 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.2016 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.2016 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.2016 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.2016 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.2016 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.2016 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.2016 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.
    Gentoo – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
    17.3.2016 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.2016 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?
    Gentoo – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
    17.3.2016 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.2016 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.2016 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.
    Gentoo – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
    17.3.2016 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.2016 12:00
    Rozbalit Rozbalit vše Re: VN místo VPN
    Debata je o tom, že používá veřejné ip adresy.
    17.3.2016 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.2016 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.2016 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.2016 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.2016 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.2016 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.2016 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.2016 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.2016 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.2016 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?
    Gentoo – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
    17.3.2016 21:45
    Rozbalit Rozbalit vše Re: VN místo VPN
    vole přečti si to celé a uvažuj.
    17.3.2016 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.2016 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.2016 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.2016 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.2016 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.2016 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.2016 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.2016 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.2016 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.
    Gentoo – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
    pavlix avatar 18.3.2016 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. :)
    Gentoo – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
    18.3.2016 07:23
    Rozbalit Rozbalit vše Re: VN místo VPN
    ;-)
    18.3.2016 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.2016 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.2016 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.2016 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.2016 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.2016 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.2016 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.