[Megoldva] "Belso" IPv6 cimek

IPv6

Gondolkodom. (lehet csak meg kellene tanulni hasnalni a keresoket....)
Mit lehet hasznalni olyan esetben ha nem akarsz az eszkozoddel a publikus internetre kimenni, de kell halozat?
Mondjuk kamera rendszer IPv6 alapon amit csak egy belso halon akarok elerni.
vagy
Virtualizacio es a storage nem kell hogy szinten publikus legyen de halozat alapu eleres van IPv6 only halozatban.

Erre hasznalni a link-local cimeket? Elegge macerasnak tunik dokumentalni...
Vagy meg valami van? A unique local az hivatalos? Azt kellene hasznalni?
Nem vilagos nekem. Nem kell NAT egyszeruan csak belso halozaton hasznalni amit nem akarok publikus internet fele elerhetove tenni.

( mauzi v | 2019. 02. 20., sze – 20:57 )

A unique local tökéletesen erre való. (fc00::/7)
Tekints rá úgy, mint IPv4 esetén a 10.0.0.0/8, 172.16.0.0/12 és 192.168.0.0/16 privát tartományokra.

Gyárts magadnak egy kvázi-egyedi prefixet, pl:
fdb8:a8cf:1289:a8cc::/64

aztán használd úgy, mind idáig a 192.168.1.0/24-et, például.

Ha bármi okból ki kell vele menni a külvilágba, akkor pont ugyanúgy NAT-olható, mint ahogy IPv4-nél megszoktad.

IPv6 esetén egyébként célszerű a teljes subnetet nem egy publikus (globális) IPv6 címre NAT-olni, hanem egy komplett (azonos prefix hosszúságú) tartományra. Ha úgy tetszik: network prefix translation. Ezzel akár oda-vissza transzparensen átjárható hálózatokat is csinálhatsz, mégpedig stateless módon.

+1 az ULA-nak, én két telephelyet tettem egy /48-as ULA tartomány két /64-es hálójára és szépen tudnak kommunikálni az eszközök egymással, belsőleg szépen routolható.

NAT azért érdekes kérdés, ugyanis sok IPv6 képes eszköz nem tud NAT-olni (pl Mikrotik úgy egészében) IPv6-ot, mert ugye minek (azért néha tényleg nem ártana, ULA-t meg amúgy se lehetne kiengedni, kell hozzá egy publikus cím/tartomány is az ULA mellé a végpontokra, valamint jól működő BGP és más hókuszpókusz nélküli Multi WAN-hoz se ártana a NAT).
Persze egy pőre friss kerneles Linuxos dobozzal biztos megoldható IPTables-sel, vagy mi mostanában a divat, de nem tudom, hogy ilyen kommerszebb kategóriában mely routerek/rendszerek támogatnak IPv6 NAT-ot.

Még mindig él az a hamis prekoncepció hogy a NAT az egyfajta "firewall". Az alulképzett NA-k tartják életben ezt a mítoszt és az igényt is a NAT-ra. A NAT mindig csak egy "workaround" volt, semmi több. A NAT elhitette némelyekkel hogy a hálózati szegmentáció az szükségtelen. Ideje hagyni a NAT-ot elenyészni.

Az alulképzett NA-k tartják életben ezt a mítoszt és az igényt is a NAT-ra
LOL

alkalmazás szintű tűzfalat és/vagy transzparens proxy-t láttál-e már közelről?

Ha igen, mégis hogy működne NAT nélkül???

Ha nem, akkor kicsit olvasgass hozzászólás előtt/helyett.

--
zrubi.hu

a transzparens proxynak/tűzfalnak pont az a lényege, hogy mindegy, mennyire normális a program.

Íme néhány példa:
http://darkk.net.ru/redsocks/
http://tldp.org/HOWTO/TransparentProxy-5.html
https://docs.mitmproxy.org/stable/howto-transparent/

az egyetlen NAT nélküli megoldás a Balabit féle TPROXY kernel patch (nem tudom benne van-e a vanilla kernelben), amihez viszont az alkalmazás szintű proxy/tűzfal részt is kell erre felkészíteni. A Squid pl biztosan támogatja ezt a módot is.

--
zrubi.hu

nyilván transzparensen tűzfalazni csak a nem titkosított forgalmat lehet (tanúsítvány csere/hamisítás nélkül)
De ez általában nem probléma, ha szerver oldalt akarsz védeni. Egyszerűen a TLS réteg kibontása után jön a protokoll szűrés. (utána meg akár vissza is lehet csomagolni) Eközben a kliens abban a hitben van, hogy direktben a szerverrel beszélget...

