Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: Whocares 21. 02. 2015, 22:27:37
-
Ahoj,
dneska jsem si rozchodil na domácí síti s Mikrotik routerem nativiní IPv6 přes ADSL od T-Mobilu. Všechno funguje pěkně, akorát si moc nevím rady s pravidly na firewallu a potřeboval bych s nimi pomoci. Jedná se o domácí síť, klientům na interfacu LAN_WLAN věřím, ti si mohou posílat co chtějí kam chtějí. Z internetu (interface adsl) nepotřebuju mít přístupné žádné služby na domácí síti a krom trochu ICMPv6 chci všechno zahazovat. Jiné interfacy na tom Mikrotiku nemám. Vytvořil jsem si podle inspirace na netu následující konfiguraci a nejsem si jist, jestli je tam pokryto vše... Budete někdo prosím tak hodný a hodíte na to očko?
Díky moc!
add chain=input limit=100,5 protocol=icmpv6
add action=drop chain=input protocol=icmpv6
add chain=forward limit=100,5 protocol=icmpv6
add action=drop chain=forward protocol=icmpv6
add chain=input connection-state=established
add chain=input connection-state=related
add chain=input dst-port=546 in-interface=adsl protocol=udp
add action=drop chain=input in-interface=adsl
add chain=forward connection-state=established
add chain=forward connection-state=related
add action=drop chain=forward in-interface=adsl
add action=drop chain=input in-interface=adsl
-
Vypadá to dobře, akorát nerozumím tomu portu 546. Opravdu IPv6 nastavuješ pomocí DHCPv6?
-
Díky za reakci! Ten port 546 jsem pravda dogooglil, protože Mikrotik nedostával od T-Mobilu rozsah,což tohle spravilo..
-
Díky za reakci! Ten port 546 jsem pravda dogooglil, protože Mikrotik nedostával od T-Mobilu rozsah,což tohle spravilo..
Hm, je to možný, že to tak T-mobile má. Běžnější je použití router solicitation, který běží přes icmp6 ( http://wiki.mikrotik.com/wiki/Manual:IPv6/ND#Stateless_address_autoconfiguration ).
Pokud T-mobile autokonfiguraci nepodporuje, tak nevím, jestli by to nechtělo ten port ještě nějak omezit, aby ti na něj nemohl posílat kdokoli cokoli. To teď z hlavy nevím, jak by se dalo udělat, třeba poradí někdo jinej. Pokud by autokonfiguraci podporoval a nepoužíváš jejich DNS, tak bych rozjel radši autokonfiguraci, je to přinejmenším robustnější řešení.
Teď ještě jak na to koukám, nevidím tam povolení odchozích paketů. To asi chceš, ne? ;)
-
Díky za reakci! Ten port 546 jsem pravda dogooglil, protože Mikrotik nedostával od T-Mobilu rozsah,což tohle spravilo..
Hm, je to možný, že to tak T-mobile má. Běžnější je použití router solicitation, který běží přes icmp6 ( http://wiki.mikrotik.com/wiki/Manual:IPv6/ND#Stateless_address_autoconfiguration ).
Vůbec nevíte o čem mluvíte. DHCPv6 je dnes jediný standardizovaný protokol umožňující autokonfiguraci veřejných IPv6 adres v LAN (viz RFC 3769). Nechcete přeci připojit jen ten router, nebo snad nedejbože zavádět NAT?
-
Vůbec nevíte o čem mluvíte. DHCPv6 je dnes jediný standardizovaný protokol umožňující autokonfiguraci veřejných IPv6 adres v LAN (viz RFC 3769). Nechcete přeci připojit jen ten router, nebo snad nedejbože zavádět NAT?
Především nechci, aby se mi adresy strojů v síti měnily jakkoli se ISP zachce. Chci, aby mi ISP řekl, že můj rozsah je XYZ/64 a na svém routeru si chci nastavit normální router solicitation. Dynamické nastavování adres přes DHCP je zlozvyk z v4 a nevidím důvod, proč by se měl tahat do v6.
Největší přínos v6 je v tom, že na libovolné ledničce nebo dveřnímu pantu můžu přidělit globálně dosažitelnou adresu a přímo se na ni připojit odkudkoli z celého světa. Pokud o tuhle možnost kvůli dynamickým adresám přijdu, nevím, k čemu by mi šestka byla dobrá (kromě možnosti připojit se na *statické* adresy v jiné síti).
-
Vůbec nevíte o čem mluvíte. DHCPv6 je dnes jediný standardizovaný protokol umožňující autokonfiguraci veřejných IPv6 adres v LAN (viz RFC 3769). Nechcete přeci připojit jen ten router, nebo snad nedejbože zavádět NAT?
Především nechci, aby se mi adresy strojů v síti měnily jakkoli se ISP zachce. Chci, aby mi ISP řekl, že můj rozsah je XYZ/64 a na svém routeru si chci nastavit normální router solicitation. Dynamické nastavování adres přes DHCP je zlozvyk z v4 a nevidím důvod, proč by se měl tahat do v6.
Největší přínos v6 je v tom, že na libovolné ledničce nebo dveřnímu pantu můžu přidělit globálně dosažitelnou adresu a přímo se na ni připojit odkudkoli z celého světa. Pokud o tuhle možnost kvůli dynamickým adresám přijdu, nevím, k čemu by mi šestka byla dobrá (kromě možnosti připojit se na *statické* adresy v jiné síti).
Evidentně nevíte jak to chodí ve světě velkých ISP. Ti trvají na autokonfiguraci (i když běžně přidělují stále stejné adresy a to je to co ve skutečnosti potřebujete, nikoliv statickou konfiguraci!), protože každý zákazník který si cokoliv nastavuje manuálně je potenciální zdroj problémů které je třeba draze řešit (je potřeba větší callcentrum nebo helpdesk). Je potřeba aby zákazník zapojil koupenou krabičku (router) a ta okamžitě fungovala bez jakéhokoliv donastavování. Berte nebo nechte být, ale umožňovat zrovna vám s DSL přípojkou za pár korun nějaké speciální nastavování je nereálné.
-
Evidentně nevíte jak to chodí ve světě velkých ISP.
To nevím a ani jsem o tom nic netvrdil. Řekl jsem, že pokud T-mobile statické nastavení adres v lokální síti umožňuje, tak bych ho využil raději než dhcp.
Je potřeba aby zákazník zapojil koupenou krabičku (router) a ta okamžitě fungovala bez jakéhokoliv donastavování. Berte nebo nechte být, ale umožňovat zrovna vám s DSL přípojkou za pár korun nějaké speciální nastavování je nereálné.
Zajímavé je, že ve smlouvě statické v4 IP adresy často bývají uvedeny. Nechápu, jaký by měl být rozdíl v tom, kdyby tam měl být v6 rozsah. DHCPv6 samozřejmě pro BFU v síti může běžet, ale z toho nijak neplyne, že ho musím používat. Tím spíš, pokud
běžně přidělují stále stejné adresy
Takže tím bych uzavřel diskusi nad tím, čemu nerozumím a co vůbec netuším, protože to myslím tazatele ani nikoho jiného moc nezajímá.
-
Pokud T-mobile autokonfiguraci nepodporuje, tak nevím, jestli by to nechtělo ten port ještě nějak omezit, aby ti na něj nemohl posílat kdokoli cokoli. To teď z hlavy nevím, jak by se dalo udělat, třeba poradí někdo jinej. Pokud by autokonfiguraci podporoval a nepoužíváš jejich DNS, tak bych rozjel radši autokonfiguraci, je to přinejmenším robustnější řešení.
Teď ještě jak na to koukám, nevidím tam povolení odchozích paketů. To asi chceš, ne? ;)
Tak to omezení jsem udělal tak, že jsem tam přidal ještě src-address=fe80::/64, čímž by se to mělo vyřešit,ne?
Ještě jsem našel jednu konfiguraci, se kterou to taky funguje pěkně a přijde mi trochu přehlednější.
add chain=input comment="Router - Allow IPv6 ICMP" protocol=icmpv6
add chain=input comment="Router - Accept established connections" connection-state=established
add chain=input comment="Router - Accept related connections" connection-state=related
add action=drop chain=input comment="Router - Drop invalid connections" connection-state=invalid
add chain=input comment="Router- UDP" dst-port=546 protocol=udp src-address=fe80::/64
add chain=input comment="Router - From our LAN" in-interface=LAN_WLAN
add action=drop chain=input comment="Router - Drop other traffic"
add action=drop chain=forward comment="LAN - Drop invalid Connections" connection-state=invalid
add chain=forward comment="LAN - Accept ICMPv6 " protocol=icmpv6
add chain=forward comment="LAN - Accept established Connections" connection-state=established
add chain=forward comment="LAN - Accept related connections" connection-state=related
add chain=forward comment="LAN - Internal traffic" in-interface=LAN_WLAN
add action=log chain=forward comment="LAN - Log everything else" log-prefix="Log IPv6"
add action=drop chain=forward comment="LAN - Drop everything else" connection-state=new in-interface=adsl
-
Tak to omezení jsem udělal tak, že jsem tam přidal ještě src-address=fe80::/64, čímž by se to mělo vyřešit,ne?
To prave z hlavy nevim, odkud tam ty packety putuji. Pokud je to vzdycky po link-local, tak by to takhle bylo asi ok.
Ještě jsem našel jednu konfiguraci, se kterou to taky funguje pěkně a přijde mi trochu přehlednější.
Jo. Už tam máš i to propouštění packetů zevnitř, takže myslím, že je to cajk.
-
Nechal jsem si ty packety logovat a vypadá to, že jsou fakt jen z link-local, i když to resetnu, tak ten rozsah znovu dostane.
Tak diky moc za pomoc!
-
Zdravim
Par poznamek k firewallu:
# add chain=input action=accept in-interface=LAN_WLAN # s routerem budes asi z vnitrni site chtit komunikovat.
add chain=input comment="Router - Allow IPv6 ICMP" protocol=icmpv6
add chain=input comment="Router - Accept established connections" connection-state=established
add chain=input comment="Router - Accept related connections" connection-state=related
add chain=input action=drop comment="Router - Drop invalid connections" connection-state=invalid # toto pravidlo je splneno poslednim pravidlem, odstranit, pokud te nezajima counter.
add chain=input comment="Router- UDP" dst-port=546 protocol=udp src-address=fe80::/64
add chain=input comment="Router - From our LAN" in-interface=LAN_WLAN
add chain=input action=drop comment="Router - Drop other traffic" # timto se zahodi i komunikace vnitrni sit -> router, viz pridane pravidlo na radku 1.
add chain=forward comment="LAN - Accept ICMPv6 " protocol=icmpv6
add chain=forward comment="LAN - Accept established Connections" connection-state=established # zbytecne prohlizi pakety z vnitrni site, viz nasledujici poznamka
add chain=forward comment="LAN - Accept related connections" connection-state=related
add chain=forward comment="LAN - Internal traffic" in-interface=LAN_WLAN # toto pravidlo je nutne dat jako prvni z chainu FORWARD, LAN->WAN komunikace ma pak o 4 pravidla rychlejsi cestu.
add chain=forward action=log comment="LAN - Log everything else" log-prefix="Log IPv6" # pravidlo bude logovat hromadu UDP paketu, logy budou nejspis k nicemu.
add chain=forward action=drop comment="LAN - Drop invalid Connections" connection-state=invalid # posunuto za log, pokud bude log fungovat je dobre vedet o invalidni komunikaci, pokud ne je potreba ho vyhodit.
add chain=forward action=drop comment="LAN - Drop everything else" connection-state=new in-interface=adsl
Nijak se neomezuje UDP komunikace na stroje ve vnitrni siti (IPv6 jsou vsechny verejne, ze?) IPv6 obecne nema zadne solidni L2/L3 zabezpeceni, takze pokud na strojich ve vnitrni siti neni nasazeny kvalitni personal firewall s IPv6 funkci, doporucuji celou IPv6 vypnout.
Navic zabezpeceni na urovni jakkoliv pridelenych IPv6 adres neni opravdu funkcni, stroj muze mit statickou/DHCPv6/SLAAC IP, plus k tomu ma jeste automatickou privatni zalozenou na MAC (EUI-64), plus jeste dalsi docasnou automatickou ktera na MAC zalozena neni a prubezne se meni (diky privacy extension v IPv6). NEDA se urcit kterou z techto IP stroj pouzije jako odchozi (vedou vsechny do stejne site), a pokud nechcete nastavovat i dynamicke DNS a resit firewall nejak nad hostname misto IP, coz uz je pro domaci sit s kanonem na vrabce. Pokud nemate nejaky OPRAVDU dobry duvod proc pouzit IPv6, pak mate OPRAVDU dobry duvod proc ho nepouzit.
-
mala oprava, prehlednul jsem predposledni pravidlo v INPUT chainu. Bude fungovat, ale stejne jako u FORWARD je zbytecne pozde, ma byt na zacatku.
-
IPv6 obecne nema zadne solidni L2/L3 zabezpeceni
Tim myslíš jenom to, co píšeš níž, nebo ještě něco jinýho?
Navic zabezpeceni na urovni jakkoliv pridelenych IPv6 adres neni opravdu funkcni, stroj muze mit statickou/DHCPv6/SLAAC IP, plus k tomu ma jeste automatickou privatni zalozenou na MAC (EUI-64), plus jeste dalsi docasnou automatickou ktera na MAC zalozena neni a prubezne se meni (diky privacy extension v IPv6). NEDA se urcit kterou z techto IP stroj pouzije jako odchozi (vedou vsechny do stejne site), a pokud nechcete nastavovat i dynamicke DNS a resit firewall nejak nad hostname misto IP, coz uz je pro domaci sit s kanonem na vrabce. Pokud nemate nejaky OPRAVDU dobry duvod proc pouzit IPv6, pak mate OPRAVDU dobry duvod proc ho nepouzit.
A on snad existuje nějaký OPRAVDU dobrý důvod, proč na domácí (koneckonců i jakékoli jiné) síti firewallovat odchozí provoz?
-
ale ten firewall nefiltruje ani prichozi UDP a koncove stanice budou mit verejnou IP...
navic odchozi komunikace tak nejak definuje i tu navratovou, ze, takze v pripade ze udelam restrikci na IP/port v routeru, nikde nemam jistotu, ze to pravidlo bude fungovat protoze stroj muze komunikovat na minimalne trech IP, pricemz dve z nich jsou nepredikovatelne.
Filtrovani odchozi komunikace rozhodne smysl ma, pokud se bavime o zabezpecene siti ze ktere nechci ven poustet spam/zombie a podobne. Realnemu napadeni pres diry v systemu totiz uplne zabranit nelze, lze jen minimalizovat nasledky.
Ale asi mame kazdy uplne jiny nazor na zabezpeceni site.
Pochopitelne, pokud vam nevadi vyuzivani vaseho pripojeni k netu treti stranou, jen do toho.
-
IPv6 nema zadne zabezpeceni. Je to jen protokol. Neobsahuje zadne prvky ktere by mely zabranit nezadouci komunikaci.
Vetsina dnesnich domacich routeru (mtik je jedna z vyjimek) nema ani IPv6 pravidla ve svem firewallu a jede v rezimu pass-through. Pouziti kvalitni ochrany typu L2/L3 firewall a aplikacni firewall na koncovych strojich je prakticky jedina moznost jak chranit koncove stroje. Z toho vseho mi vyplyva ze pokud IPv6 opravdu nepotrebuji, nevidim duvod proc mit vubec IPv6, nebo 6to4 rozhrani vubec zapnute.
-
Nijak se neomezuje UDP komunikace na stroje ve vnitrni siti (IPv6 jsou vsechny verejne, ze?) IPv6 obecne nema zadne solidni L2/L3 zabezpeceni, takze pokud na strojich ve vnitrni siti neni nasazeny kvalitni personal firewall s IPv6 funkci, doporucuji celou IPv6 vypnout.
ne i u ipv6 existuji privatni rozsahy viz https://en.wikipedia.org/wiki/Private_network#IPv6 + jeste adresy zaciinajici :: ,
napr u 6to4
a jak zaznelo vys , k cemu filtrovat odchozi?
-
Pouziti kvalitni ochrany typu L2/L3 firewall a aplikacni firewall na koncovych strojich je prakticky jedina moznost jak chranit koncove stroje.
Co na těch koncových počítačích běží za nebezpečné služby, že je potřeba je chránit firewallem? Není lepší služby, které tam běžet nemají, vypnout, a služby, které tam běžet mají (což v domácí síti bud možná nějaký NAS) zabezpečit?
Z toho vseho mi vyplyva ze pokud IPv6 opravdu nepotrebuji, nevidim duvod proc mit vubec IPv6, nebo 6to4 rozhrani vubec zapnute.
Já zase nevidím důvod, proč konfigurovat nějaký firewall, když tomu dotyčný nerozumí. V případě firewallu totiž vůbec nejde o to, zda ho někdo má nebo nemá, ale jestli ho umí správně nastavit, správně používat. Nechápu tuhle módu, kdy každý, kdo umí něco naklikat, má pocit, že musí mít firewall. Řekl bych, že je to úplně stejné, jako se zbraní - když ji jenom máte a neumíte ji používat, může to být kolikrát horší, než ji nemít vůbec.
-
ale ten firewall nefiltruje ani prichozi UDP a koncove stanice budou mit verejnou IP...
Jaky firewall?
navic odchozi komunikace tak nejak definuje i tu navratovou, ze,
Pokud vyjdeš z tohodle, tak samozřejmě nutně dojdeš k tomu závěru, ke kterému jsi došel. Kdybys postupoval opačně: 1) odchozí komunikace definuje příchozí a 2) veškerá odchozí je povolena, tak dojdeš k úplně jinému závěru.
Filtrovani odchozi komunikace rozhodne smysl ma, pokud se bavime o zabezpecene siti ze ktere nechci ven poustet spam/zombie a podobne.
A jak to zařídíš, aby ty zombie nekomunikovaly přes https na standardním portu? Nebo ten zakážeš taky? Nebo IDS s podvrhováním certifikátů?
Nebo jenom falešný pocit bezpečí?
Ale asi mame kazdy uplne jiny nazor na zabezpeceni site.
Tak aspoň na něčem se shodneme :)
-
Pokud vyjdeš z tohodle, tak samozřejmě nutně dojdeš k tomu závěru, ke kterému jsi došel. Kdybys postupoval opačně: 1) odchozí komunikace definuje příchozí a 2) veškerá odchozí je povolena, tak dojdeš k úplně jinému závěru.
Pardon, přehlídl jsem se, tohle škrtám.
-
A on snad existuje nějaký OPRAVDU dobrý důvod, proč na domácí (koneckonců i jakékoli jiné) síti firewallovat odchozí provoz?
Ano. Je třeba mít zablokovaná odchozí TCP spojení na port 25 kromě vybraných důvěryhodných IP adres, jinak první nakažená stanice ve vnitřní síti která dostane v rámci botnetu příkaz rozesílat spamy dostane vaši IP adresu na spoustu SMTP blacklistů a pak se budete divit proč vám neodcházejí ani legitimní e-maily.
-
Ano. Je třeba mít zablokovaná odchozí TCP spojení na port 25 kromě vybraných důvěryhodných IP adres, jinak první nakažená stanice ve vnitřní síti která dostane v rámci botnetu příkaz rozesílat spamy dostane vaši IP adresu na spoustu SMTP blacklistů a pak se budete divit proč vám neodcházejí ani legitimní e-maily.
Jasně, to je jediný port, u kterého to má smysl. A spousta ISP ho blokuje sama, takže to je docela bezpředmětný.
-
Nu, třeba odchozí firewall se hodí minimálně proto, že tím pouštím ven jen IPčko/blok mi přidělený a ostatní pakety se zdrojovou adresou mimo blokuji.
Například proto, že někteří ISP shodí vždy spojení, když jim pošlete paket, kde je jiná zrojová IPv4/6, než vám přidělená, což kapánek nabořuje komunikaci, pokud je to linka na bázi nějakého PPP/PPPoE. Přeci jen to obnovení PPP spojení moment trvá a obvykle popadá při tom aktivníé spojení...
-
Největší přínos v6 je v tom, že na libovolné ledničce nebo dveřnímu pantu můžu přidělit globálně dosažitelnou adresu a přímo se na ni připojit odkudkoli z celého světa. Pokud o tuhle možnost kvůli dynamickým adresám přijdu, nevím, k čemu by mi šestka byla dobrá (kromě možnosti připojit se na *statické* adresy v jiné síti).
Chmm... kvuli tomu uz pred par mesici vymysleli DNS, a dokonce se umi samo aktualizovat. Cimz netvrdim, ze by adresy nemely bejt pridelovany vicemene staticky (minimalne co se rozsahu pro zakaznika tyce).
A on snad existuje nějaký OPRAVDU dobrý důvod, proč na domácí (koneckonců i jakékoli jiné) síti firewallovat odchozí provoz?
Existujou duvody, ale to, ze stroj pouzije pokazdy jinou IP tomu vubec nijak nebrani. Ipcka ktery lze pouzit pro komunikaci smerem ven jsou vzdy zcela jasne definovana pouzitym prefixem.
-
Nu, třeba odchozí firewall se hodí minimálně proto, že tím pouštím ven jen IPčko/blok mi přidělený a ostatní pakety se zdrojovou adresou mimo blokuji.
Například proto, že někteří ISP shodí vždy spojení, když jim pošlete paket, kde je jiná zrojová IPv4/6, než vám přidělená, což kapánek nabořuje komunikaci, pokud je to linka na bázi nějakého PPP/PPPoE. Přeci jen to obnovení PPP spojení moment trvá a obvykle popadá při tom aktivníé spojení...
Kteri nekteri? U vetsiny ISP vpohode projde do site i privatni rozsah. A to pochopitelne i 4kovej. Na 6tce mi zcela bez problemu funguje komunikace se zcela jinym src.
-
Díky za reakci! Ten port 546 jsem pravda dogooglil, protože Mikrotik nedostával od T-Mobilu rozsah,což tohle spravilo..
Hm, je to možný, že to tak T-mobile má. Běžnější je použití router solicitation, který běží přes icmp6 ( http://wiki.mikrotik.com/wiki/Manual:IPv6/ND#Stateless_address_autoconfiguration ).
TMO samozřejmě má puštěno na těch DSL linkách i toto. Nicmémě specifikace IPv6 říká, že takto se může konfigurovat pouze koncová stanice, ne router, ten ho má ignorovat. A Mikrotik to tak v základu dělá. Takže to je pro případ, že budu mít tupý DSL modem a PPPoE spojneí ukončením přímo v jendom koncovém počítači, pak se dle toho nastaví.
Dneksa máme RFC pro domácí end user routery, kde se říká, aby akceptovaly na WAN portu ohlášení routeru (v Mikrotiku jde zapnout pod /ipv6 settings). Nicméně pro tu konfiguraci na LAN stranu potřebuji ten IPv6 prefix pomocí DHCPv6-PD od operátora získat. Takže ten port a DHCPv6-PD klient zapnutý na tom dsl portu je nutný (stačí omezit na link local adresy).
-
Takže ten port a DHCPv6-PD klient zapnutý na tom dsl portu je nutný (stačí omezit na link local adresy).
Nebyl by nutný právě kdybych měl ve smlouvě, že můj rozsah je X. Ale dobře, už jsem vzal na vědomí, že se to tak u velkých ISP nedělá...
-
Kteri nekteri? U vetsiny ISP vpohode projde do site i privatni rozsah. A to pochopitelne i 4kovej. Na 6tce mi zcela bez problemu funguje komunikace se zcela jinym src.
Jak jsem psal, je to tam, kde se používá PPP, řešil jsme to několikrát u O2, kdy padající linka se vysvětlila tak, že odchází pakety s jinou zdrojovou adresou než přidělenou a PPP koncentrátor je nastaven, že má v tom případně spojení hnedka dropnout. Blbé je, když občas na IPv4 takto utíkají pakety, které se "zapomenou" NATnout. Když jsem pak chytka komunikaci v Mikrotiku na odchozím PPP spojení, tak to bylo krásně vidět, jak šel první paket s blbou adresou, bum disconnect.
Že někteří pustí cokoliv, to je věc jiná, neměli by to dneska dělat (BCP38?).
-
Chmm... kvuli tomu uz pred par mesici vymysleli DNS, a dokonce se umi samo aktualizovat.
No jenže dynamicky aktualizované DNS je berlička kvůli nedostatku v4 adres a nenapadá mě žádný důvod, proč by se měl používat v šestce.
řešil jsme to několikrát u O2, kdy padající linka se vysvětlila tak, že odchází pakety s jinou zdrojovou adresou než přidělenou a PPP koncentrátor je nastaven, že má v tom případně spojení hnedka dropnout.
Ježkovanoho, bavíme se o domácím/zákaznickém hraničním firewallu, ne o tom, co si má nastavit ISP ::)
-
Takže ten port a DHCPv6-PD klient zapnutý na tom dsl portu je nutný (stačí omezit na link local adresy).
Nebyl by nutný právě kdybych měl ve smlouvě, že můj rozsah je X. Ale dobře, už jsem vzal na vědomí, že se to tak u velkých ISP nedělá...
Jak to popisuješ, tak je to u velkých ISP běžné, pokud jsi firemní zákazník se smlouvou, kde s ebavíme o SLA a cenách X.XXX Kč/měsíc a výše. Poklud jsi domácí masovka, tak jen dynamika.
U malých wiif ISP na bázi Mikrotik tu dynamiku potkáč, pokud používají PPPoE, tka jde dělat jendoduše, jinak to děljí jak píšeš, protože Mikrotik to nemá zaítm plně automatizovatelně použitelné.
Ježkovanoho, bavíme se o domácím/zákaznickém hraničním firewallu, ne o tom, co si má nastavit ISP ::)
Já jen vysvětluji, proč je žádoucí, aby domácí/zákaznický firewall dělal filtrování odchozích paketů, aby se předešlo zbytečnému shazování linky. :-)
Jinak ohledně trojkombinace DSL od TMO - IPv6 - Mikrotik, tak pokud budu těch linek nastavovat víc stylem, že si nastavím jedno RBčko, pak udělám backup konfigurace a import do dalších, tak IPv6 pojede jen na tom, který bude zapnut první. Při klonování konfigurace přes backup/import dojde k duplikaci DUID pro DHCPv6-PD klienta do všech těch RB a TMO to hlídá a přidělí blok jen jendomu (když ho vypnu, tak ten blok /56 dostane další zapnutý a tak se o něj tahají).
Je třeba dělat /export compact a /import konfigurace (jak velí kostelní pořádek pro přenos konfigurace u Mikrotiku), pak se na každém vytvoří DUID správně dle MAC adresy ether1 a vše jede jak má.
-
Jak to popisuješ, tak je to u velkých ISP běžné, pokud jsi firemní zákazník se smlouvou, kde s ebavíme o SLA a cenách X.XXX Kč/měsíc a výše. Poklud jsi domácí masovka, tak jen dynamika.
U malých wiif ISP na bázi Mikrotik tu dynamiku potkáč, pokud používají PPPoE, tka jde dělat jendoduše, jinak to děljí jak píšeš, protože Mikrotik to nemá zaítm plně automatizovatelně použitelné.
Ok, dík za info a omlouvám se způsobené zmatení.