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 06:00 | Komunita

O víkendu probíhá v Praze na Karlově náměstí 13 konference InstallFest 2020. Na programu je celá řada zajímavých přednášek a workshopů. Přednášky lze sledovat také online. Přehled dění na Twitteru.

Ladislav Hagara | Komentářů: 2
včera 15:22 | Komunita

Daniel Vetter ve zprávě rozeslané do vícero e-mailových konferencí shrnuje situaci kolem financování služeb poskytovaných projektům Freedesktop.org, zvláště spojeným s X.Org (grafické knihovny atp.). Vzhledem k rostoucí popularitě služeb jako CI (Continuous Integration) rostou také náklady na hosting (očekávané výdaje od 75 tisíc dolarů za rok), a proto se hledá sponzor, nebo bude nutné služby v horizontu několika měsíců omezit.

Fluttershy, yay! | Komentářů: 8
včera 14:55 | Zajímavý článek

Knot DNS slaví deset let své existence. Projekt autoritativního DNS serveru Knot DNS patří mezi nejstarší projekty Laboratoří CZ.NIC. Dnes je tomu právě deset let od uložení prvotního prototypu serveru commitem 2da03d5da do veřejného repozitáře Git.

Ladislav Hagara | Komentářů: 0
včera 14:11 | Nová verze

Byla vydána nová verze 2.53.1 svobodného multiplatformního balíku internetových aplikací SeaMonkey (Wikipedie). Přehled novinek v poznámkách k vydání. Hlavní změny jsou pod kapotou. Nová hlavní verze 2.53 používá základ z Firefoxu a Thunderbirdu 60.

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

Budou to tři roky, co Canonical ukončil vývoj mj. grafického prostředí Unity8 a souvisejících projektů jako smartphone s Ubuntu Touch. Toho se ujala komunita UBports a vedle toho vznikl fork Yunit, který již neexistuje, zatímco Unity8 se dostane do Debianu. Nebude se však jmenovat Unity8, nýbrž Lomiri, jak bylo nyní oznámeno.

Fluttershy, yay! | Komentářů: 0
včera 06:00 | Zajímavý projekt

Úrad podpredsedu vlády SR pre investície a informatizáciu vyhlásil výzvu na podporu migrácie na open source a podporu budovania inteligentných miest a regiónov. Dátum uzavretia 1. hodnotiaceho kola je 21.04.2020. Žiadatelia môžu získať od 200 000 do 1 000 000 eur.

atirage21 | Komentářů: 0
včera 05:00 | IT novinky

Otevřená certifikační autorita Let's Encrypt oznámila, že vydala již miliardu certifikátů. Při spuštění veřejné bety Let's Encrypt, v prosinci 2015, bylo celosvětově pomocí HTTPS stahováno cca 40 % webových stránek. Dnes je to 81 %. V USA dokonce 91 %. Podrobnosti na stránce se statistikami. Let's Encrypt má aktuálně 13 zaměstnanců na plný úvazek a roční rozpočet přibližně 3,35 milionu dolarů.

Ladislav Hagara | Komentářů: 8
27.2. 15:33 | Komunita

Fedora stále hledá nové logo. První návrhy byly představeny již před rokem. Designérka Fedory Máirín Duffy ukázala na Twitteru aktuální verzi a žádá uživatele o zpětnou vazbu.

Ladislav Hagara | Komentářů: 22
27.2. 13:55 | Nová verze

Android-x86, tj. port mobilního operačního systému Android na standardní PC s architekturou x86, byl vydán v nové stabilní verze 9.0-r1. Přehled novinek v oficiálním oznámení.

Ladislav Hagara | Komentářů: 19
27.2. 13:11 | Komunita

Mozilla definitivně opouští IRC. Vloni začala hledat novou veřejnou komunikační platformu. Dosud používala IRC (plus interně neveřejný Slack a po nějakou dobu i Mattermost). Nicméně IRC i servery zastarávaly a zejména použitelnost na mobilních zařízeních byla často problematická. Po zvažování a zkoušení různých alternativ se Mozilla přiklonila k otevřenému protokolu Matrix (můžete také znát referenčního klienta Riot) a na konci února IRC vypne.

