reklama

IPv6 a řešení záložní konektivity

Re:IPv6 a řešení záložní konektivity
« Odpověď #75 kdy: 16. 01. 2019, 17:22:06 »
A odkaz na patricne RFC, ktere si mam precist, by nebyl?
Pokud vám jde jen o definici pojmu „firewall“, pak je mi líto, ale neznám RFC, které by tento pojem definovalo. Což samozřejmě neznamená, že neexistuje – akorát jsem to nikdy nepotřeboval.

reklama


Vilith

  • *****
  • 587
    • Zobrazit profil
Re:IPv6 a řešení záložní konektivity
« Odpověď #76 kdy: 16. 01. 2019, 17:23:54 »
A odkaz na patricne RFC, ktere si mam precist, by nebyl?
Pokud vám jde jen o definici pojmu „firewall“, pak je mi líto, ale neznám RFC, které by tento pojem definovalo. Což samozřejmě neznamená, že neexistuje – akorát jsem to nikdy nepotřeboval.

Takze nemas autoritativni informaci a jako vzdy jen "kalis vodu" a vydavas sva prani/predstavy za absolutni pravdu

Dekuji

Re:IPv6 a řešení záložní konektivity
« Odpověď #77 kdy: 16. 01. 2019, 22:20:33 »
Takze nemas autoritativni informaci a jako vzdy jen "kalis vodu" a vydavas sva prani/predstavy za absolutni pravdu
Opravte mne, jestli jsem něco přehlédl, ale ani vy jste nedodal odkaz na nějakou autoritativní informaci. Co se týče způsobu vystupování, používáte v této diskusi absolutnější výroky, než já, takže pro vás platí minimálně stejně jako pro mne, že jen kalíte vodu a vydáváte svá přání/představy za absolutní pravdu.

Vilith

  • *****
  • 587
    • Zobrazit profil
Re:IPv6 a řešení záložní konektivity
« Odpověď #78 kdy: 16. 01. 2019, 22:31:39 »
Vsechny neustale opravujes a neustale tvrdis neco, k cemu nemas zadnou autoritativni informaci.

Kazdou zadost o uvedeni autoritativniho zdroje ke svym tvrzenim obracis proti tazateli.

