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

[xyz]

A co  to udelat, tak jak to ma byt? Zazadat si o PI adresy a pak resit klasicky routing? IP budou porad stejne a je jedno pres koho se pripoji. Muze mit klidne i 10 ruznych konektivit, ale adresy budou porad stejny.

[Reklama]

[Dzavy]

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

Moh bys sem, prosim, hodit jak presne to mas udelany? Nejakej Netwatch scripting nebo to funguje nativne?

[werwer]

2) NAT != bezpečnostní featura

mozno nie bezpecnostna featura ale zariadeina za NATom nie su dostupne z internetu, tak ako by si to nazval?

[Filip Jirsák]

mozno nie bezpecnostna featura ale zariadeina za NATom nie su dostupne z internetu, tak ako by si to nazval?

Nikoli, zařízení za NATem nejsou vždy snadno dostupná z internetu. Zabezpečení to není v žádném případě – to, že vy (jako vlastník) máte problém se tam dostat neznamená, že stejný problém má útočník.

[werwer]

nikde som nepovedal ze je to idelane alebo odporucane zabezpecenie.
tak isto nehovorim o nejakych sofistikovanych utokoch
cez NAT napr neprejde scan siete ktora je za NATom kedze siet za NATom nie je dostupna z internetu
ako by si nazval toto?
podla mna sa to da nazvat ako to najjednoduchsie zabezpecenie, ci je to optimalne alebo dostacujuce? samozrejme ze nie!

[Reklama]

[Filip Jirsák]

nikde som nepovedal ze je to idelane alebo odporucane zabezpecenie.
tak isto nehovorim o nejakych sofistikovanych utokoch
cez NAT napr neprejde scan siete ktora je za NATom kedze siet za NATom nie je dostupna z internetu
ako by si nazval toto?
podla mna sa to da nazvat ako to najjednoduchsie zabezpecenie, ci je to optimalne alebo dostacujuce? samozrejme ze nie!

Ne, není to žádné zabezpečení. Tečka. Není pravda, že síť za NATem není dostupná z internetu. Představte si třeba případ, že na vnější rozhraní toho NATu (které je v internetu) přijde paket s cílovou adresou patřící do té NATované sítě. Co udělá ten router/NAT? Pošle ten paket do vnitřní sítě. Ten paket přišel z internetu, takže ta síť je dostupná z internetu. Určitě budete chtít argumentovat tím, že ale není dostupná z celého internetu. Za prvé je to jiné tvrzení, než jste vy napsal, a za druhé existují i metody, jak se do té vnitřní sítě dostat i odjinud. Na tom, že zvládají tunelování do sítí za NATem, je založená spousta aplikací a protokolů – dřívější Skype, různé VPN, Teredo…

To, že NAT není zabezpečení, bylo už řečeno a dokázáno tolikrát – nechápu, že dneska ještě někdo může tvrdit opak.

[Vilith]

nikde som nepovedal ze je to idelane alebo odporucane zabezpecenie.
tak isto nehovorim o nejakych sofistikovanych utokoch
cez NAT napr neprejde scan siete ktora je za NATom kedze siet za NATom nie je dostupna z internetu
ako by si nazval toto?
podla mna sa to da nazvat ako to najjednoduchsie zabezpecenie, ci je to optimalne alebo dostacujuce? samozrejme ze nie!

Ne, není to žádné zabezpečení. Tečka. Není pravda, že síť za NATem není dostupná z internetu. Představte si třeba případ, že na vnější rozhraní toho NATu (které je v internetu) přijde paket s cílovou adresou patřící do té NATované sítě. Co udělá ten router/NAT? Pošle ten paket do vnitřní sítě. Ten paket přišel z internetu, takže ta síť je dostupná z internetu. Určitě budete chtít argumentovat tím, že ale není dostupná z celého internetu. Za prvé je to jiné tvrzení, než jste vy napsal, a za druhé existují i metody, jak se do té vnitřní sítě dostat i odjinud. Na tom, že zvládají tunelování do sítí za NATem, je založená spousta aplikací a protokolů – dřívější Skype, různé VPN, Teredo…

To, že NAT není zabezpečení, bylo už řečeno a dokázáno tolikrát – nechápu, že dneska ještě někdo může tvrdit opak.

Pokud nemas nic k tematu, tak uz mlc - nic poradneho neporadis a jen vsude placas sva "moudra"

[Filip Jirsák]