Ladislav Hagara | Komentářů: 38
Vydržela vám novoroční předsevzetí?
 (11%)
 (6%)
 (3%)
 (81%)
Celkem 211 hlasů
 Komentářů: 0
Rozcestník

IPinIP over DSL (nebo spíš over ATM)

9.2.2011 21:28 | Přečteno: 1027× | linux, počítače a tak vůbec | Výběrový blog | poslední úprava: 10.10.2015 00:20

Nedávný zápisek o IPv6 mi připomněl některé resty. Třeba rozjet IPv6 router. Zprovoznit SixXS za pomoci Aiccu, nebo Gogo6 za pomoci jejich klienta není problém ani za mnoha NATy. Nicméně rozjet 6in4 může být problém. Konkrétně v případě některých druhů ADSL, pokud má člověk přidělenu jen jednu IP adresu. Doma mám několik počítačů, ADSL modem Zyxel Prestige 600 s jedním Ethernetovým portem a Linuxový router s dd-wrt, kam chci IPv6 protunelovat. A navíc provider používá IPoA.

Bohužel SixXS nemůžu použít. Po žádosti o subnet mi bouncnul email, za což je zablokování účtu. To je pochopitelné. Bohužel support SixXS. No podívejte se do Googlu. No a pro Gogo6 není v WRT podpora.

Zlá maškaráda

Moje síť vypadala tak, že ADSL modem prováděl maškarádu pro celou LAN. V LAN byl směrovač, který měl všechny porty v bridge (prostě WiFi bridge). Původně to byl nějaká Ovislink, ale teď jsem upgradoval na zařízení s dd-wrt. Důvod proč je snadné rozjet SixXS nebo Gogo6 v lokální síti za maškarádou je posloupnost protokolů. IP, UDP a pak teprve IPv6 payload. S tunelováním UDP si poradí kdejaká maškaráda naprosto běžně, jinak by uživatel nemohl pokládat DNS dotazy. S takovým IPinIP je to trochu horší. Sled protokolů IP a pak rovnou IPv6 má poněkud omezenější možnosti v důsledku chybějících čísel portů.

Předpokládejme router R0 (onen Zyxel v mém případě) s vnější adresou 1.1.1.190, který provádí maškarádu. Je zřejmé, že na tuto adresu lze z jiné adresy vytvořit jen jeden tunel, protože žádný jiný identifikátor v IP paketu pro rozlišení tunelů nemáme. Předpokládejme, že stroj za maškarádou se pokouší vytvořit tunel s 216.66.80.98. Maškaráda na R0 bude tak chytrá, že IP pakety od této chvíle přicházející z 216.66.80.98 bude přeposílat našemu počítači ve vnitřní síti. Trochu problém bude pokud se tentýž tunel pokusí vytvořit jiný počítač ve vnitřní síti. Jsou dvě možnosti řešení. Buď dostane přednost starý tunel, nebo nový tunel. (Možná by mohl R0 i příchozí pakety duplikovat a posílat oběma počítačům).

Tolik bláznivá teorie. Zapomeňte, že by to nějaká maškaráda dělala. Ono je dobrá vzpomenout si trochu na minulost, asi tak na rok 96/97. Tehdy maškaráda neuměla FTP v aktivním módu. Až časem se pak objevil modul ftp_conntrack. Pokud víte jak FTP funguje, pak asi i odhadnete co onen modul dělal. Přidával pravidla pro překlad adres paketů v závislosti na řídícím spojení. Maškaráda má samozřejmě podporu pro TCP, jak funguje je vzhledem k tomu, že TCP je spojový protokol poměrně jasné. U UDP se vytvářejí pravidla dynamicky v závislosti na odchozích paketech. Stejně tak ICMP ping. Kvízová otázka: dva stroje za maškarádou pingají stejný stroj v Internetu. Co se stane?

