operacni system se stydi

17.8.2011 18:09 | Přečteno: 2128× | poslední úprava: 17.8.2011 18:08

V firmě máme dvě lokality, v každé z nich je pár privátních sítí, které nejdou navzájem routovat přes internet. Ale protože potřebujeme spojení mezi lokalitami neomezeně, používáme IPsec tunel, a sice OpenSwan. Běží to přímo na linuxových hraničních routerech. V konfiguraci IPsecu je napsáno, že co jde do privátní sítě na druhé straně, ať to zabalí a pošle tunelem. Na jednu síť jsme zapomněli, v konfiguraci IPsecu není, a přesto má konektivitu. Akorát že traceroute ukazuje o dva hopy víc než by měl a jako mezistanice samé hvězdičky.

Přesněji je to takto: požadavek na spojení přijde do hraničního routeru z nějaké VLANy. Projde pravidly iptables, kde není přesměrován ani zahozen, nýbrž akceptován. Teď by měl odejít defaltní routou do internetu a tam se ztratit, protože cílová adresa je 10.x.x.x . Avšak neodejde, jak jsem zjistil tcpdumpem na externím rozhraní routeru. Spojení s privátní adresou v druhé lokalitě se uskuteční jako by se nechumelilo. Nemám pro to jiné vysvětlení, než že se jádro stydí poslat paket směřující do privátního rozsahu do defaltní routy. Místo toho se paket pořád jenom v jádře nějak mrcasí, což ho stojí dvě TTL jednotky, a potom ho dostane IPsec démon a normálně pošle. Celé se to tedy zachová, jako kdyby paket navazující spojení přišel z jiné VLANy než ze které ve skutečnosti přišel. Funguje TCP a ping, nic jiného jsem nezkoušel. Sakra to jsou ty systému vážně tak inteligentní?

       

Komentáře

[Miriam]

První

[Aleš Kapica]

Z tvého popisu problému by člověk nabyl dojmu, že každý správný admin musí žmoulat plyšového méďu pro štěstí, aby mu síť jela jak má. Fuj!

[dizz]

ja zmoulam stary hardware, to pomaha vic.

[Kvakor]

Lépe zní, že je vybaven integrovaným MPM ("Malý Plyšový Medvěd", v originále "Fluffy Teddy Bear")

[R]

Ked mas ten desiatkovy rozsah nastaveny na nejakom interface (aj virtualnom), tak sa paket posle tam.

[FF]

A co třeba dát sem výpis té routovací tabulky, toho iptables a konfig openswanu.....málokdo má dneska křišťálovou kouli.

[Kvakor]

Chělo by vidět routovací tabulky. Osobně si nemyslím, že by se jádro samo o sobě stydělo posílat pakety s adresou 10.x.x.x do vnějšího rozhraní, protože potom by se takto divně chovaly všechny zaNATované sítě v tomto rozsahu. To bude někde v routovacích tabulkách, pravidlech firweallu nebo v samotném kódu tunelu - nevím jak OpenSwan, ale OpenVPN si dělá vlastní i routování, i když záznamy propaguje do routovací tabulky jádra. Kdysi jsem zažil něco podobného, také u paketú s ven neroutovatelnou adresou a nakonec se uzkázalo, že problém byl v masce, která byla nastavená na A sít, i když skutečná maska byla 255.255.255.252. Jen si už nepamatuju o kolik se lišilo TTL bludnýcvh paketů a jak se mi vlastně podařilo tenkrát problém vyvolat.

[Michal Kubeček]

Jen bych upozornil, že výpis směrovací tabulky není to, co ukazuje příkaz route, ale to, co ukazuje 'ip route show' nebo ještě lépe 'ip route show table all' a 'ip rule show'.

Jinak konfigurace FreeS/WAN byla vždycky trochu mystická a po přechodu na ipsec-tools (setkey a racoon) jsem zjistil, že je všechno najednou mnohem průhlednější, když se nemlží vlastními matoucími pojmy a používají se ty standardní. Celkově v používání OpenSWAN na dnešních jádrech nevidím moc smysl.

[Ondrej 'SanTiago' Zajicek]

Ja bych k tomu dodal, ze vsechno je take mnohem pruhlednejsi, pokud se nepouziva IPsec tunnel rezim, ale pouze IPsec transport rezim, podle potreby (napr. pro ucely VPN) kombinovan s obycejnym tunelem (IPIP ci GRE).

[Mrkva]

