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

[Bubák]

Zdravíčko,

jakým způsobem se v ipv6 řeší záložní konektivita v ipv6 síti s tímto scénářem:

primární konektivita - provider A - ipv6 rozsah A
záložní konektivita - provider B - ipv6 rozsah B

Ideální by bylo řízení preferované konektivity hraničním routerem.

Díky za nasměrování

[Reklama]

[Malíd]

Díky za nasměrování

To je vtip?

[jarda jouda]

Nasměrování směrování čeho do čeho?
Hraniční směrovač směruje obvykle provoz přeložených vnitřně směrovaných adres směrovaných původně do sítě providera A, v případě zjištění výpadku směrování změní a přesměruje provoz přeložených vnitřně směrovaných adres do sítě providera B. 
Směrování dostatečné?

[M.]

Dotyčný se ptá na řešení pro IPv6, tak asi NATu by se chtěl vyhnout.
Záleží na tom, co má za router a co umí, protože je několik řešení.
Já to doma řeším na Mikrotiku (který neumí policy routing pro IPv6) takto:
V LAN mám jeden segment na ULA IPv6 adresách (ze segmentu fc00::/7), který je neměnný a slouží pro interní komunikaci a trvale se propaguje do LAN. Router zjišťuje pomocí pingu funkčnost primární IPv6 linky, pokud funguje, tak do LAN propaguje IPv6 prefix odpovídající lince A a současně pro prefix linky B propaguje nulovou dobou platnost prefixu. Když linka A vypadne a B jede, tak to porohodí a propaguje A prefix s nulovou dobou paltnosti a Béčkový s hodinovou. Klienti se dynamicky pběhem pár sekund překonfigurují a jede se dál (samozřejmě spojení otevřená ven pochcípají a musí se navázat znovu pod novými IPčkama). Takže se v podstatě propagují do LAN tři IPv6 segmenty a těm odpovídajícím WANA a WANB se mění ohlašovaný valid/preffered lifetime podle ne/dostupnosti WANA IPv6 konektivity.

[Ondřej Caletka]

Zdravíčko,

jakým způsobem se v ipv6 řeší záložní konektivita v ipv6 síti s tímto scénářem:

primární konektivita - provider A - ipv6 rozsah A
záložní konektivita - provider B - ipv6 rozsah B

Ideální by bylo řízení preferované konektivity hraničním routerem.

Díky za nasměrování

Asi nejlepší řešení v takovém případě je dynamické ohlašování síťových prefixů.

Druhým řešením, pokud jde o běžné služby, které nemají problém s NATem, je překlad síťového prefixu hlavního providera na záložního po dobu výpadku. To je v zásadě ekvivalent běžně používaného řešení v IPv4, kdy se při výpadku změní vnější adresa NAT-PATu.

Nejnákladnějším řešením pak je obstarat si vlastní IP adresy a domluvit se s oběma ISP, ať je pro vás směrují, tedy tradiční multihoming.

[Reklama]

[jarda jouda]

Dotyčný se ptá na řešení pro IPv6, tak asi NATu by se chtěl vyhnout.
......

Dotyčný nic o NATu nepíše, což ovšem neznamená, že jej a) nepoužívá, b)nechce/nemůže používat do budoucna...
Třeba řeší záložní připojení pro několik tisíc počítačů a serverů národního cybersecurity centra bezpečnostní informační služby...

[PetrM]

Dotyčný nic o NATu nepíše, což ovšem neznamená, že jej a) nepoužívá, b)nechce/nemůže používat do budoucna...
Třeba řeší záložní připojení pro několik tisíc počítačů a serverů národního cybersecurity centra bezpečnostní informační služby...

1) NAT + IPv6 = slabomyslný admin
2) NAT != bezpečnostní featura
3) NAT = rovnák na vohybák, který nemá na internetu co dělat

Zapiš si to za uši...

[MP]

Dotyčný nic o NATu nepíše, což ovšem neznamená, že jej a) nepoužívá, b)nechce/nemůže používat do budoucna...
Třeba řeší záložní připojení pro několik tisíc počítačů a serverů národního cybersecurity centra bezpečnostní informační služby...

1) NAT + IPv6 = slabomyslný admin
2) NAT != bezpečnostní featura
3) NAT = rovnák na vohybák, který nemá na internetu co dělat

Zapiš si to za uši...

A pak narazis treba na banku, co ti povoli jen 2 IP adresy. Chci te videt.

