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í
×

včera 15:18 | Zajímavý software

CrossOver, komerční produkt založený na Wine, je dnes (23. 5. 2017) dostupný ve slevě. Roční předplatné linuxové verze vyjde s kódem TWENTYONE na $21, resp. $1 v případě IP z chudších zemí. Firma CodeWeavers, která CrossOver vyvíjí, významně přispívá do Wine. Přidaná hodnota CrossOver spočívá v přívětivějším uživatelském rozhraní, integraci do desktopu a podpoře.

Fluttershy, yay! | Komentářů: 22
včera 15:11 | Zajímavý projekt

V únoru loňského roku bylo představeno několik útoků na celou řadu bezdrátových klávesnic a myší s názvem MouseJack. Po více než roce lze chybu opravit, tj. aktualizovat firmware, také z Linuxu. Richardu Hughesovi se podařilo navázat spolupráci se společností Logitech, získat od nich dokumentaci, přesvědčit je, aby firmware poskytovali přímo a ne jako součást .exe souboru, aby mohl být popis začleněn do služby Linux Vendor Firmware Service (LVFS) a aktualizace tak mohla proběhnou přímo z Linuxu pomocí projektu fwupd.

Ladislav Hagara | Komentářů: 2
včera 13:22 | Nová verze

Po roce a půl vydali vývojáři projektu SANE (Scanner Access Now Easy) (Wikipedie) novou verzi 1.0.27 balíku SANE-Backends. Nejnovější verze tohoto balíku pro přístup ke skenerům přináší například významná vylepšení v několika backendech nebo podporu pro více než 30 nových modelů skenerů. Verze 1.0.26 byla přeskočena.

Ladislav Hagara | Komentářů: 0
22.5. 20:55 | Komunita

Od 18. do 21. května proběhla v Saint-Étienne Linux Audio Conference 2017. Na programu byla řada zajímavých přednášek a seminářů. Videozáznamy přednášek lze zhlédnout na YouTube. K dispozici jsou také články a prezentace.

Ladislav Hagara | Komentářů: 0
22.5. 20:44 | IT novinky

Hodnota Bitcoinu, decentralizované kryptoměny, překonala hranici 2 200 dolarů. Za posledních 30 dnů tak vzrostla přibližně o 80 % [reddit].

Ladislav Hagara | Komentářů: 8
22.5. 17:33 | Nová verze

Po 5 měsících vývoje od vydání verze 0.12.0 byla vydána verze 0.13.0 správce balíčků GNU Guix a na něm postavené systémové distribuce GuixSD (Guix System Distribution). Na vývoji se podílelo 83 vývojářů. Přibylo 840 nových balíčků. Jejich aktuální počet je 5 454. Aktualizována byla také dokumentace.

Ladislav Hagara | Komentářů: 1
22.5. 17:22 | Nová verze

Po 5 měsících vývoje a 3 týdnech intenzivního testování byla vydána verze 12 open source systému Nextcloud, forku ownCloudu, umožňujícího provoz vlastního cloudového úložiště. Přehled novinek i s videoukázkami v poznámkách k vydání. Pro vyzkoušení je k dispozici demo.

Ladislav Hagara | Komentářů: 10
22.5. 11:44 | Zajímavý článek

Týden po prvním číslu publikoval Michal Špaček na svých stránkách druhé číslo newsletteru věnovanému bezpečnosti, bezpečnému vývoji převážně webových aplikací a bezpečnosti uživatelů. Věnuje se výpadku Let's Encrypt, únikům dat, bug bounty pro WordPress nebo SQL Injection v Joomla. Zmiňuje také, že Mozilla plánuje z Firefoxu odstranit podporu pro Encrypted Media Extensions (EME) na nešifrovaném HTTP a nadále pro EME vyžadovat HTTPS.

Ladislav Hagara | Komentářů: 0
22.5. 02:00 | Pozvánky

Ve středu 31. května 2017 od 17:00 proběhne v pražské pobočce SUSE Den otevřených dveří v SUSE. Čekají vás přednášky o live kernel patchingu a nástroji SaltStack. Také se dozvíte zajímavé informace o SUSE, openSUSE, a vlastně všech produktech, na kterých lidé ze SUSE pracují.

Ladislav Hagara | Komentářů: 4
22.5. 01:00 | Pozvánky

Czech JBoss User Group srdečně zve na setkání JBUG v Brně, které se koná ve středu 7. června 2017 v prostorách Fakulty informatiky Masarykovy univerzity v místnosti A318 od 18:00. Přednáší Tomáš Livora na téma Fault Tolerance with Hystrix. Více informací na Facebooku a Twitteru #jbugcz.

mjedlick | Komentářů: 0
Chystáte se pořídit CPU AMD Ryzen?
 (6%)
 (32%)
 (1%)
 (8%)
 (44%)
 (8%)
Celkem 605 hlasů
 Komentářů: 62, poslední 19.5. 01:57
    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.