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

UPSat (Twitter) je první open source nanodružice (CubeSat). Jedná se o společný projekt nadace Libre Space Foundation a University of Patras. Repozitáře projektu jsou k dispozici na GitHubu. Pod Libre Space Foundation patří také projekt SatNOGS (zprávička), projekt globální sítě open source pozemních satelitních stanic, vítězný projekt soutěže The Hackaday Prize 2014. UPSat je součástí mise QB50 (Twitter). ID UPSatu je GR02. GPS přijímač na UPSatu je od české společnosti SkyFox Labs. Součástí mise QB50 je i česká nanodružice VZLUSAT-1 s ID CZ02.

Ladislav Hagara | Komentářů: 3
21.4. 15:00 | Komunita

V diskusním listu Thunderbird planning vývojáři poštovního klienta Thunderbird řeší, zda by nebylo možné budoucí Thunderbird postavit nad webovými technologiemi, tj. nad Electronem, stejně jako například Nylas Mail. Gecko, nad kterým je Thunderbird postaven, se má hodně změnit. V plánu je odstranění vlastností, které Firefox už nepotřebuje, ale Thunderbird je na nich závislý [Hacker News, reddit].

Ladislav Hagara | Komentářů: 79
21.4. 10:22 | Bezpečnostní upozornění

Společnost Oracle vydala čtvrtletní bezpečnostní aktualizaci svých softwarových produktů (CPU, Critical Patch Update). Opraveno bylo celkově 299 bezpečnostních chyb. V Oracle Java SE je například opraveno 8 bezpečnostních chyb. Vzdáleně zneužitelných bez autentizace je 7 z nich. V Oracle MySQL je opraveno 39 bezpečnostních chyb. Vzdáleně zneužitelných bez autentizace je 11 z nich.

Ladislav Hagara | Komentářů: 6
21.4. 10:00 | Pozvánky

V úterý 25. dubna proběhne další Prague Containers Meetup. Přijďte se nechat inspirovat jak zlepšit build/delivery pipeline vašich kontejnerových aplikací.

little-drunk-jesus | Komentářů: 2
20.4. 21:33 | Komunita

Na Launchpadu se objevilo kódové jméno následující verze Ubuntu. Ubuntu 17.10 bude Artful Aardvark (mazaný hrabáč) [OMG! Ubuntu!].

Ladislav Hagara | Komentářů: 9
20.4. 20:11 | Zajímavý software

MojeFedora.cz informuje, že společnost Nylas oznámila vydání verze 2.0 poštovního klienta Nylas Mail (původně Nylas N1), která již plně podporuje Linux. Obchodní model společnosti je tzv. open core. Samotný klient je open source, ale uživatel si musí připlatit za některé pokročilé funkce. V základu se lze připojit k GMailu nebo libovolnému účtu přes IMAP. Podpora Exchange je pouze v placené verzi. Klient je napsaný nad Electronem.

Ladislav Hagara | Komentářů: 12
20.4. 15:55 | Zajímavý článek

České centrum pro investigativní žurnalistiku (ČCIŽ) publikovalo na svých stránkách článek s názvem Je česká státní správa „rukojmím Microsoftu“?. Drtivá většina české veřejné správy je závislá na výrobcích softwarového gigantu Microsoft – a nijak zvlášť jí to nevadí.

Ladislav Hagara | Komentářů: 16
20.4. 02:48 | Nová verze

Google Chrome 58 byl prohlášen za stabilní. Nejnovější stabilní verze 58.0.3029.81 tohoto webového prohlížeče přináší řadu oprav a vylepšení (YouTube). Opraveno bylo 29 bezpečnostních chyb. Mezi nimi i chyba umožňující phishing s unicode doménami.

Ladislav Hagara | Komentářů: 0
19.4. 22:44 | Nová verze

Po šesti týdnech od vydání verze 52.0 byla vydána verze 53.0 webového prohlížeče Mozilla Firefox. Z novinek lze upozornit například na nové kompaktní vzhledy – tmavý z Firefoxu Developer Edition a jeho světlá varianta. Na Linuxu byla ukončena podpora procesorů starších než Pentium 4 a AMD Opteron. Podrobné informace v poznámkách k vydání a na stránce věnované vývojářům. Řešeny jsou také bezpečnostní chyby.