Dalším vlastností IPinIP je bezstavovost. Pokud máme IPinIP tunel mezi dvěma směrovači A a R0, pak na A říkáme, že vše co se posílá za R0 se má obalit do ještě jedné IP hlavičky, a vše co přichází z R0 se má jedné hlavičky zbavit. Přidávaná vnější hlavička obsahuje zdrojovou adresu A a cílovou R0, jako protokol vyšší vrstvy je v případě IPv6 hodnota 0x29. Žádné sestavování tunelu. R0 od nás nedostane ani jeden paket, který by se informací o nějakém tunelu týkal. Administrátor proto musí ekvivalentně nastavit R0 sám. Tady aby R0 zbavoval IP hlavičky, pokud je paket od A, a paketům pro A IP hlavičku přidával.

Výše jsem naznačil, jak by bylo možné dostat IPinIP skrze maškarádu. Zapomeňte na to, že by to snad někdo podporoval. Pravidla pro ip.proto=0x29 prostě nejsou. Ještě však není třeba zoufat. Máme R0, což je ADSL modem, a druhý stroj R1 (dd-wrt), kde chceme tunel ukončit. Ze sítě, ADSL - R0 - počítače (včetně R1), vznikne ADSL - R0 - R1 - počítače. Maškarádu tedy přesunu u z R0 na R1.

Mezi R0 a R1 je Ethernet. Jsou na něm jen dvě stanice. Problém je, že na dsl rozhraní R0 musím přiřadit jedinou dostupnou IP adresu, kterou mám od providera. Vzhledem k tomu, že mezi R0 a R1 je v podstatě dvoubodový spoj nabízí se použít NAT 1-1. Pokud je výrobce modemu někdo jiný než Zyxel, pak máte vyhráno. Pokud je to Zyxel, pak máte smůlu, protože ADSL mrdky tohoto výrobce se neobtěžují NATovat veškerý provoz, ale pouze TCP,UDP a ICMP. Na IPinIP zapomeňte. Veselé na tom je, že modem disponuje konfigurovatelným firewallem, takže to svádí k tomu myslet si, že je tam jen nějaké zlé pravidlo. Není, zahazování je zapnuté na tvrdo.

Chci Dosáhnout toho, že cokoliv co se objeví na dsl rozhraní se objeví i na eth rozhraní a naopak. To obvykle dělá bridge.Takovým módem Zyxel disponuje, a dalo by se očekávat, že pak dsl rozhraní žádnou adresu potřebovat nebude a mi zůstane pro R1. Je ale potřeba uvědomit si na jaké vrstvě ADSL modem pracuje. Pokud by pracoval pouze na 1. (fyzické vrstvě), pak jsem vysmátý. Každý určitě zná nutnost klonovat MAC adresy u modemů kabelových televizí v případě výměny síťové karty, nebo její náhrady routerem. Tak to je přesně ono. Onen kabelový modem je prostě jen switch, který má na jednom portu jako fyzickou vrstvu koax kabelové televize a na druhém UTP.

IPoA a směrování

V případě ADSL na tom můžu být hůře. IPoA (RFC1483), a možná i PPPoA. Ono A neznamená ADSL jak by se bylo možné domnívat, ale ATM. Takže s tím bridgem to nebude tak jednoduché. Bylo by hezké, kdyby onen modem fungoval tak, že sloupne Ethernet hlavičku, a zbytek zabalí do ATM paketu. Tenhle směr by byl ještě jednoduchý. Opačný směr je horší. Poskládám paket z ATM a přidám Ethernet hlavičku. Ha, ale jakou. Třeba by šla nastavit napevno. Bohužel ne. Ale pokud se podíváme do RFC1483 zjistíme, že existuje routed a bridged mode. Ty dva módy se liší v tom, že v případě bridged mode je mezi ATM hlavičku a payload vkládána cílová MAC adresa. Pokud váš provider podporuje bridged mode pak máte vyhráno (a vlastně jste nikdy žádný problém neměli, stejně jak uživatelé CATV). V opačném případě se ale už dostáváme také k řešení.