Jen bych upozornil, že výpis směrovací tabulky není to, co ukazuje příkaz route

Takže mě někdo mystifikuje?

man route
route - show / manipulate the IP routing table

route --help
Usage: route [-nNvee] [-FC] [<AF>]           List kernel routing tables

[Michal Kubeček]

Příkaz route je v Linuxu obsolete od jádra 2.2 (vyšlo v lednu 1999). Takže vám sice v dobré víře ukáže, co si myslí, že je směrovací tabulka, ale ani zdaleka nemůžete spoléhat na to, že vám ukáže všechno, co potřebujete vědět.

[Mrkva]

Zdroj? Koukal jsem do manuálových stránek route, ifconfig, ip. A nikde žádná zmínka. To za prvé. A za druhé ukažte mi jednu běžnou situaci, kdy ip funguje a ifconfig ne.

[Michal Kubeček]

1. Já to třeba v ifconfig(8) mám (a ne, nenapsal jsem si to tam sám). Jinak třeba tady a na spoustě dalších míst. Stačí nezavírat oči.

2. To už jsem udělal mnohokrát, ale pokud si úmyslně zadefinujete "běžné" situace jako ty, kdy ifconfig a route jakž takž stačí, pak to samozřejmě už z principu nepůjde. Pro zajímavost si zkuste porovnat i na zcela "běžném" systému výstup 'route -n' a 'ip route show table all'. Myslíte si, že to, co ukazuje druhý příkaz navíc, je nějaká fikce? Nebo si snad myslíte, že tyto položky nemají vliv na směrování paketů?

[Mrkva]

Ad 1: ack

Ad 2: Tak jasně, ale mě jde o to, že na naprostou většinu použití ifconfig a route naprosto postačuje. Navíc má o mnoho příjemnější syntaxi.

ifc<TAB>eth0 IP/maska up

vs

ip addr add IP/maska dev eth0

[Luboš Doležel (Doli)]

A co když potřebuješ víc adres?

[Mrkva]

ifconfig eth0:n IP/maska

[CEST]

ifconfig eth0:n IP/maska

To je alias, ne dve adresy. ja mam napriklad na jednom(!) rozhrani DHCP a zaroven dalsich par

ip a s eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:13:d3:d2:bb:ef brd ff:ff:ff:ff:ff:ff
    inet 192.168.26.1/32 scope global eth0
    inet 192.168.2.175/24 brd 192.168.2.255 scope global eth0
    inet 192.168.0.175/24 brd 192.168.0.255 scope global eth0
    inet 172.16.34.175/16 brd 172.16.255.255 scope global eth0
    inet6 fe80::213:d3ff:fed2:bbef/64 scope link 
       valid_lft forever preferred_lft forever

A co mi ukaze ifconfig?

ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:13:d3:d2:bb:ef  
          inet addr:192.168.26.1  Bcast:0.0.0.0  Mask:255.255.255.255
          inet6 addr: fe80::213:d3ff:fed2:bbef/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:254104359 errors:0 dropped:5146 overruns:0 frame:0
          TX packets:130721632 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3197090190 (2.9 GiB)  TX bytes:3644918187 (3.3 GiB)
          Interrupt:17 

No a kde je ten zbytek adres? Navic, primarni by mela byt 172.16.34.175 (DHCP) - kde je? To se pak nediv, ze ti pak chodi nejaky packety neznamo odkud a neznamo kam, kdyz vidis jenom pulku nastaveni (resp. mozna jenom 10%).

[Michal Kubeček]

To je alias, ne dve adresy.

On to právě není alias, jen se to tak tváří. IP aliasing jako takový fungoval naposledy v řadě 2.0 (IIRC pouze v řädě 2.0). Problém (jeden z problémů) je právě v tom, že se ifconfig dodnes tváří, jako by tam skutečně existovalo virtuální rozhraní, což dávno není pravda. Navíc další adresy vidí a zobrazuje jen v případě, že mají přiřazený label (což demonstruje váš příklad).

[Michal Kubeček]

Jestli jsem to dobře pochopil, výrazem příjemnější rozumíte kratší. V tom případě se můžete vykašlat na srozumitelnost a psát 'ip a a addr/prefixlen dev eth0' (IIRC spíš musíte, protože ip IIRC zápis s maskou ani nepodporuje).

