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 05:55 | Zajímavý projekt

Dle příspěvku na blogu zaměstnanců CZ.NIC byl spuštěn ostrý provoz služby Honeypot as a Service (HaaS). Zapojit se může kdokoli. Stačí se zaregistrovat a nainstalovat HaaS proxy, která začne příchozí komunikaci z portu 22 (běžně používaného pro SSH) přeposílat na server HaaS, kde honeypot Cowrie (GitHub) simuluje zařízení a zaznamenává provedené příkazy. Získat lze tak zajímavé informace o provedených útocích. K dispozici jsou globální statistiky.

Ladislav Hagara | Komentářů: 0
dnes 04:44 | Komunita

Před týdnem společnost Feral Interactive zabývající se vydáváním počítačových her pro operační systémy macOS a Linux oznámila, že pro macOS a Linux vydají hru Rise of the Tomb Raider. Včera společnost oznámila (YouTube), že pro macOS a Linux vydají také hru Total War Saga: Thrones of Britannia. Verze pro Windows by měla vyjít 19. dubna. Verze pro macOS a Linux krátce na to.

Ladislav Hagara | Komentářů: 0
včera 21:33 | Nová verze

Byla vydána nová major verze 7.10 svobodného systému pro řízení vztahů se zákazníky (CRM) s názvem SuiteCRM (Wikipedie). Jedná se o fork systému SugarCRM (Wikipedie). Zdrojové kódy SuiteCRM jsou k dispozici na GitHubu pod licencí AGPL.

Ladislav Hagara | Komentářů: 0
včera 16:44 | Nová verze

Byla vydána nová verze 0.30 display serveru Mir (Wikipedie) a nová verze 2.31 nástrojů snapd pro práci s balíčky ve formátu snap (Wikipedie). Z novinek Miru vývojáři zdůrazňují vylepšenou podporu Waylandu nebo možnost sestavení a spouštění Miru ve Fedoře. Nová verze snapd umí Mir spouštět jako snap.

Ladislav Hagara | Komentářů: 0
včera 14:00 | Komunita

Na Indiegogo běží kampaň na podporu Sway Hackathonu, tj. pracovního setkání klíčových vývojářů s i3 kompatibilního dlaždicového (tiling) správce oken pro Wayland Sway. Cílová částka 1 500 dolarů byla vybrána již za 9 hodin. Nový cíl 2 000 dolarů byl dosažen záhy. Vývojáři přemýšlejí nad dalšími cíli.

Ladislav Hagara | Komentářů: 1
včera 11:11 | Nasazení Linuxu

Před dvěma týdny se skupina fail0verflow (Blog, Twitter, GitHub) pochlubila, že se jim podařilo dostat Linux na herní konzoli Nintendo Switch. O víkendu bylo Twitteru zveřejněno další video. Povedlo se jim na Nintendo Switch rozchodit KDE Plasmu [reddit].

Ladislav Hagara | Komentářů: 3
včera 05:55 | Komunita

Byla vydána vývojová verze 3.2 softwaru Wine (Wikipedie), tj. softwaru, který vytváří aplikační rozhraní umožňující chod aplikací pro Microsoft Windows také pod GNU/Linuxem. Z novinek lze zdůraznit například podporu HID gamepadů. Aktuální stabilní verze Wine je 3.0, viz verzování. Nejistá je budoucnost testovací větve Wine Staging s řadou experimentálních vlastností. Současní vývojáři na ni již nemají čas. Alexandre Julliard, vedoucí projektu Wine, otevřel v diskusním listu wine-devel diskusi o její budoucnosti.

Ladislav Hagara | Komentářů: 2
18.2. 16:55 | Komunita

Do 22. března se lze přihlásit do dalšího kola programu Outreachy (Wikipedie), jehož cílem je přitáhnout do světa svobodného a otevřeného softwaru lidi ze skupin, jež jsou ve světě svobodného a otevřeného softwaru málo zastoupeny. Za 3 měsíce práce, od 14. května do 14. srpna 2018, v participujících organizacích lze vydělat 5 500 USD.

Ladislav Hagara | Komentářů: 54
17.2. 15:44 | Komunita

Nadace The Document Foundation (TDF) zastřešující vývoj svobodného kancelářského balíku LibreOffice dnes slaví 6 let od svého oficiálního vzniku. Nadace byla představena 28. září 2010. Formálně ale byla založena až 17. února 2012. Poslední lednový den byl vydán LibreOffice 6.0. Dle zveřejněných statistik byl za dva týdny stažen již cca milionkrát.