Oživíme naši ukázkovou síť. ADSL - R0 - R1 - počítače. R0 tedy routuje. Výše jsem udělal jeden předpoklad, který se ukázal jako chybný. Adsl rozhraní R0 zas tak moc tu IP adresu nepotřebuje, rozhodně nepotřebuje tu moji jedinou veřejnou, je to totiž P-t-P spoj mezi mnou a providerem. Stejně tak i mezi R0 a R1 P-t-P spoj. Takže co kdybych R0 nenastavil na eth a adsl rozhraní nenastavil žádnou IP adresu, a R1 dostalo 1.1.1.190. Tím je dána teorie. Směrovací tabulky by mohli vypadat následovně (s hvězdičkou jsou adresy rozhraní):
R0
1.1.1.190/32	eth
0.0.0.0/0	dsl

R1 (1.1.1.190)
*1.1.1.190/32	eth
 0.0.0.0/0	via eth
Tolik teorie. Teď limity praxe. Zyxel neumí rozhraní bez adresy. Takže prostě náhodně vybereme adresu a přiřadíme ji našemu dsl rozhraní. (Adsl je sice jako defaultní vždy, ale bez adresy je prostě vypnuté). Taktéž spoji mezi R0 a R1 je třeba přidělit adresu. Tak třeba u R0 10.1.2.1 a u R1 10.1.2.2. Tím pádem můžeme směrovat na R0.
R0
*10.1.2.1/8	eth
 1.1.1.190/32	gw 10.1.2.2
 0.0.0.0/0	dsl

R1
*1.1.1.190/32	eth
*10.1.2.2/8	eth
 0.0.0.0/0	gw 10.1.2.1
Tím máme vyřešen směr k nám. Příchozí paket z adsl je vybalen na R0 z ATM, je rozhodnuto ho směrovat přes 10.1.2.2, takže je doplněna Ethernet hlavička s MAC adresou R1. A to je vítězství, protože tím pádem získáváme paket s cílovou adresou 1.1.1.190 a MAC adresou R1, což stačí pro to, aby ho R1 považoval za svůj.

Ještě je zde problém s opačným směrem. Pokud na R1 nastavíme default gw na 10.1.2.1, tak budeme mít u spojení iniciovaný R1 problém se zdrojovou adresou, která bude 10.1.2.2. Tedy routovat to bude, ale ze samotné R1 si nepingnem. Je třeba provést ještě jednu úpravu. Od providera jsme dostali adresu 1.1.1.190. Nejmenší síť, která má smysl je 1.1.1.190/30, a obsahuje dvě použitelné adresy (1.1.1.190,1.1.1.189). Upravíme tedy masku adresy R1 na /30 a tím pádem můžeme nastavit jako bránu 1.1.1.189. (Není nutnou podmínkou, aby tato adresa byla na druhé straně adsl rozhraní) Dostáváme:
R1
*1.1.1.190/20	eth
*10.1.2.2/8	eth
 0.0.0.0/0	gw 1.1.1.189
Teď mají odchozí pakety z R1 správnou adresu. Ještě to má háček. Podkladní vrstva není žádná sériová linka, ale ethernet. Takže R1 se ptá, jaká je MAC adresa pro 1.1.1.189. Je potřeba ji nastavit ručně. Stačí se podívat jaká je MAC adresa pro 10.1.2.1, nebo si třeba přečíst štítek na modemu. A je vyhráno.

Shrnutí

Nevěřte providerům v tom, kam musíte napsat vaší IP adresu. Stručně nastavení:
R0
dsl=192.168.100.1/24 (any) 
eth=10.1.2.1/8

+ route default dsl (automaticky)
+ route 212.65.211.190 gw 10.1.2.2

R1
ethWAN=1.1.1.190/30
ethWAN=10.1.2.2/8
ethLAN=192.168.1.1/24 (any)

+ arp: MAC 1.1.1.190 stejně jak 10.1.2.1
+ route default gw 1.1.1.189

Úskalí
------
ARP cache
 - R0 si zapamatuje na dlouhou dobu MAC adresu R1
  - kdyz clovek zapomene nastavit

       

Hodnocení: 100 %

        špatnédobré        

Obrázky

IPinIP over DSL (nebo spíš over ATM), obrázek 1

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

20.2.2019 10:06 Nice
Rozbalit Rozbalit vše Re: IPinIP over DSL (nebo spíš over ATM)
The author clearly describe all the parts of the article with good language and information. Looking forward to another article. bullet force
ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.