Kdo si myslíte, že jste? Nic neumíte, píšete nesmysly, a ještě budete ostatní okřikovat? Vzhledem k tomu, jak jste se tu zatím projevil, byste měl sedět v koutě a študovat a študovat – a pak se můžete opatrně zapojit do diskuse s lidmi, kteří o těch věcech něco vědí, a pokorně se ptát na věci, které vám nejsou jasné. A přidejte k tomu lekce slušného chování, pokud se s někým neznáte a nepotykali jste si, tak se v češtině vyká. Ono to má dobré důvody, přeci jen vykání spíš vede člověka k tomu, aby se vyjadřoval uctivěji. Což evidentně potřebujete, protože jste podlehl mylnému dojmu, že když spolu diskutujeme na stejném diskusním fóru, je to stejné, jako kdybychom spolu pásli ovce. Jenže ono to stejné není.

Já jsem v této diskusi poradil a teď jsem vyvracel chybné tvrzení, které vyplynulo z původní diskuse. Porovnejte to se svými komentáři – oba dva úplně mimo téma, jenom osobní útoky. A dovolí si to psát „nic pořádného neporadíš“.

[M.]

A co  to udelat, tak jak to ma byt? Zazadat si o PI adresy a pak resit klasicky routing? IP budou porad stejne a je jedno pres koho se pripoji. Muze mit klidne i 10 ruznych konektivit, ale adresy budou porad stejny.