Ja, na rozdil od tebe, sve nazory nikomu nevnucuji, rad bych se neco noveho dozvedel - a to nejlepe od nekoho, kdo tady vystupuje jako ten nejmoudrejsi. Asi chci moc  :(

Re:IPv6 a řešení záložní konektivity
« Odpověď #79 kdy: 16. 01. 2019, 22:54:48 »
Vsechny neustale opravujes a neustale tvrdis neco, k cemu nemas zadnou autoritativni informaci.
To děláte vy. Já rozhodně neopravuju všechny, opravuju jenom ty, kteří píšou nesmysly o věcech, o kterých něco vím.

Kazdou zadost o uvedeni autoritativniho zdroje ke svym tvrzenim obracis proti tazateli.
Opravdu? Byl by příklad? Když jste se ptal na definici termínu „firewall“, PetrM vám nějakou odpověď dal, bylo zbytečné, abych odpovídal také. Vy jste se ptal na ještě autoritativnější definici, já jsem vám popravdě napsal, že tak autoritativní zdroj definice zrovna tohohle termínu neznám. Co je na tom špatně? To jsem si měl nějaký zdroj vymyslet?

Ja, na rozdil od tebe, sve nazory nikomu nevnucuji, rad bych se neco noveho dozvedel
Aha, tak to bych moc rád viděl, v čem přesně spočívá ten rozdíl mezi mým vnucováním názorů a vašim „rád bych se něco nového dozvěděl“. Například věta „ty už nikomu neraď“ je tedy zřejmě vyjádření toho, že byste se rád něco nového dozvěděl, chápu to správně?

Taky by mne zajímalo – když tedy své názory nikomu nevnucujete – jak je možné, že jste se najednou objevil se svou definicí firewallu v diskusi, kde jiní lidé diskutovali o tom, zda NAT má i bezpečnostní funkci. Přičemž ta vaše definice byla nekompatibilní se vším, co před tím v té diskusi padlo, diskusi nijak nepomohla, ba právě naopak, podařilo se vám diskusi unést ke svému tématu.

a to nejlepe od nekoho, kdo tady vystupuje jako ten nejmoudrejsi
No to jste se ale trochu zacyklil, když se něco chcete dozvědět sám od sebe.

reklama


Re:IPv6 a řešení záložní konektivity
« Odpověď #80 kdy: 16. 01. 2019, 23:12:44 »
Ale když tak trváte na nějaké autoritativní definici, i to pro vás umím najít: RFC 2979 – Behavior of and Requirements for Internet Firewalls.

PetrM

Re:IPv6 a řešení záložní konektivity
« Odpověď #81 kdy: 17. 01. 2019, 07:29:19 »
@Vilith:

Díky za definici z toho RFC2467. Ukážu ti kouzlo.

Existuje terminus technicus "access control", což znamená "řízení přístupu" nebo "přístupová práva". "Access control policy" znamená "pravidla přístupových práv"

V RFC je "A device or group of devices that enforces an access control policy between networks." v překladu "Zařízení nebo skupina zařízení, která vynucuje pravidla řízení přístupu mezi sítěmi". 

Jenomže on to někdo pěkně pohnojil při přebírání na tu wikipedii, parafrázoval to jako "... a firewall is a network security system that monitors and controls incoming and outgoing network traffic...", což znamená "... firewall je bezpečnostní síťový systém, který monitoruje a řídí příchozí a odchozí síťový provoz..". Najednou se z "access control policy" (podst. jméno) stalo prostý "control"(sloveso) a místo vynucování pravidel pro přístup do sítě řídí provoz. A význam definice se posouvá někam úplně jinam.

No a nějaký patla to přeložil do CZ verze. Jako "... je síťové zařízení, které slouží k řízení a zabezpečování síťového provozu mezi sítěmi ..." - řízení (který je tady definitivně jako sloveso, navíc zdůrazněno první pozicí) tam podle původní definice není, zato mu chybí "pravidla přístupových práv".

 A další matla tomu věří jak katolík papežovi (= nekriticky, ani nad tím nepřemýšlí). Hrál jsi vůbec někdy ve školce "tichou poštu"?

Vilith

  • *****
  • 587
    • Zobrazit profil
Re:IPv6 a řešení záložní konektivity
« Odpověď #82 kdy: 17. 01. 2019, 07:35:39 »
Takze podle vas, pokud na Cisco routeru vydefinuji napr.
Kód: [Vybrat]
ip access-list extended Net128_INBOUND
permit icmp  10.203.128.0 0.0.0.255 host 10.203.129.254 echo-request
deny icmp 10.203.128.0 0.0.0.255 10.203.129.0 0.0.0.255 echo-request
permit ip 10.203.128.0 0.0.0.255 any
permit udp host 0.0.0.0 host 255.255.255.255

tak se z neho stane firewall?

PetrM

Re:IPv6 a řešení záložní konektivity
« Odpověď #83 kdy: 17. 01. 2019, 08:40:10 »
Takze podle vas, pokud na Cisco routeru vydefinuji napr.
Kód: [Vybrat]
ip access-list extended Net128_INBOUND
permit icmp  10.203.128.0 0.0.0.255 host 10.203.129.254 echo-request
deny icmp 10.203.128.0 0.0.0.255 10.203.129.0 0.0.0.255 echo-request
permit ip 10.203.128.0 0.0.0.255 any
permit udp host 0.0.0.0 host 255.255.255.255

tak se z neho stane firewall?

Na zařízení aktivuješ funkcionalitu "firewall". Jak výrobce / obchodník to zařízení nazve je věc matketingu, může tomu říkat klidně InternetBox nebo třeba router.

Vilith

  • *****
  • 587
    • Zobrazit profil
Re:IPv6 a řešení záložní konektivity
« Odpověď #84 kdy: 17. 01. 2019, 08:42:37 »
Takze podle vas, pokud na Cisco routeru vydefinuji napr.
Kód: [Vybrat]
ip access-list extended Net128_INBOUND
permit icmp  10.203.128.0 0.0.0.255 host 10.203.129.254 echo-request
deny icmp 10.203.128.0 0.0.0.255 10.203.129.0 0.0.0.255 echo-request
permit ip 10.203.128.0 0.0.0.255 any
permit udp host 0.0.0.0 host 255.255.255.255

tak se z neho stane firewall?

Na zařízení aktivuješ funkcionalitu "firewall". Jak výrobce / obchodník to zařízení nazve je věc matketingu, může tomu říkat klidně InternetBox nebo třeba router.

Na trohle nemam silu a naladu...

Router je firewall.

Prc

Re:IPv6 a řešení záložní konektivity
« Odpověď #85 kdy: 17. 01. 2019, 08:51:05 »
Router je firewall.

Tzv. důkaz úporným tvrzením.  ;D ;D ;D

PetrM

Re:IPv6 a řešení záložní konektivity
« Odpověď #86 kdy: 17. 01. 2019, 08:54:44 »
Router je firewall.

Sešlápl jsem brzdový pedál a auto zastavilo. To znamená, že auto je brzda

Tzv. důkaz úporným tvrzením.  ;D ;D ;D

+100

M.

Re:IPv6 a řešení záložní konektivity
« Odpověď #87 kdy: 17. 01. 2019, 16:18:09 »
Vidím, ž o hledně odporných termitů a jejich významů se to tu probralo důkladně. :-)
Bylo také něco k původnímu dotazu - jaké routery a jak to umí řešit? Případně jaké typy NATů pro IPv6 podporují a co přes ně ne/funguje, pokud používají tuto odpornost?