Z filosofického hlediska má navíc ip jednu zcela zásadní výhodu: odpovídá tomu, co skutečně děláte - přidáváte na rozhraní adresu. Syntaxe ifconfig pořád vychází z toho, co už přes dvanáct let neplatí: že má rozhraní jednu adresu, která se nastavuje. Příznačné je, že pro IPv6 tentýž příkaz najednou realitu bere na vědomí a používá add a remove.

[Ondrej 'SanTiago' Zajicek]

Příznačné je, že pro IPv6 tentýž příkaz najednou realitu bere na vědomí a používá add a remove.

Neni to primarne proto, ze u IPv4 se vseobecne pocitalo s tim, ze rozhrani ma jen jednu adresu (a vic adres je tedy rozsireni nekterych implementaci), tak u IPv6 se standardne pocita s vice adresama?

Treba u toho IPv4 mnoho navazujicich standardu ma s vice adresama problem (treba OSPFv2).

[Michal Kubeček]

1. U IPv6 je skutečně pro plnou funkcionalitu nutné mít možnost přiřadit rozhraní více adres. Ale co se IPv4 týká, nejsem si vědom toho, že by standard nějak přikazoval nebo aspoň doporučoval mít jen jednu.

2. Skutečně je to problém OSPF jako takového? Není to spíš problém konkrétních implementací?

[Ondrej 'SanTiago' Zajicek]

1. nerikam doporucoval, spise implicitne predpokladal.

2. U OSPFv2 standard predpoklada 'jedna linka - jeden prefix'. Konkretni implementace to pripadne (ruznym zpusobem) obchazeji - bud vyberou 'primarni' rozsah, ktery bude reprezentovat linku, a ostatni se pouziji jako stub zaznamy, nebo se tvari, ze to je vic paralelnich linek (kazda s jednim prefixem). AFAIK tyhle workaroundy obecne nejsou standardizovane, takze se muze stat, ze ruzne implementace je budou mit nekompatibilni. U OSPFv3 (pro IPv6) uz jsou linky a prefixy odlisne koncepty.

[Michal Kubeček]

Ad 1: ono se implicitně předpokládalo víc věcí, které už dávno neplatí. Když si třeba přečtete RFC týkající se DNS, zjistíte, že se tam celkem důkladně popisuje, jak to má vypadat, když se jednomu jménu přiřazují dvě adresy, ale v podstatě vůbec se tam nezabývají (dnes o mnoho řádů četnější) možností, že by se naopak několik jmen mohlo překládat na jednu adresu.

[Ondrej 'SanTiago' Zajicek]

U OSPFv2 standard predpoklada 'jedna linka - jeden prefix'.

Tedy s vyjimkou ptp (a ptmp) linek, ktere prefix mit nemusi.

[Mrkva]

Z filosofického hlediska má navíc ip jednu zcela zásadní výhodu: odpovídá tomu, co skutečně děláte - přidáváte na rozhraní adresu. Syntaxe ifconfig pořád vychází z toho, co už přes dvanáct let neplatí: že má rozhraní jednu adresu, která se nastavuje.

Mě jedna adresa na rozhraní zatím skoro vždy stačila (OK, IPv6 je výjimka).

[Michal Kubeček]

To je sice možné, ale nemění to nic na skutečnosti, že počínaje jádrem 2.2 se rozhraní nenastavuje adresa, ale má přiřazen seznam adres, do kterého přidáváte a ze kterého odebíráte.

[melkors]

Vy asi nedelate clustery, ze?

[Ondrej 'SanTiago' Zajicek]

'ip route show table all'

No, to je trochu zavadejici, nebot to vypise i obsah tabulky 'local', ktera ma specifickou funkci a rozhodne se nejedna o beznou routovaci tabulku. Pokud clovek srovna 'route -n' a 'ip route show', tak to na beznych konfiguracich vypise vicemene to same.

[Michal Kubeček]

tabulky 'local', ktera ma specifickou funkci a rozhodne se nejedna o beznou routovaci tabulku

S takovou formulací bych určitě nesouhlasil. Tabulka local (255) je normální tabulka, která se zpracovává úplně stejně jako všechny ostatní. Zvláštní jsou na ní jen dvě věci: za prvé je defaultní tabulkou pro přidávání položek typu local a broadcast (a možná i některých dalších), ale stejně tak je main (254) defaultní pro typ unicast a některé další. Za druhé: automaticky vytvářené pravidlo s prioritou 0 zajišťuje, že se tato tabulka prohledává pro všechny pakety jako první. Jinak ale tato tabulka funguje stejně jako všechny ostatní.

Pokud clovek srovna 'route -n' a 'ip route show', tak to na beznych konfiguracich vypise vicemene to same.