Ladislav Hagara | Komentářů: 11
19.4. 17:44 | IT novinky

Realtimová strategická počítačová hra StarCraft a její rozšíření StarCraft: Brood War jsou ode dneška zdarma. Společnost Blizzard Entertainment chystá remasterovanou verzi (YouTube) a při té příležitosti se rozhodla neremasterovanou verzi aktualizovat a dát ji ode dneška k dispozici zdarma. Hru lze na Linuxu hrát pod Wine.

Ladislav Hagara | Komentářů: 3
Chystáte se pořídit CPU AMD Ryzen?
 (4%)
 (35%)
 (0%)
 (7%)
 (45%)
 (10%)
Celkem 271 hlasů
 Komentářů: 31, poslední 20.4. 21:26
    Rozcestník

    Dotaz: Problemy s multihomingom

    1.10.2010 16:12 timeos | skóre: 32
    Problemy s multihomingom
    Přečteno: 256×

    Zdravim

    riesim divne spravanie sa debiana, ktory aj napriek definovanym pravidlam posiela pakety inak ako ja pozadujem. Mam klasicky priklad. Linux router (debian etch), ktory ma internetovu konektivitu cez dvoch providerov ISP1 (lokalna adresa IP1) a ISP2 (lokalna adresa IP2). Standardne mam default routu na ISP1.

    A teraz ku konfiguracii. Riesim problem ze mam ipsecovy tunel, ktory potrebujem tahat cez ISP2 so zdrojovou adresou IP2 a cielovou adresou VPNDestIP. Problem vsak je, ze sice smerom na ISP2 ta komunikacia ide, ale s adresou IP1, cim sa samozrejme nie je sanca zostavit spojenie. Konfiguracia:

    ip rule:
    0:      from all lookup 255
    32759:  from all fwmark 0x2 lookup table_isp2
    32760:  from all fwmark 0x1 lookup table_isp1
    32764:  from IP1 lookup table_isp1
    32765:  from IP2 lookup table_isp2
    32766:  from all lookup main
    32767:  from all lookup default
    ip ro:
    ISP1_NET dev eth1 scope link src IP1
    ISP2_NET dev eth2 scope link src IP2
    ...
    default via ISP1 dev eth1
    
    ip ro sh table table_isp1:
    ISP1_NET dev eth1 scope link src IP1
    default via ISP1 dev eth1
    
    ip ro sh table table_isp2:
    ISP2_NET dev eth2 scope link src IP2
    default via ISP2 dev eth2
    

    zaroven mam v iptables nasledovne:

    iptables -t mangle -A -d VPNDestIP -j MARK --set-mark 0x2

    Taktiez v konfiguracii ipsec tunela mam presne definovane aka je left ip (IP2) a aka right ip (VPNDestIP). To teda znamena ze pakety by mali vyhoviet jednak ip rule 32759 a teda pre ich smerovanie by sa mala pozerat tabulka table_isp2, alebo keby som pakety nemarkoval, tak by sa mala zafungovat polozka ip rule 32765, ktora pakety so zdrojovou adresou IP2 bude tak ci onak smerovat cez table_isp2. Ale nedeje sa tak a ja netusim preco. Dokonca neviem, akym sposobom by som to mohol nejak nizkourovnovo oddebugovat.

    Teraz to troska skomplikujem (v skutocnosti to take jednoduche nieje) ked napisem, ze tych tunelov je v systeme definovanych viac a ze niektore tunely idu spravne a ine zas nie. Avsak pre vsetky z nich je principialna konfiguracia rovnaka (cielovy VPN endpoint sa markuje cez iptables, a v ipsec.conf je pre kazdy tunel definovany left ip (IP2) aj right ip (VPNDestIPX)). Avsak pre vsetky tunely plati, ze ich zdrojova adresa je IP2.

    Dalsia vec ktora to (mozno) komplikuje je to, ze na ISP2 je navesanych na jednom interfaci (eth2) niekolko IP adries s tym, ze IP2 je podla vypisu ip addr oflagovana ako secondary.

    Mna teda zaujima ci je uvedeny postup konfiguracie spravny, a ak ano, tak ako je mozne, ze sa sice paket na zostavenie tunela posiela spravnym interfacom (eth2) ale s nespravnou zdrojovou IP adresou (IP1) - to ze je to naozaj tak mam overene cez tcpdump -i eth2 host VPNDestIP. Co to teda moze sposobovat? System sluzi zaroven aj ako router, teda z internych sieti sa smerom na ISP1 robi NAT, avsak NAT-ovacie pravidlo je zavesene vyslovene na interfaci eth1 (-t nat -A -o eth1 -j MASQUERADE).

    A este verzie toho, co pouzivam:

    debian etch 4.0, kernel-2.6.18-6-amd64, openswan-2.4.6+dfsg.2-1.1+etch2, iptables-1.3.6.0debian1-5

    Dakujem za akukolvek radu.


    Řešení dotazu:


    Odpovědi

    1.10.2010 21:08 frr | skóre: 32
    Rozbalit Rozbalit vše Re: Problemy s multihomingom
    Jak přesně vypadá konfigurace toho IPSecu? Kde mu říkáte, jakou lokální adresu má tunel použít?

    Ehh... možná trochu o voze a o koze, ale: co použít OpenVPN? Dvě instance démona, každou nakonfigurovanou aby jela přes jinou lokální IP adresu. Ale pokud je Vám třeba IPSec shůry diktován, asi nemáte na vybranou. O IPsec jsem se pokoušel asi 3x (Cisco, BSD, Linux) v průběhu cca 10 let a pokaždé se mi z něho chtělo zvracet - částečně z některých principů, částečně z konkrétní implementace. Zato OpenVPN jela před pár lety na první škrtnutí, a pořád jede, k mé úplné spokojenosti.

    IPSec holýma rukama v Linuxu jsem už dlouho neviděl, takže netuším, jestli pořád "krade pakety ze vzduchu", nebo jestli vytváří pro tunel virtuální rozhraní. OpenVPN to má jasné: vytváří virtuální rozhraní, přes která routuje. A vnější TCP/UDP sockety tunelů obsluhuje standardním způsobem user-space démon - nemá se kde splést, nemá výmluvu.

    BTW, jsou ty běžící IPSecové relace vidět v "netstat -n" resp. "netstat -ln"? Pokud ano, jak vypadají?
    [:wq]
    2.10.2010 10:49 timeos | skóre: 32
    Rozbalit Rozbalit vše Re: Problemy s multihomingom
    Jak přesně vypadá konfigurace toho IPSecu? Kde mu říkáte, jakou lokální adresu má tunel použít?
    Takto (z ipsec.conf):
    conn spojenie
        left=IP2
        leftsubnet=MY_NET
        right=VPNDestIP
        rightsubnet=VPNDestIP_NET
        ...

    Ehh... možná trochu o voze a o koze, ale: co použít OpenVPN? Dvě instance démona, každou nakonfigurovanou aby jela přes jinou lokální IP adresu. Ale pokud je Vám třeba IPSec shůry diktován, asi nemáte na vybranou. O IPsec jsem se pokoušel asi 3x (Cisco, BSD, Linux) v průběhu cca 10 let a pokaždé se mi z něho chtělo zvracet - částečně z některých principů, částečně z konkrétní implementace. Zato OpenVPN jela před pár lety na první škrtnutí, a pořád jede, k mé úplné spokojenosti.
    Presne ako neskvor pisete, to ze je tam prave ipsec ja nedokazem ani v najmensom ovplyvnit. za druhe je jeho konfiguracia dost priehladna a da sa presne definovat aka ma byt IP, aky ma byt nexthop a pod, takze pre situacie, kedy mate viac exitpointov je dokonca toto ziaduce, ze mozte rovno povedat, aka ma byt src IP a teda nemusi to nejak robit system.

    IPSec holýma rukama v Linuxu jsem už dlouho neviděl, takže netuším, jestli pořád "krade pakety ze vzduchu", nebo jestli vytváří pro tunel virtuální rozhraní. OpenVPN to má jasné: vytváří virtuální rozhraní, přes která routuje. A vnější TCP/UDP sockety tunelů obsluhuje standardním způsobem user-space démon - nemá se kde splést, nemá výmluvu.
    Pouzita IPSec implementacia je KLIPS (cez openswan), a pre ziadny tunel sa nejake viditelne rozhranie nevytvara. Overit funkcnost tunela samozrejme problem nieje, dokazem si zistit stav a teda overit, ktory je up a ktory je freeznuty v nejakej faze.

    BTW, jsou ty běžící IPSecové relace vidět v "netstat -n" resp. "netstat -ln"? Pokud ano, jak vypadají?
    Nie, tam ich neuvidite, su to nontcp spojenia takze vo vypise maximalne vidiet iba LISTEN porty pre ipsecove porty 500.
    4.10.2010 11:43 frr | skóre: 32
    Rozbalit Rozbalit vše Re: Problemy s multihomingom

    To je právě ono. Na první pohled do konfigurace to vypadá jednoduše a přehledně. Reálně ale často koukáte jak zjara, proč to nefunguje tak, jak by si člověk intuitivně představoval - a to i v přehlednějších případech, než je ten Váš. Na rozběhnutí IPSecu aby člověk študoval detaily toho protokolu z RFCček a nejlíp i zdrojáky OpenSwanu, aby zjistil, co ta zatracená věc zrovna dělá, jak se tahle konkrétní verze liší od verze před dvěma měsíci apod. Navíc "krade pakety ze vzduchu", takže se neřídí routovací tabulkou, takže si dělá bůhví co, a s interním schematem subsystémů netfilter+iproute2 interaguje bůhví jak. Že se tam dynamicky nahazují, timeoutují, obnovují apod. nějaké managementové relace, takže stavový mechanismus na každém konci, a teď se třeba správně nepotkají proti sobě, to už jsou spíš okrajové problémy ("aspoň se to rozběhlo a chvíli to běhalo, shnilo to až za někou dobu"). Omlouvám se, tyhle moje vzteklé žvásty možná s Vaším konkrétním problémem nesouvisí :-)

    Pokud má protistrana *nějaký* IPsec, prostě konkrétní implementaci v konkrétní verzi, tak máte docela kliku, pokud proti ní Vaše konkrétní implementace aspoň trochu funguje. To je celkový dojem z mých sporadických zkušeností za posledních cca deset let.

    Jo aha, on IPsec pro tunely (ESP tunnel mode) používá svůj vlastní protokol nad IP, číslo 50 (tj. nejede nad TCP ani UDP). Pokud jsou vidět "naslouchající" sockety na UDP portu 500, jsou otevřené pro každou lokální IP adresu extra, nebo vidíte jenom 0.0.0.0:500 ? Tenhle naslouchající UDP port je pro ISAKMP. Čili soudím, že ISAKMP používáte...

    Potažmo pro fungování IPSecu je potřeba ve filtrech po cestě povolit jednak IPSec protokol (číslo protokolu 50) pro holé tunely, jednak protokol UDP port 500 pro ISAKMP. Počítám, že tyhle díry ve filtrech máte správně...

    Ještě jsem si všiml: Vaše pravidlo "iptables -t mangle" spadne implicitně do chainu FORWARD, tj. neuplatní se na lokálně generované pakety, tj. patrně ani na Váš IPSec (ehm: možná záleží, kam se IPSec zaháčkuje, = možná bude rozdíl mezi low-level tunelem a ISAKMP relací). Pokud byste tedy chtěl manglovat IPSec, správně byste měl to pravidlo vsadit do chainu OUTPUT (mangle table), tj. "-A OUTPUT". Viz opět KPTD. Ale souhlasím, že i pokud mangling nezabere, měl by se na to uplatnit "source routing" pomocí "ip rule 32765".

    Pro sledování činnosti IPtables pravidel se dá použít třeba "log target", tj. -J LOG --log-prefix "Ahoj", případně "iptables -L -v", kde sloupec úplně vlevo je počítadlo průchodů pro každé pravidlo.

    Už si přesně nepamatuju podrobnosti konfigurace IPSecu... nicméně mám pocit, že než začnou vůbec chodit užitečné pakety tam a zpátky, navazuje se napřed IPSec tunel, resp. pokud je použit ISAKMP pro řešení klíčů pro holý IPSec tunel, tak ISAKMP si ještě napřed musí navázat svoji komunikaci a dohodnout=spárovat odpovídající "security association"... Tak mě napadá, pokud by byly dva tunely na jeden společný "protější konec", a měly by chodit oba ze stejného lokálního stroje = z jediné lokální instance OpenSwanu, jestli třeba ISAKMP nezjistí, že mluví jenom dva stroje mezi sebou, a začne jednu z obou tras ignorovat. Nebo zjistí, že má jenom jednu destination, tak ani nenahodí druhou ISAKMP relaci z druhé lokální adresy - což může a nemusí znamenat, že pak nebude ani balit traffic do "IP protokolu 50" s druhou lokální adresou. Prostě dynamismus a vrstevnatost IPSecu s ISAKMP mi přijde potenciálně dost netriviální, možná se nepočítalo s "Vaším" případem, že chcete mít na jediném lokálním stroji dva různé "endpointy" (IP adresy lokálního konce tunelu) proti jedinému společnému protějšku...
    Napadá mě: pokud se správně pamatuju, OpenSwan provozuje user-space démona (řeší ISAKMP a možná něco dalšího). Nešlo by spustit ho dvakrát paralelně? Tj. pro každé venkovní rozhraní oddělenou instanci, s konfigurací security associations pouze pro toto rozhraní. Tohle půjde pouze v případě, že OpenSwan(ISAKMP) binduje UDP port 500 pouze na konkrétní lokální IP adrese. Pokud OpenSwan binduje adresu 0.0.0.0 (všechna rozhraní), tak pokus o spuštění druhé instance skončí chybou. A pak ještě záleží na tom, jestli by reálně zafungovalo zřetězení kernelových háčků (netlink?) obou instancí.

    Předpokládám, že IPSec NAT traversal se Vám do toho nemíchá...

    [:wq]
    19.1.2011 16:39 timeos | skóre: 32
    Rozbalit Rozbalit vše Re: Problemy s multihomingom

    po dlhsom case sa vraciam k tomuto vlaknu aby som to nejak uzavrel. v prvom rade dik za vycerpavajucu odpoved, mam vsak taky pocit ze problem je vyrieseny. cele to spocivalo v tom, ze aplikovanie ip rule pravidiel a zmien v routovacich tabulkach sa vykonavalo ako posledne (rc.local, vtedy som nevedel o ziadnom rozumnejsiom sposobe aplikovania nastaveni na debiane). A teda predtym, ako sa pravidla zmeny aplikovali, nastartovali vsetky demony vratane vpn demonov na ipsec a pod a hned sa snazili o pripojenie (ktore bolo v tej chvili neuspesne). Darmo som sa mohol snazit hladat problem v pravidlach, niekedy niektore vpn tunely isli podla nich, ine podla pravidiel smerovania pred aplikaciou zmien.

    A pritom cely ten cas bol problem v smerovacej cache, ktora ostavala persistentna aj po aplikacii zmien v ip rule a v smerovacich tabulkach. To znamena ze zmena nastaveni sa previedla, ale packet bol smerovany stale starym sposobom, lebo siel cez cache ktora tuto info stale drzala :)))) Skoro ma toto zistenie porazilo :)). Ponaucenie na zaver: pokial robite zmeny v smerovani zalozenych na urcitych pravidlach a viacerych branach, VZDY po aplikovani nastaveni premazte smerovaciu cache nasledujucim prikazom:

    ip route flush cache

    Tento ukon je nevyhnutny hlavne vtedy, pokial v pociatocej konfiguracii smerovania tiekli pakety (a hlavne tie, ktore chceme ovplivnit - ako v mojom pripade) a tym sa ta cache vytvorila. Ak by sa jednalo o stav aplikacie zmien pri spustani "networking" init skriptu po starte systemu (teda este pred spustenim akejkolvek sluzby), tak zmazanie cache potrebne podla mojho nazoru nieje. Tu vsak asi treba pouzit spravnu distro, ktora taketo zmeny (ip rule, viacere smerovacie tabulky) dokaze cez networking init skript realizovat (asi najviac sa mi to vidi na redhat like networking init skriptoch).

    19.1.2011 16:53 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Problemy s multihomingom
    A teda predtym, ako sa pravidla zmeny aplikovali, nastartovali vsetky demony vratane vpn demonov na ipsec a pod a hned sa snazili o pripojenie (ktore bolo v tej chvili neuspesne).

    Co si vzpomínám na doby, kdy jsem ještě používal FreeS/WAN, tak tam šlo v konfiguraci nastavit, jestli se má rovnou vyjednat SA nebo ne. U ipsec-tools (což je IMHO na systémech s jádrem 2.6 vhodnější implementace) se to vždy nechává až na první paket odpovídající příslušné SP.

    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.