Ladislav Hagara | Komentářů: 1
17.2. 04:44 | Bezpečnostní upozornění

CSIRT.CZ upozorňuje, že byla vydána nová verze 1.2.3 svobodného routovacího démona Quagga (Wikipedie) přinášející několik bezpečnostních záplat. Při nejhorší variantě může dojít až k ovládnutí běžícího procesu, mezi dalšími možnostmi je únik informací z běžícího procesu nebo odepření služby DoS. Konkrétní zranitelnosti mají následující ID CVE-2018-5378, CVE-2018-5379, CVE-2018-5380 a CVE-2018-5381.

Ladislav Hagara | Komentářů: 0
Který webový vyhledávač používáte nejčastěji?
 (2%)
 (28%)
 (62%)
 (2%)
 (3%)
 (1%)
 (1%)
 (1%)
Celkem 389 hlasů
 Komentářů: 34, poslední 14.2. 18:44
    Rozcestník

    Dotaz: IPsec VPN a routovani

    12.2.2010 07:51 iji | skóre: 29
    IPsec VPN a routovani
    Přečteno: 999×
    Dobre rano,
    resim problem, ktery neni uplne z meho oboru a tak doufam, ze nejaka dobra duse poradi.

    Mejme server s verejnou IP, ktery funguje jako centralni VPN hub pro ostatni pobocky (tedy zapojeni do hvezdy). VPN tunely jsou realizovany pomoci IPSecu (implementace pres Racoon, kernely rady 2.6, rezim tunel). V soucasne chvili funguje komunikace z centraly na pobocku a opacnym smerem. Doted zadny problem.

    Co vsak resim, je komunikace mezi pobockami. Je zrejme, ze komunikace bude muset jit pres centralni VPN koncentrator.
    Zkousel jsem problem resit rucnim pridanim zaznamu do routovaci tabulky na pobockach tak, aby traffic do dalsiho subnetu byl routovan pres VPN hub. Jelikoz vsak Racoon nevytvari vlastni interface a routovaci tabulku si modifikuje pouze interne, nebyl jsem uspesny (routa sice pridana, ale data naprochazela - overeno tcpdumpem). Pouzite konstrukce byly ve tvaru ip route add vzdaleny_sbunet/maska via vnitrni_IP_hubu src lokalni_IP_routeru.

    Je mozne zapojeni do hvezdy a komunikaci pres VPN hub mezi pobockami realizovat samotnym IPSecem nebo je nutny navic jeste GRE tunel mezi centralnim bodem a pobockami (i v pripade rucni konfiguraci bez dynamickeho routovani)?
    Jeste mne napada pouzit SPD k "suplovani" routovani, tj. na kazde pobocce pridat dalsi zaznam mezi subnetem lokalni pobocky do kazde dalsi pobocky pres VPN hub. Je toto realne a systemove?

    Predem dekuji vsem za pomoc.

    Řešení dotazu:


    Odpovědi

    12.2.2010 09:31 NN
    Rozbalit Rozbalit vše Re: IPsec VPN a routovani
    Ja myslim, ze na to jdes dobre. Na pobocce pridam routu do vzdalene site sktz VPN tunel. Nicmene problem vydiv koncentratoru, ktery musi umet odforwardovat ten traffic dal, co se v toto pripadu nestalo. CO jsi zjistil tim tcpdumpem ?

    NN
    12.2.2010 19:52 iji | skóre: 29
    Rozbalit Rozbalit vše Re: IPsec VPN a routovani
    tcpdump na centralnim hubu neukazal nic - ICMP pakety vubec nedorazily, na pobocce (po pridani routy ip route add subnet_dalsi_pobocky/maska via verejna_IP_teto_brany src LAN_adresa_teto_brany) jsem videl ICMP odchazeji z "verejna_IP_teto_brany" na "LAN_adresa_vzdalene_brany_na_pobocce". Dle tcpdumpu tedy koncily "nekde v internetu".

    Problem vidim v routovovani, kdy nejsem schopen traffic pro dalsi pobocku "otocit" do stavajiciho tunelu. A nejrhorsi je, ze nevim, zda to vubec ma reseni bez GRE.

    Update: Na prvni pobocce jsem pridal dalsi SPD pro IPSec, ktera se tykala "subnetu_na_teto_pobocce" a "subnetu_na_dalsi_pobocce" pres "verejnou_IP_centralniho_hubu".
    Bez vysledku. Zde ani ICMP neopoustely tuto branu.

    Pote jsem jeste pridal dalsi SA Racoonu pro "subnetu_na_dalsi_pobocce" a "subnetu_na_teto_pobocce".
    Opet bez vysledku.

    Zacinam byt ponekud zoufaly :(
    12.2.2010 20:06 timeos | skóre: 32
    Rozbalit Rozbalit vše Re: IPsec VPN a routovani

    Podla mojho nazoru su v IPSecovych tuneloch definovane urcite politiky na packety, ktore nimi maju prechadzat. Tie spocivaju napr v tom, ze packet, ktory ma tunelom prejst musi mat zdrojovu a cielovu IP adresu, ktore odpovedaju IP rozsahom oboch VPN stran (alebo proste definovanym konfigurovanym rozsahom oboch stran pri zostavovani spojenia)... teda ak je centrala 10.0.0.0/16 a pobocka je 172.16.1.0/24, tak packet musi mat ako cielovu a zdrojovu adresu iba niektoru z tychto rozsahov... teda ak chcete routovat medzi pobockami (dalsia pobocka 172.16.2.0/24), tak packet automaticky bude mat nejaku adresu inu, a teda nebude vpusteny do tunela medzi prvou pobockou a centralou.

    A ano.. ako pisete, bez GRE si asi neporadite.

    13.2.2010 11:19 iji | skóre: 29
    Rozbalit Rozbalit vše Re: IPsec VPN a routovani
    Tvuj (nevadi, ze opustime vykani?) nazor je spravny. To, ktere pakety se budou sifrovat a posilat pres IPSec, urcuje SPD. Zkousel jsem jej, viz vyse, zmenit, aby SPD na prvni pobocce obsahovalo jak subnet centraly, tak i druhe pobocky pres centralu, ale to IPSecu nelibilo vubec - pakety pro druhou pobocku vubec neopoustely public interface na prvni pobocce.

    GRE jsem jiz kdysi testoval a neni to slozite. Jedinou nevyhodou je nutnost adaptovat firewall konfiguraci, cemuz jsem se puvodne chtel vyhnout. Nic jineho mi vsak asi nezbyde.
    13.2.2010 12:39 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: IPsec VPN a routovani
    Jestli to dobře chápu, rozšířil jste u SP rozsah. Zkuste tam nechat původní a místo toho přidat další SP (na obou stranách). U IPsec se totiž rozsahy u SA a SP porovnávají na rovnost, ne na podmnožinu. Druhou možností je vykašlat se na hvězdicovou topologii a vytvořit přímé tunely "každý s každým".
    13.2.2010 19:29 tomk
    Rozbalit Rozbalit vše Re: IPsec VPN a routovani
    Nevim, jak jsou pobocky a centrala adresovany, ale asi bych pro ipsec vytvoril jednoduche policy, ktere by na pobocce rikalo jen neco jako: 192.168.129.0/24 -> 192.168.0.0/16 na dalsi pobocce: 192.168.130.0/24 -> 192.168.0.0/16 a na centrale to same, ale opacne. Diky tomu budou pobocky encapsulovat veskery provoz na cokoliv ve 192.168.0.0/16 do ipsecu, tim padem to dorazi na centralu, ktera to desifruje a bud odroutuje na lokalni sit (192.168.0.0/24), nebo odesle jinym tunelem dal.

    Tomas
    13.2.2010 19:32 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: IPsec VPN a routovani
    To by mohlo fungovat, ale osobně bych upřednostnil přidání samostatných politik pro jednotlivé rozsahy.
    13.2.2010 20:06 tomk
    Rozbalit Rozbalit vše Re: IPsec VPN a routovani
    Myslim, ze z hlediska ipsecu by to tak bylo koser. Jen prijemnejsi na spravu. Zalezi, kolik tech pobocek je a jak se budou rozsirovat. Pokud bych mel pri kazde zmene stejne upravovat konfiguraci na vsech pobockach, tak bych asi uprednostnil uz tu nejcistejsi variantu s full-meshem ;-)

    Tomas
    13.2.2010 21:59 iji | skóre: 29
    Rozbalit Rozbalit vše Re: IPsec VPN a routovani
    Jsem zde s vysledkem. A predem hned uvedu, ze pozitivnim.

    Reseni, ktere funguje, jsem zcela jiste jiz jednou zkousel. Tehdy vsak bez valneho vysledku (rano moudrejsiho vecera holt plati).

    Mejme centralu "C" (adresni prostor 192.168.1.0/24, verejna IP 1.1.1.1), pobocku "A" (192.168.2.0/24 s verejnou 2.2.2.2) a pobocku "B" (192.168.3.0/24 s verejnou 3.3.3.3).



    Centrala C
    centrala-c:~# cat /etc/ipsec-tools.conf
    #!/usr/sbin/setkey -f
    
    flush;
    spdflush;
    
    
    spdadd 192.168.2.0/24 192.168.1.0/24 any -P in ipsec
    	esp/tunnel/2.2.2.2-1.1.1.1/require;
    spdadd 192.168.1.0/24 192.168.2.0/24 any -P out ipsec
    	esp/tunnel/1.1.1.1-2.2.2.2/require;
    
    spdadd 192.168.3.0/24 192.168.1.0/24 any -P in ipsec
    	esp/tunnel/3.3.3.3-1.1.1.1/require;
    spdadd 192.168.1.0/24 192.168.3.0/24 any -P out ipsec
    	esp/tunnel/1.1.1.1-2.2.2.2/require;
    centrala-c:~# 
    


    centrala-c:~# cat /etc/racoon/racoon.conf
    .
    .
    .
    
    sainfo address 192.168.0.0/16 any address 192.168.2.0/24 any {
    	lifetime time	15 min;
    	pfs_group modp1024;
    	encryption_algorithm rijndael;
    	authentication_algorithm hmac_sha1;
    	compression_algorithm deflate;
    }
    
    sainfo address 192.168.0.0/16 any address 192.168.3.0/24 any {
    	lifetime time	15 min;
    	pfs_group modp1024;
    	encryption_algorithm rijndael;
    	authentication_algorithm hmac_sha1;
    	compression_algorithm deflate;
    }
    centrala-c:~#
    


    Pobocka A
    pobocka-a:~# cat /etc/ipsec-tools.conf
    #!/usr/sbin/setkey -f
    
    flush;
    spdflush;
    
    spdadd 192.168.2.0/24 192.168.2.0/24 any  -P in none; 
    spdadd 192.168.2.0/24 192.168.2.0/24 any  -P out none; 
    
    spdadd 192.168.2.0/24 192.168.0.0/16 any -P out ipsec
    	esp/tunnel/2.2.2.2-1.1.1.1/require;
    spdadd 192.168.0.0/16 192.168.2.0/24 any -P in ipsec
    	esp/tunnel/1.1.1.1-2.2.2.2/require;
    
    pobocka-a:~#
    


    pobocka-a:~# cat /etc/racoon/racoon.conf
    .
    .
    .
    
    sainfo address 192.168.2.0/24 any address 192.168.0.0/16 any {
    	lifetime time	15 min;
    	pfs_group modp1024;
    	encryption_algorithm rijndael;
    	authentication_algorithm hmac_sha1;
    	compression_algorithm deflate;
    }
    pobocka-a:~#
    


    Pak uz jen zbyva na firewallu povolit zadouci komunikaci mezi pobockami. Zapojeni do hvezdy ma nevyhodu, ze komunikace mezi pobockami "vyzira" linku centraly (a to hned dvakrat), ale na oplatku nabizi konfiguraci firewallu pro traffic mezi pobockami na jednom miste - na centrale (na pobockach povolit vsechen provoz z/do tunelu).
    Dekuji vsem za pomoc a preji hezky vecer.
    12.2.2010 20:36 linuxik | skóre: 32 | Milovice
    Rozbalit Rozbalit vše Re: IPsec VPN a routovani
    Ahoj, a nepremyslel jsi o openvpn, povoleni komunikace mezi pobockami vyresis jednim parametrem, routovani je diky tomu, ze se ti udela dalsi tun nebo tap interface taky prehledne a se zapnutou kompresi usetris spoustu prenesenych dat.

    ps. Reci o vetsi robustnosti a bezpecnosti ipsecu patri do rise pohadek.
    13.2.2010 11:32 iji | skóre: 29
    Rozbalit Rozbalit vše Re: IPsec VPN a routovani
    OpenVPN je skvele - jediny TCP/UDP port, vznikne vlastni interface, jednoducha konfigurace. OpenVPN u nas pouzivaji zamestnanci, kteri se pripojuji z domova.

    IPSec mezi koncentratory je pouzit z historickych duvodu. Na prvni pobocce byl pouzit low-end router, ktery umel pouze IPSec a pak jsme si take nechavali cestu pro pripad, ze by se Linuxovy router nahradil Cisco koncentratorem. Nenahradil a ani nenahradi.

    IPSec provozujeme jiz cca dva roky a jedna se o spolehlive reseni, jen ty zacatky byly mnohem tezsi. OpenVPN se naproti tomu rozjede prakticky samo a customizace a hardening jsou hotove za chvili.
    13.2.2010 18:49 pasmen | skóre: 45 | blog: glob | Praha
    Rozbalit Rozbalit vše Re: IPsec VPN a routovani
    Taky používáme OpenVPN pro přístup roadwarriorů. Ovšem pro propojení poboček to není nejlepší, při větším trafficu je oproti IPsecu znatelný overhead jako u každé SSL VPN.
    13.2.2010 21:08 linuxik | skóre: 32 | Milovice
    Rozbalit Rozbalit vše Re: IPsec VPN a routovani
    Myslis tech 70 bitu na kazdy UDP packet oproti prumernych 7.8% procentum overheadu IPSECu? ;-)
    14.2.2010 13:44 pasmen | skóre: 45 | blog: glob | Praha
    Rozbalit Rozbalit vše Re: IPsec VPN a routovani
    No jistě, ale není to jen o nižší propustnosti. OpenVPN pakety musí probublat stackem až na aplikační vrstvu apod. Navíc pokud použijeme hardwarově akcelerované šifrování (např. AES na routerboardu 1000), pak IPsec jasně vede. Toto mám prakticky vyzkoušené, takže protesty odmítám :-)
    14.2.2010 18:32 iji | skóre: 29
    Rozbalit Rozbalit vše Re: IPsec VPN a routovani
    Ciste ze zvedavosti - jak moc vychazi lepe IPSec s vyuzitim AES zadratovaneho v chipu vuci OpenVPN? Na eBay jsem videl hw sifrovaci karty do PCI (tusim od Compaq) za smesne penize. Kvuli uzkym linkam a predimenzovanemu hw zatez od kryptografie nemusim resit, ale do budoucna by se informace mohla hodit.
    14.2.2010 19:15 pasmen | skóre: 45 | blog: glob | Praha
    Rozbalit Rozbalit vše Re: IPsec VPN a routovani
    Tak to už ti teď přesně nepovím. Původně jsme měli pobočky spojené pomocí OpenVPN, zakončení dělali nějaké Celerony 300MHz s asi 512MB RAM. Před přechodem na IPsec (jako routery slouží právě zmíněné RouterBoard 1000) jsem změřil propustnost při downloadu stejného souboru z asi 5 strojů a spolu s tím odezvu při interaktivní práci mezi pobočkami (ssh + rdp). To samé jsem pak udělal po přechodu na IPsec. Výsledky nikde schované nemám, je to přece jen už dva roky. Ale vycházelo to celkem dobře, nejužší místo na trase mělo propustnost 10Mb/s. Při downloadu bylo znát, že to ty Celerony už moc nedávali, interaktivní práce taky pěkně vázla.
    14.2.2010 22:08 linuxik | skóre: 32 | Milovice
    Rozbalit Rozbalit vše Re: IPsec VPN a routovani
    No tak dobre. V pripade, ze bude dnes nekdo pouzivat 300 MHz celeron, bude HW akcelerovany IPsec lepsi. Tak jsem si dal tu praci a nastavil tunel mezi servery pripojenymi do gigbitoveho switche a zkusil kopirovat pres FTP. Bez tunelu 26 MB/s, zatizeni procesoru 0.08 , pres tunel bez komprese 23 MB/s CPU 0.16, s kompresi 24 MB/s CPU 0.23. Testovany stroj HP DL380-G6 1x Xeon E5520 4 core. Kopirovany soubor uz byl komprimovany (nenasel jsem zadny dostatecne velky nekomprimovany), takze se komprese nemohla projevit.
    13.2.2010 19:33 peta
    Rozbalit Rozbalit vše Re: IPsec VPN a routovani
    Ano, je to mozne i bez GRE tunelu, staci nakonfigurovat primo ipsec :). Precti si dukladne manualove stranky pro racoon a setkey, pripadne i neco na tema ipsec. Ale manualove stranky staci, kdyz vis o cem je rec.

    Dokonce je mozne i ridit provoz mezi pobockami pomoci netfilter, zakladni info najdes opet v manualove strance, nektere podrobnosti je nutne vycist ze zdrojaku.
    vencour avatar 13.2.2010 19:40 vencour | skóre: 55 | blog: Tady je Vencourovo | Praha+západní Čechy
    Rozbalit Rozbalit vše Re: IPsec VPN a routovani

    S openNHRP nikdo zkušenost nemá?

    Ty nejhlubší objevy nečekají nutně za příští hvězdou. Jsou uvnitř nás utkány do vláken, která nás spojují, nás všechny.

    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.