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í
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
včera 22:00 | Komunita

Přibližně před měsícem bylo oznámeno, že linuxová distribuce SUSE Linux Enterprise Server (SLES) běží nově také Raspberry Pi 3 (dokumentace). Obraz verze 12 SP2 pro Raspberry Pi 3 je ke stažení zdarma. Pro registrované jsou po dobu jednoho roku zdarma také aktualizace. Dnes bylo oznámeno, že pro Raspberry Pi 3 je k dispozici také nové openSUSE Leap 42.2 (zprávička). K dispozici je hned několik obrazů.

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

OMG! Ubuntu! představuje emulátor terminálu Hyper (GitHub) postavený na webových technologiích (HTML, CSS a JavaScript). V diskusi k článku je zmíněn podobný emulátor terminálu Black Screen. Hyper i Black Screen používají framework Electron, stejně jako editor Atom nebo vývojové prostředí Visual Studio Code.

Ladislav Hagara | Komentářů: 26
včera 06:00 | Zajímavý článek

I letos vychází řada ajťáckých adventních kalendářů. QEMU Advent Calendar 2016 přináší každý den nový obraz disku pro QEMU. Programátoři se mohou potrápit při řešení úloh z kalendáře Advent of Code 2016. Kalendáře Perl Advent Calendar 2016 a Perl 6 Advent Calendar přinášejí každý den zajímavé informace o programovacím jazyce Perl. Stranou nezůstává ani programovací jazyk Go.

Ladislav Hagara | Komentářů: 7
3.12. 16:24 | Nová verze

Byla vydána Mageia 5.1. Jedná se o první opravné vydání verze 5, jež vyšla v červnu loňského roku (zprávička). Uživatelům verze 5 nepřináší opravné vydání nic nového, samozřejmě pokud pravidelně aktualizují. Vydání obsahuje všechny aktualizace za posledního téměř půldruhého roku. Mageia 5.1 obsahuje LibreOffice 4.4.7, Linux 4.4.32, KDE4 4.14.5 nebo GNOME 3.14.3.

Ladislav Hagara | Komentářů: 14
3.12. 13:42 | Pozvánky

V Praze probíhá konference Internet a Technologie 16.2, volné pokračování jarní konference sdružení CZ.NIC. Konferenci lze sledovat online na YouTube. K dispozici je také archiv předchozích konferencí.

Ladislav Hagara | Komentářů: 0
2.12. 22:44 | Komunita

Joinup informuje, že Mnichov používá open source groupware Kolab. V srpnu byl dokončen dvouletý přechod na toto řešení. V provozu je asi 60 000 poštovních schránek. Nejenom Kolabu se věnoval Georg Greve ve své přednášce Open Source: the future for the European institutions (SlideShare) na konferenci DIGITEC 2016, jež proběhla v úterý 29. listopadu v Bruselu. Videozáznam přednášek z hlavního sálu je ke zhlédnutí na Livestreamu.

Ladislav Hagara | Komentářů: 25
2.12. 15:30 | Zajímavý projekt

Společnost Jolla oznámila v příspěvku Case study: Sailfish Watch na svém blogu, že naportovala Sailfish OS na chytré hodinky. Využila a inspirovala se otevřeným operačním systémem pro chytré hodinky AsteroidOS. Použita je knihovna libhybris. Ukázka ovládání hodinek na YouTube.

Ladislav Hagara | Komentářů: 15
2.12. 14:15 | Nová verze

Byla vydána verze 7.1.0 skriptovacího jazyka PHP používaného zejména k vývoji dynamických webových stránek. Jedná se o první stabilní verzi nejnovější větvě 7.1. Přehled novinek v dokumentaci. Podrobnosti v ChangeLogu. K dispozici je také příručka pro přechod z PHP 7.0.x na PHP 7.1.x.

Ladislav Hagara | Komentářů: 5
2.12. 12:55 | Nová verze

Google Chrome 55 byl prohlášen za stabilní. Nejnovější stabilní verze 55.0.2883.75 tohoto webového prohlížeče přináší řadu oprav a vylepšení (YouTube). Opraveno bylo také 36 bezpečnostních chyb. Mariusz Mlynski si například vydělal 22 500 dolarů za 3 nahlášené chyby (Universal XSS in Blink).

Ladislav Hagara | Komentářů: 4
2.12. 11:55 | Pozvánky

Máte rádi svobodný software a hardware nebo se o nich chcete něco dozvědět? Přijďte na 135. sraz spolku OpenAlt, který se bude konat ve čtvrtek 8. prosince od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Sraz bude tentokrát tématický. Bude retro! K vidění budou přístroje jako Psion 5mx nebo Palm Z22. Ze svobodného hardwaru pak Openmoko nebo čtečka WikiReader. Přijďte se i vy pochlubit svými legendami, nebo alespoň na pivo. Moderní hardware má vstup samozřejmě také povolen.

xkucf03 | Komentářů: 1
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (7%)
 (5%)
 (3%)
Celkem 774 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

Dotaz: Problemy s multihomingom

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

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.