transzparensen proxyzni viszont bármilyen forgalmat lehet, mert ahhoz nem kell belelátni a protokollba. És ez a gyakorlatban igen hasznos feature.
pl egy RDP-t is csak így lehet proxy-n keresztül terelni.
enélkül maradnak a tsocks-szal való szarakodások kliens oldalon.

--
zrubi.hu

Számomra tisztábbnak tűnik az, amikor "ip6tables -A FORWARD -j NFQUEUE" -t csinálsz tetszőleges protokollra és így adod át az alkalmazástűzfalnak kiértékelésre, amely a megtekintés után vagy ACCEPT-tet dob vissza a QUEUE-ba vagy DROP-ot. Ez ugyanis minden protokollt QUEUE-ba dob, nem korlátozódik arra sem, hogy kizárólag TCP, UDP, SCTP lehessen a szűrendő. Bármit, ami IP-n forwardolódik az alkalmazástűzfalra és annak szabályrendszerére tud bízni.

Suricata ezt képes használni: https://doxygen.openinfosecfoundation.org/source-nfq_8c_source.html#l00…
Kernelben: net/netfilter/nf_queue.c

update: úgy néz ki, nem ritka a használata. Még Rust-ban is van rá userspace modul: https://docs.rs/nfqueue/0.9.1/nfqueue/ - a GitHUB-on levő példa tényleg működik.

Mikrotik sajnos megragadt a 3.3-as Linux kernelnél. Majd ha kijön pl. egy 5.x-es friss kernellel, akkor a Mikrotik is tudni fogja. Persze a mikor az jó kérdés.
Addig sajnos SOHO téren marad az OpenWRT képes router. Az OpenWRT 18.06.x-ben futó 4.9-es Linux kernel szépen tudja.
És persze a drágább IPv6 képes routerek is tudják (Cisco, Juniper, ...).

De ahogy írták előttem, publikus IP cím mehet a hostnak a belső IP cím mellé. Nálam is így van itthon konfigolva. Egyébként az oka az nálam, hogy a dinamikus publikus IP-re nem tudtam fix nevet osztani a belső hálózati gépeimnek. Így belül ha néven szólítom, akkor belső IP címen érem el, kifelé viszont a publikus IP címén kommunikál.

Majd ha jön a ROS 7 :D, a Mikrotik már régóta ezzel bosszantja a fórumán a jónépet, ha valamit kérdeznek, hogy mikor fogja már tudni, válasz: majd a ROS 7-ben lesz megvalósítva (már legalább 5 éve hitetik a jónépet).
A drágábbak biztos tudják, de a több mint 10 éve hallgatott CCNA óta nem láttam Cicót vagy hasonló komolyságú macsekot munkahelyen sem. Örültem, hogy a Linux-os PC-ket Mikire tudtam cserélni (nem utálom sem a Linuxot sem a PC-t, de egy kis fogyasztású passzív hűtésű eszköz jobban való kis telephelyre pl).

Tényleg, a Mikrotik-OpenWRT párosításról mik a tapasztalatok?
https://downloads.openwrt.org/releases/18.06.2/targets/ar71xx/mikrotik/
Milyen kernele van? Mik a gyenge pontjai a RouterOS-hez képest?
A honlap szerint ezekre a Mikrotikekre megy fel az OpenWRT: https://openwrt.org/toh/start?dataflt%5BBrand*%7E%5D=MikroTik

... és hogyan kell felvarázsolni, majd ha mégsem ez lesz a befutó, akkor a ROS-t vissza?

Ha támogatott az eszközöd és még Wifi is van benne, az állítólag jobban müxik OpenWRT-vel (mobiltelefonokkal stabilabb kapcsolat) :D
Viszont ugye elvesztesz olyan képességeket, amire otthon lehet hogy nincs szükséged (pl nv2, station bridge, CAPsMAN).
Hardveres NAT-ot nem hiszem, hogy támogat a ROS, de az OpenWRT alatt se lesz.
Ha neked elég, amit az OpenWRT alapból nyújt, akkor nem hiszem, hogy az olcsóbb Mikik esetén nagy érvágás lenne az OpenWRT, sőt.
Én azért szeretem jobban a ROS-t, mert használok OpenVPN-t, dynDNS-t (Miki Cloud) meg QoS-t és mindez gyárilag benne van az alap ROS-ban (nem mintha olyan rengeteg plusz csomag lenne), mindezt a br 6000Ft-s HAP minivel (igaz az internet pont annyira combos, amit még pont kibír ez a tücsök, 15/2 :D )