Nu, tazatel neuvedl, v jakém prostředí se pohybuje. Souhlasím, že takto je to nejhezčí, ale asi to není pro SOHO segment. Přeci jen přidělení PI IPv6 /48 bloku něco stojí, pokud si vzpoméním, tak ISP servis za to chtěl i s vyřízením AS cca 10 kKč jednorázově, asi by šlo jinde sehnat levněji, ale poplatek od RIPE je jasně daný.
Potom potřebuji aspoň ty dva ISP, kteří budou se mnou ochotni peerovat BGP nebo aspoň propagovat ten můj PI blok ven v rámci svého BGP a dostupnost mé sítě řešit jinak, než přes klasické BGP. Toto také nebude služba v rámci SOHO tarifů za pětistovku/měsíc. :-(
Takže pro ten SOHO segment asi reálně dneska zbývá ten dynamický renumbering, v nejhorším NPTv6 na záložní trasu.
Další metody asi patří do sci-fi nebo vzdálené budoucností, s ohledme na stav ne/implementace (např. SHIM6).

A to přehazování záznamů v DNS dle linky, tak není to ideál, ale pokud má DNS záznam relativně krátkou TTL, tak se to používá. Není to na veřejně přístupný server ideál, ale pro SOOH přístup domů asi OK, viz žada DynDNS služeb pro Ipv4 i IPv6.

[M.]

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

Moh bys sem, prosim, hodit jak presne to mas udelany? Nejakej Netwatch scripting nebo to funguje nativne?

Nativně to ROS neumí. Pomocí netwatch by to šlo, ale ten reaguje na první ztracený/prošlý paket, což nemusí být ono.
Proto to raději dělám skriptem, který pouštím po 30 sec ze scheduleru. Skript natvrdo testuje, zda přes wan2 je na ping dostupný Google DNS a pokud není, tak Cloudflare DNS, pokud ani jeden, tak zakáže default routu přes wan2 a změní preferred a valid lifetime pro ohlašované prefixy do sítě, aby se to celé překlopilo. Když wan2 ožije, vrátí to zpět. Mám konfiguraci, že přes wan1 normálně jde IPv4 a přes wan2 IPv6, při výpadku přehodím na druhou lajnu. Ty dvě IPv6 pomocí kterých testuji, ty jsou natvrdo směrovány přes wan2 (takže zvolit něco, co mi nebude chybět, když nepojede přes zálohu). Pro ukázku mám dvě vnitřní sítě, a krom těch dvou veřejných rozsahů používám i trvale živý ULA vnitřní prefix.
Mějme:
WAN1 IP 2001:DB8:1100::2, brána 2001:DB8:1100::1, delegovaný rozsah 2001:DB8:1111::/48
WAN2 IP 2001:DB8:2200::2, brána 2001:DB8:2200::1, delegovaný rozsah 2001:DB8:2222::/48
ULA prefix pro vnitřní provoz: fd00:dead:beef::/48

Takže vykradená podstatná část cfg:

Kód: [Vybrat]

/ipv6 address
add address=2001:DB8:1100::2/64 advertise=no interface=wan6he1
add address=2001:DB8:2200::2/64 advertise=no interface=wan6he2
add address=fd00:dead:beef:1::1/64 advertise=no interface=lan6
add address=fd00:dead:beef:2::1/64 advertise=no interface=wlan6
add address=2001:DB8:1111:1::1/64 advertise=no interface=lan6
add address=2001:DB8:1111:2::1/64 advertise=no interface=wlan6
add address=2001:DB8:2222:1::1/64 advertise=no interface=lan6
add address=2001:DB8:2222:2::1/64 advertise=no interface=wlan6


/ipv6 route
add check-gateway=ping comment=WAN6HE2 distance=1 gateway=2001:DB8:2200::1
add check-gateway=ping comment=WAN6HE1 distance=5 gateway=2001:DB8:1100::1
add distance=10 type=unreachable
add comment="WAN6HE2 - blackhole" distance=10 dst-address=2001:DB8:1111::/48 type=unreachable
add comment="WAN6HE2 - blackhole" distance=10 dst-address=2001:DB8:2222::/48 type=unreachable
add comment="WAN6HE2 - pro test dostupnosti linky(Google DNS)" distance=1 dst-address=2001:4860:4860::8844/128 gateway=2001:DB8:2200::1
add distance=5 dst-address=2001:4860:4860::8844/128 type=unreachable
add comment="WAN6HE2 - pro test dostupnosti linky(CloudFlare DNS)" distance=1 dst-address=2606:4700:4700::1001/128 gateway=2001:DB8:2200::1
add distance=5 dst-address=2606:4700:4700::1001/128 type=unreachable


/ipv6 nd
set [ find default=yes ] disabled=yes
add advertise-dns=yes hop-limit=64 interface=lan6 other-configuration=yes ra-interval=10s-30s
add advertise-dns=yes hop-limit=64 interface=wlan6 other-configuration=yes ra-interval=10s-30s
/ipv6 nd prefix
add interface=lan6  prefix=fd00:dead:beef:1::/64 preferred-lifetime=7h valid-lifetime=7h2m
add interface=wlan6 prefix=fd00:dead:beef:2::/64 preferred-lifetime=7h valid-lifetime=7h2m
add interface=lan6  prefix=2001:DB8:1111:1::/64 preferred-lifetime=1h valid-lifetime=2h
add interface=wlan6 prefix=2001:DB8:1111:2::/64 preferred-lifetime=1h valid-lifetime=2h
add interface=lan6  prefix=2001:DB8:2222:1::/64 preferred-lifetime=0s valid-lifetime=0s
add interface=wlan6 prefix=2001:DB8:2222:1::/64 preferred-lifetime=0s valid-lifetime=0s


/system scheduler
add interval=30s name=sched-check-inet6-he2 on-event=script-check-inet6-he2 policy=read,write,test start-date=jan/01/2000 start-time=00:00:00


/system script
add dont-require-permissions=no name=script-check-inet6-he2 owner=admin policy=read,write,test source="# Kontroluje ..."

Tělo vlastního skriptu je zde:

Kód: [Vybrat]

# Kontroluje dostupnost IPv6 internetu pres WAN6HE2 a pripadne to prehodi na WAN6HE1

# jake IPv6 adresy testujeme (Google DNS a CloudFlare DNS)
:local checkdst1 "2001:4860:4860::8844"
:local checkdst2 "2606:4700:4700::1001"
# z jake delame test (IPv6 adresu z LAN odpovidajici WAN2 lince)
:local checksrc "2001:DB8:1111:1::1"
# komentar pro vyhledani routy
:local cmdid WAN6HE2
# prefixy odpovidajici na LAN 1. a 2. lince
:local lanprefixes1 "2001:DB8:1111:"
:local lanprefixes2 "2001:DB8:2222:"

# test result
:local wanok 0

# funkce provede ping test na zadany pip cil z daneho src zdroje, vraci 1 pri OK 3x ping po sobe, 0 po sesti pokusech
:local pingcheck do={
  :local cntpings 0
  :local cntok 0
  :do {
    :set cntpings ($cntpings + 1)
    :if ([ /ping "$pip" src-address="$src" interval=2s count=1 ] > 0) do={
      :set cntok ($cntok + 1)
      :if ($cntok>2) do={ :return 1 }
    } else={ :set cntok 0 }
    :delay 1s
  } while=($cntpings<6);
  :return 0
}

:set wanok [ $pingcheck pip=$checkdst1 src=$checksrc ]
:if ($wanok=0) do={ :set wanok [ $pingcheck pip=$checkdst2 src=$checksrc ] }

:if ($wanok > 0) do={
  :if ([ ipv6 route get number=[ find comment="$cmdid" ] disabled]=true) do={
    # WAN6_2 jede, prehod na nej
    :local msg "$cmdid OK gw - $[/system identity get name] - $[/system clock get time] $[/system clock get date]"
    /log warning message=$msg
    /ipv6 route set [ find comment="$cmdid" && disabled=yes ] disabled=no
    /ipv6 nd prefix set [ find where prefix~"$lanprefixes1" ] preferred-lifetime=0s valid-lifetime=0s
    /ipv6 nd prefix set [ find where prefix~"$lanprefixes2" ] preferred-lifetime=1h valid-lifetime=2h
  }
} else={
  :if ([ ipv6 route get number=[ find comment="$cmdid" ] disabled]=false) do={
    # WAN6_2 nejede, prehod na WAN6_1
    :local msg "$cmdid KO gw - $[/system identity get name] - $[/system clock get time] $[/system clock get date]"
    /log error message=$msg
    /ipv6 route set [ find comment="$cmdid" && disabled=no ] disabled=yes
    /ipv6 nd prefix set [ find where prefix~"$lanprefixes1" ] preferred-lifetime=1h valid-lifetime=2h
    /ipv6 nd prefix set [ find where prefix~"$lanprefixes2" ] preferred-lifetime=0s valid-lifetime=0s
  }
}

Dále je vhodné pod /ipv6 firewall filter mít na začátku pravidla, co blokují output a forward do těch wan linek jiných zdrojových bloků, než ty přidělené k daným linkám (ať po překlopení to rejectuje staré spojení s původní IP pro druhou linku).

Konfig zjendodušen pro jeden router s dvěma WAN IPv6 linkama, v reálu to mám kapánek složitěji (jsou tam dva routery vedle sebe se vzájemně zálohující a pomocí VRRP si předávají LAN i WAN strany, použití dvou routerůl mi i dovoluje naráz využívat obě IPv6 konektivity pro různé LAN segmenty, to s jedním Mikortikem nejde pro nepodporu policy routingu na IPv6 v ROSu).

[xyz]

A co  to udelat, tak jak to ma byt? Zazadat si o PI adresy a pak resit klasicky routing? IP budou porad stejne a je jedno pres koho se pripoji. Muze mit klidne i 10 ruznych konektivit, ale adresy budou porad stejny.

Nu, tazatel neuvedl, v jakém prostředí se pohybuje. Souhlasím, že takto je to nejhezčí, ale asi to není pro SOHO segment. Přeci jen přidělení PI IPv6 /48 bloku něco stojí, pokud si vzpoméním, tak ISP servis za to chtěl i s vyřízením AS cca 10 kKč jednorázově, asi by šlo jinde sehnat levněji, ale poplatek od RIPE je jasně daný.
Potom potřebuji aspoň ty dva ISP, kteří budou se mnou ochotni peerovat BGP nebo aspoň propagovat ten můj PI blok ven v rámci svého BGP a dostupnost mé sítě řešit jinak, než přes klasické BGP. Toto také nebude služba v rámci SOHO tarifů za pětistovku/měsíc. :-(
Takže pro ten SOHO segment asi reálně dneska zbývá ten dynamický renumbering, v nejhorším NPTv6 na záložní trasu.
Další metody asi patří do sci-fi nebo vzdálené budoucností, s ohledme na stav ne/implementace (např. SHIM6).

A to přehazování záznamů v DNS dle linky, tak není to ideál, ale pokud má DNS záznam relativně krátkou TTL, tak se to používá. Není to na veřejně přístupný server ideál, ale pro SOOH přístup domů asi OK, viz žada DynDNS služeb pro Ipv4 i IPv6.

Poplatek RIPE je presne 50eur. Je uplne jedno v jakym je to segmentu. Pokud nekdo potrebuje realne resit IPv6 zalohu, tak mu stejne nic jinyho nezbude.

[peter]

Ne, není to žádné zabezpečení. Tečka. Není pravda, že síť za NATem není dostupná z internetu. Představte si třeba případ, že na vnější rozhraní toho NATu (které je v internetu) přijde paket s cílovou adresou patřící do té NATované sítě. Co udělá ten router/NAT? Pošle ten paket do vnitřní sítě. Ten paket přišel z internetu, takže ta síť je dostupná z internetu.

Netvrdím že NAT je nejaké výrazné zabezpečenie, ale Váš príklad by fungoval len ak by na danom routeri ktorý vykonáva NAT vnútorných adries na vonkajšiu nebolo žiadne iné pravidlo. Pokiaľ na vonkajší interface príde packet s cieľovou adresou vo vnútornej sieti, tak predsa ten packet zahodím. To dokáže aj jednoduché pravidlo cez iptables.
Samotné NAT per se samozrejme okrem prekladu (a tým aj schovania) adries žiadnu bezpečnosť nerieši, no zriedkakedy sa používa bez toho aby daný router odrážal minimálne všetky pokusy o odoslanie packetu z vonkajšej do vnútornej siete. Ostávajú síce čiastočne otvorené vrátka v prípade povoleného UDP, no tam si myslím je problém či už NAT alebo neNAT.

[peter]

Ešte dopním, že podobne by ste mohli argumentovať že firewall vyhodnocujúci packety po TCP/IP vrstvu nie je žiadne zabezpečenie, predsa niekto na routovanej ceste môže uniesť spojenie. To je pravda, môže, a preto je trend že sa všetko v aplikačnej vrstve podpisuje / šifruje.

[peter]

Ešte dopním, že podobne by ste mohli argumentovať že firewall vyhodnocujúci packety po TCP/IP vrstvu nie je žiadne zabezpečenie, predsa niekto na routovanej ceste môže uniesť spojenie. To je pravda, môže, a preto je trend že sa všetko v aplikačnej vrstve podpisuje / šifruje.

Pardon, myslel som ...vyhodnocujúci po transportnú vrstvu TCP / IP protokolu.

[Filip Jirsák]

Netvrdím že NAT je nejaké výrazné zabezpečenie, ale Váš príklad by fungoval len ak by na danom routeri ktorý vykonáva NAT vnútorných adries na vonkajšiu nebolo žiadne iné pravidlo. Pokiaľ na vonkajší interface príde packet s cieľovou adresou vo vnútornej sieti, tak predsa ten packet zahodím. To dokáže aj jednoduché pravidlo cez iptables.

Děláte si v tom sám zmatek tím, že nerozlišujete router, firewall a NAT. Když ten váš popis upřesním, píšete: „Váš příklad by takhle fungoval jedině tehdy, kdyby na routeru byl jenom NAT. Když přidám i firewall a do něj jednoduché pravidlo, paket z internetu do vnitřní sítě neprojde.“ Ano, v tom máte pravdu, a je to přesně to, co celou dobu tvrdím – NAT není žádné zabezpečení. Abyste tu vnitřní síť zabezpečil, musel jste na router dát firewall – samotný NAT nic nezabezpečil.

Samotné NAT per se samozrejme okrem prekladu (a tým aj schovania) adries žiadnu bezpečnosť nerieši, no zriedkakedy sa používa bez toho aby daný router odrážal minimálne všetky pokusy o odoslanie packetu z vonkajšej do vnútornej siete. Ostávajú síce čiastočne otvorené vrátka v prípade povoleného UDP, no tam si myslím je problém či už NAT alebo neNAT.

NAT žádné adresy neschovává. Jak jste správně napsal v předchozím odstavci, samotný NAT žádnou bezpečnost neřeší. Pokud chcete bezpečnost, musíte vedle NATu dát ještě něco jiného, co tu bezpečnost bude řešit. Asi vás mate to, že se NAT velice často vyskytuje na stejném zařízení jako firewall, ale tu bezpečnost pak řeší firewall, nikoli NAT.

Ešte dopním, že podobne by ste mohli argumentovať že firewall vyhodnocujúci packety po TCP/IP vrstvu nie je žiadne zabezpečenie, predsa niekto na routovanej ceste môže uniesť spojenie. To je pravda, môže, a preto je trend že sa všetko v aplikačnej vrstve podpisuje / šifruje.

Nikoli. Únos spojení je nebezpečí, před kterým firewall nechrání, ale firewall chrání před jiným nebezpečím – např. před komunikací útočníka se zařízením, ke kterému útočník nemá mít přístup. NAT nechrání před žádným nebezpečím – jak jste sám správně uvedl, aby router začal vnitřní síť chránit, musíte přidat firewall, NAT síť před ničím neochrání.