Ohledne tematu, nevi nekdo, jak se pak resi DNS pro verejne pristupne sluzby?

[Filip Jirsák]

Ohledne tematu, nevi nekdo, jak se pak resi DNS pro verejne pristupne sluzby?

Dají se do DNS obě IP adresy (přes oba poskytovatele). Ideální je mít pak monitoring a při výpadku jedné konektivity odstranit příslušnou IP adresu i z DNS, aby nepřekážela hloupým klientům. Chytrý klient by si měl poradit sám a při nedostupnosti přes jednu IP adresu zkusit další, ještě chytřejší klient může IP adresy zkoušet v pořadí, jak jsou pro něj nejvýhodnější – začít tou, která je pro něj síťově méně nákladná.

[jarda jouda]

1) NAT + IPv6 = slabomyslný admin
2) NAT != bezpečnostní featura
3) NAT = rovnák na vohybák, který nemá na internetu co dělat
Zapiš si to za uši...

Poučujte tak maximálně tazatele... Jaký napsal dotaz, taký dostal odpověď, pan Caletka to nakonec shrnul, řešeních je několik.
 
A slabomyslný jste tak akorát vy, protože spekulujete, že já doporučuju NAT, že píšu o jeho bezpečnostních výhodách, vohejbám rovnák atp.

A nakonec vlastně, proč rejete do mě, namísto fundované odpovědi tazateli?


 

[M.]

Dotyčný se ptá na řešení pro IPv6, tak asi NATu by se chtěl vyhnout.
......

Dotyčný nic o NATu nepíše, což ovšem neznamená, že jej a) nepoužívá, b)nechce/nemůže používat do budoucna...
Třeba řeší záložní připojení pro několik tisíc počítačů a serverů národního cybersecurity centra bezpečnostní informační služby...

Z pohledu toho, kdo NPTv6 nějakou dobu aktivně používal, tak vím, že to opravdu není ono. :-(
Takže ten dynamický renumbering je cesta. Pokud NAT, tak jen opravdu jako zoufalá nouzovka na chvíli a ne trvalé řešení typu, že mám LAN jen na ULA adresách a používám překlad prefixů jak na WANA, tak i WANB. Ona i ta specifikace pro NPTv6 říká, že autoři protokolů si nemají komplikovat život vymýšlením protokolů fungující přes NAT a taktéž implemetátoři NATů nemají vymýšlet voloviny, aby něco přes to fungovalo, vyjma tupého bezestavového nahrazování prefixů v hlavičkách paketů.

V případě sítě o tisících počítačů už snad bude kompetence a možnost jít do plnotučného BGP a použití PI IPv6 bloku, takže nějaké přehazování IPv6 adres netřeba.

[Vilith]

Ohledne tematu, nevi nekdo, jak se pak resi DNS pro verejne pristupne sluzby?

Dají se do DNS obě IP adresy (přes oba poskytovatele). Ideální je mít pak monitoring a při výpadku jedné konektivity odstranit příslušnou IP adresu i z DNS, aby nepřekážela hloupým klientům. Chytrý klient by si měl poradit sám a při nedostupnosti přes jednu IP adresu zkusit další, ještě chytřejší klient může IP adresy zkoušet v pořadí, jak jsou pro něj nejvýhodnější – začít tou, která je pro něj síťově méně nákladná.

Ty uz  NIKOMU nerad - nez se zmena v DNS u klienta projevi, tak to muze byt i nekolik dnu

[Filip Jirsák]

Ty uz  NIKOMU nerad - nez se zmena v DNS u klienta projevi, tak to muze byt i nekolik dnu

Když o tom vůbec nic nevíte, tak alespoň mlčte. A dostudujte si to (hledejte třeba „DNS Failover“) – používá se to naprosto běžně, např. pro cloudová řešení. Používá to Google, Amazon, Cloudflare a miliony dalších. Pokud vás zajímají základy DNS, zkuste třeba blog CloudDNS.

[Lol Phirae]

Když o tom vůbec nic nevíte, tak alespoň mlčte.

No, já nevím, co o tom teda víš ty, když tady radíš takové kokotiny jako "při výpadku jedné konektivity odstranit příslušnou IP adresu i z DNS, aby nepřekážela hloupým klientům."

Krom toho máš zjevně pomotaný load balancing a failover.

 

[cyClone]

Pán Radek Zajíc mal na LinuxDays prednášku na túto tému v podmienkach domácnosti.
https://youtu.be/klFW3yHlGVE