Ne úplně, první příkaz vám IIRC neukáže třeba MTU, metriku nebo preferovanou zdrojovou adresu. Ale především vám ani jeden neukáže dostatek informací na to, abyste mohl určit, jak se bude konkrétní paket směrovat.

[Ondrej 'SanTiago' Zajicek]

S takovou formulací bych určitě nesouhlasil. Tabulka local (255) je normální tabulka, která se zpracovává úplně stejně jako všechny ostatní.

Hlavni rozdil bych videl v tom, ze tabulka 'local' je asi dost linuxove specifikum - pokud si predstavim jakysi genericky koncept IPv4 routovani a pak jeho jednotlive implementace, pak tabulka 'local' (resp. ty polozky typu 'local' a 'broadcast') resi to, co v ostatnich implementacich (ci v tom generickem modelu) je reseno mimo routovaci tabulku jinymi strukturami. Ze v Linuxove implementaci to chytre sloucili do stejnych struktur je sice pekne, ale tezko to potom porovnavat.

[Michal Kubeček]

To sice ano, ale nic to nemění na faktu, že bez znalosti obsahu všech tabulek a směrovacích pravidel nelze říct, jak se daný paket bude směrovat. Což je v podstatě to, co jsem chtěl říct příspěvkem výše.

[xxx]

Imho je tam skutecne neposle. 10.0.0.0/8 neni globalne smerovatelna, takze na takovem rozhrani nema co delat. NAT/Maskarada funguje proto, ze se paketu na vstupu veme, zmenej se mu adresy, a pak uz je korektni paket vlozen, tusim primo do vystupni fronty pozadovaneho rozhrani. (Coz by znamenalo, ze se o jeho smeru vubec nerozhoduje routovaci tabulka. Ale nejsem si zcela jist, je to uz delsi dobu co sem to studoval.)

[Michal Kubeček]

NAT/Maskarada funguje proto, ze se paketu na vstupu veme, zmenej se mu adresy, a pak uz je korektni paket vlozen, tusim primo do vystupni fronty pozadovaneho rozhrani.

To určitě ne, jak by se pak poznalo, které rozhraní to má být (a kdo má být další hop)? Překlad zdrojové adresy (tj. i maškaráda) se provádí až na konci, kdy už je o směrování rozhodnuto. Překlad zdrojové adresy naopak probíhá - aspoň u průchozích paketů - ještě před směrováním, ale paket je pak směrován podle standardních pravidel a tabulek. Trochu složitější je to jen při přepisu cílové adresy (případně značky) u lokálně generovaných paketů, ale i tam v zásadě platí, že bez ohledu na NAT o směrování rozhodují standardní mechanismy.

Na druhou stranu, pokud se používá IPsec (a zvláště v tunelovacím modu), je potřeba dávat pozor ještě na to, kdy se na paket aplikuje SP, která také může zamíchat kartami.

[xxx]

Mate pravdu, staci zadat do Googlu iptables a mrknout se co to naslo za obrazky.

[Michal Kubeček]

Překlad zdrojové adresy naopak probíhá - aspoň u průchozích paketů - ještě před směrováním

Tady samozřejmě mělo být cílové, omlouvám se za nepozornost.

[loki]

Chtelo by to vypis routovaci tabulky, aby se videlo, kam je prirazen ten desitkovy rozsah.

[dan]

ja bych sem nedaval zadny vypis. jen bych si stezoval jak to nejde a jak se v tom nevyznam... to se pak lip radi... Kazdej z nas si vezme sklenenou kouli a budem hadat

[FF]

Já to vidím na chybu ve vadné elektronce ECC83.

[krnoha]

Bohužel není možné, abych zveřejnil topologii firemní sítě. Jak vidím, všeobecný názor je, že jádro neví nic o veřejných a privátních rozsazích. My teď opravíme konfiguraci, aby všechny routy byly definované. Tím ty záhady přestanou být vidět a budeme moci na ně zapomenout.

[Mrkva]

Security through obscurity? :)

[krnoha]

Prošlo to tam na úrovni Ethernetu VLANou, která vede radiospojem mimo routování a málokdo ze správy sítě o tom věděl. Na jedné straně je mi líto, že máme v síti nepořádek. Na druhé straně jsem rád, že jádro linuxu se nestydí a ten plyšovej talisman zatím ještě není tak úplně nezbytný.

[loki]

A vubec nebylo by lepsi toto smerovat do poradny??