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 04:44 | Komunita

Tým Debianu zabývající se reprodukovatelnými sestaveními (Reproducible Builds), tj. kdokoli může nezávisle ověřit, že daný binární .deb balíček vznikl překladem daných zdrojových kódů, oznámil, že 94 % balíčků Debianu lze přeložit a sestavit reprodukovatelně. V únory 2015 to bylo 83 % [reddit].

Ladislav Hagara | Komentářů: 0
včera 11:22 | Komunita

Mozilla.cz informuje, že na blogu Mozilly věnovaném bezpečnosti byly zveřejněny výsledky bezpečnostního auditu služby Firefox Accounts, v českých překladech účet Firefoxu, sloužící hlavně k přihlašování k synchronizaci Firefox Sync. Nalezeno bylo celkem 15 bezpečnostních chyb, z toho jedna byla označena jako kritická a tři jako vážné.

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

Byla vydána první stabilní verze 1.0 svobodného komunikačního softwaru Ring (Wikipedie). Ring, původně SFLphone, je součástí projektu GNU [reddit].

Ladislav Hagara | Komentářů: 2
včera 06:00 | Zajímavý projekt

Warner Skoch na svých stránkách zveřejnil návod (YouTube) na zhotovení kapesní herní konzole MintyPi. Konzole MintyPi je postavena na Raspberry Pi Zero W a RetroPie. Jako obal slouží plechová krabička od mentolek.

Ladislav Hagara | Komentářů: 0
23.7. 02:00 | Nová verze

Byl vydán Debian 9.1, tj. první opravná verze Debianu 9 s kódovým názvem Stretch a Debian 8.9, tj. devátá opravná verze Debianu 8 s kódovým názvem Jessie. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 9 a Debianu 8 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.

Ladislav Hagara | Komentářů: 31
22.7. 15:50 | Zajímavý článek

Nadace The Document Foundation (TDF) zastřešující vývoj svobodného kancelářského balíku LibreOffice zveřejnila čtyřiačtyřicetistránkovou výroční zprávu za rok 2016. K dispozici je ve formátu pdf ve vysokém (21,68 MB) a nízkém (7,1 MB) rozlišení. Zpráva byla vytvořena ve Scribusu.

Ladislav Hagara | Komentářů: 0
22.7. 14:40 | Zajímavý software

Mozilla.cz informuje, že Firefox Focus pro Android, velmi jednoduchý prohlížeč zaměřený na anonymní prohlížení, dosáhl milionu stažení. Firefox Focus blokuje sledující prvky a reklamy a při ukončení automaticky smaže všechna uložená data stránek, historii prohlížení a cookies.

Ladislav Hagara | Komentářů: 39
22.7. 14:20 | Komunita

Vyplněním dotazníku na Formuláře Google lze ovlivnit výběr výchozích aplikací v Ubuntu 18.04 LTS. Podrobnosti v příspěvku Dustina Kirklanda na Ubuntu Insights [reddit].

Ladislav Hagara | Komentářů: 7
21.7. 11:30 | Komunita

Etherpad (Wikipedie), svobodný online webový textový editor umožnující spolupráci v reálném čase, se stal oficiálním projektem organizace Software Freedom Conservancy (Wikipedie). Vývojáři Etherpadu se tak mohou stejně jako vývojáři dalších projektů soustředit pouze na vývoj softwaru a vše kolem zařídí Software Freedom Conservancy. Spuštěna byla instance Etherpadu pad.sfconservancy.org.

Ladislav Hagara | Komentářů: 3
21.7. 10:40 | Zajímavý článek

Lukáš Růžička se v článku Workrave ve Fedoře aneb jak si nevytunelovat karpál na MojeFedora.cz věnuje aplikaci Workrave (Wikipedie) na sledování času stráveného na počítači, která může pomoci vyhnout se negativním účinkům práce s počítačem (RSI, CTS), nebo je alespoň výrazně zmírnit.

Ladislav Hagara | Komentářů: 1
Těžíte nějakou kryptoměnu?
 (4%)
 (3%)
 (21%)
 (72%)
Celkem 67 hlasů
 Komentářů: 2, poslední včera 03:34
    Rozcestník

    Dotaz: VN místo VPN

    17.3.2016 10:07 Petr_70 | skóre: 5
    VN místo VPN
    Přečteno: 923×
    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: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: VN místo VPN
    Použití vysokého napětí místo virtual private network doporučuju.
    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: 54 | 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?
    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: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: VN místo VPN
    Jasně, takže si vymýšlíme nové pojmy pro zmatení nepřítele.
    17.3.2016 11:56 tuxmartin | skóre: 38 | 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: 54 | 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?
    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: 54 | 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.
    pavlix avatar 18.3.2016 07:20 pavlix | skóre: 54 | 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. :)
    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: 44 | 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: 44 | 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.