abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    dnes 12:55 | Nová verze

    Byla vydána verze R14.1.2 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5). Přehled novinek v poznámkách k vydání, podrobnosti v seznamu změn.

    JZD | Komentářů: 0
    včera 18:55 | IT novinky

    Dnešním dnem lze již také v Česku nakupovat na Google Store (telefony a sluchátka Google Pixel).

    Ladislav Hagara | Komentářů: 9
    včera 18:33 | IT novinky

    Apple představil (keynote) iPad Pro s čipem Apple M4, předělaný iPad Air ve dvou velikostech a nový Apple Pencil Pro.

    Ladislav Hagara | Komentářů: 1
    včera 17:11 | Nová verze

    Richard Biener oznámil vydání verze 14.1 (14.1.0) kolekce kompilátorů pro různé programovací jazyky GCC (GNU Compiler Collection). Jedná se o první stabilní verzi řady 14. Přehled změn, nových vlastností a oprav a aktualizovaná dokumentace na stránkách projektu. Některé zdrojové kódy, které bylo možné přeložit s předchozími verzemi GCC, bude nutné upravit.

    Ladislav Hagara | Komentářů: 0
    včera 13:44 | Komunita

    Free Software Foundation zveřejnila ocenění Free Software Awards za rok 2023. Vybráni byli Bruno Haible za dlouhodobé příspěvky a správu knihovny Gnulib, nováček Nick Logozzo za front-end Parabolic pro yt-dlp a tým Mission logiciels libres francouzského státu za nasazování svobodného softwaru do praxe.

    Fluttershy, yay! | Komentářů: 0
    včera 13:11 | IT novinky

    Před 10 lety Microsoft dokončil akvizici divize mobilních telefonů společnosti Nokia a pod značkou Microsoft Mobile ji zanedlouho pohřbil.

    Ladislav Hagara | Komentářů: 2
    6.5. 21:33 | Komunita

    Fedora 40 release party v Praze proběhne v pátek 17. května od 18:30 v prostorách společnosti Etnetera Core na adrese Jankovcova 1037/49, Praha 7. Součástí bude program kratších přednášek o novinkách ve Fedoře.

    Ladislav Hagara | Komentářů: 5
    6.5. 21:11 | IT novinky

    Stack Overflow se dohodl s OpenAI o zpřístupnění obsahu Stack Overflow pro vylepšení OpenAI AI modelů.

    Ladislav Hagara | Komentářů: 1
    6.5. 17:55 | Nová verze

    AlmaLinux byl vydán v nové stabilní verzi 9.4 (Mastodon, 𝕏). S kódovým názvem Seafoam Ocelot. Přehled novinek v příspěvku na blogu a v poznámkách k vydání.

    Ladislav Hagara | Komentářů: 0
    6.5. 17:11 | IT novinky

    Před 50 lety, 5. května 1974 v žurnálu IEEE Transactions on Communications, Vint Cerf a Bob Kahn popsali protokol TCP (pdf).

    Ladislav Hagara | Komentářů: 0
    Podle hypotézy Mrtvý Internet mj. tvoří většinu online interakcí boti.
     (63%)
     (7%)
     (14%)
     (16%)
    Celkem 139 hlasů
     Komentářů: 9, poslední včera 22:07
    Rozcestník

    IPinIP over DSL (nebo spíš over ATM)

    9.2.2011 21:28 | Přečteno: 1132× | 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.