PetrM

Re:IPv6 a řešení záložní konektivity
« Odpověď #88 kdy: 17. 01. 2019, 18:43:13 »
Vidím, ž o hledně odporných termitů a jejich významů se to tu probralo důkladně. :-)
Bylo také něco k původnímu dotazu - jaké routery a jak to umí řešit? Případně jaké typy NATů pro IPv6 podporují a co přes ně ne/funguje, pokud používají tuto odpornost?

NAT na IPv6 je zbytečná komplikace. Zařízení má několik IPv6 adres, není problém mu propagovat pomocí RA nebo DHCP několik veřejných prefixů. IP stack zkusí obě možnosti a vybere tu lepší. Takže normálně se ti zátěž samovolně rozloží na dvě linky (když už to platíš, tak proč nevyužívat obě?) a při výpadku ti pak jenom klesne rychlost. Jenom spadnou spojení přes tu vypadenou, ale IP stack je naváže automaticky přes druhou linku.

Druhá možnost je, pokud máš třeba optiku a jako zálohu mikrovlnu, to koordinovat s ISPíkem tak, aby na jeho gateway bylo přes rádio o jeden hop víc. Router si najde kratší cestu (optiku) a při přerušení lajny pošle traffic delší a pomalejší cestou. To je vlastnost IP protokolu.

Pokud jde o zařízení, druhou možnost jsem nezkoušel, tu první mám odzkoušenou bezproblémově na Turrisu 1.0 (1x tunel /48 od HE po WiFi, x1 nativní IPv6 /56 po VDSL). Takže teoreticky jakýkoliv železo se třema nezávislýma portama (nebo možností poslat si to ze swtche po VLANě) + OpenWRT nebo TurrisOS (tam by to skončilo Omnií). Jak jsou na tom jiný stroje netuším.

Re:IPv6 a řešení záložní konektivity
« Odpověď #89 kdy: 17. 01. 2019, 23:57:06 »
NAT na IPv6 je zbytečná komplikace. Zařízení má několik IPv6 adres, není problém mu propagovat pomocí RA nebo DHCP několik veřejných prefixů. IP stack zkusí obě možnosti a vybere tu lepší. Takže normálně se ti zátěž samovolně rozloží na dvě linky (když už to platíš, tak proč nevyužívat obě?) a při výpadku ti pak jenom klesne rychlost. Jenom spadnou spojení přes tu vypadenou, ale IP stack je naváže automaticky přes druhou linku.
Aby se IP stack pokusil spojit přes druhou linku, musí dostat od routeru informaci, že daný prefix je nadále nefunkční. Pokud ji nedostane, bude posílat data stále ze stejné adresy a tedy budou putovat stejným směrem do černé díry. Ani po timeoutu spojení nedojde k pokusu o navázání z druhé adresy, protože volba zdrojové adresy je deterministická.

Druhá možnost je, pokud máš třeba optiku a jako zálohu mikrovlnu, to koordinovat s ISPíkem tak, aby na jeho gateway bylo přes rádio o jeden hop víc. Router si najde kratší cestu (optiku) a při přerušení lajny pošle traffic delší a pomalejší cestou. To je vlastnost IP protokolu.
Tohle by platilo při zálohování spoje k témuž ISP, nikoli však v případě multihomingu. Pokud má router předělený prefix A od ISP A a prefix B od ISP B a oba prefixy nabízí klientům ve vnitřní síti, pak je volba ISP závislá pouze na tom, kterou zdrojovou adresu klient ve vnitřní síti zvolí, router musí zdrojovou adresu ctít a podle ní zvolit správného ISP. Jinak by to nemělo fungovat, protože ISP by měli implementovat BCP 38 a tedy nepropouštět do internetu provoz z cizích adres.

Pokud jde o zařízení, druhou možnost jsem nezkoušel, tu první mám odzkoušenou bezproblémově na Turrisu 1.0 (1x tunel /48 od HE po WiFi, x1 nativní IPv6 /56 po VDSL). Takže teoreticky jakýkoliv železo se třema nezávislýma portama (nebo možností poslat si to ze swtche po VLANě) + OpenWRT nebo TurrisOS (tam by to skončilo Omnií). Jak jsou na tom jiný stroje netuším.
OpenWRT je skutečně asi nejdál v tom, jak by se domácí router pro IPv6 měl chovat, řeší automaticky policy routing i dynamické ohlašování prefixů.

 

reklama