Zrovna řeším návrh sítě kde bude i Eduroam a IPv6, a čekal jsem jak bude vyřešené logování provozu, protože to je docela bolest... Ukládat ND tabulku beru jako hodně minimalistické řešení, jeho nedostatky jsou nakonec pod článkem zmíněny.
U IPv4 jde spolehlivě nasadit na access síti IP Source Guard, takže od klienta neprojde jiná zdrojová IP než přidělil DHCP server. Pak stačí flow monitoring na úrovni IP adres, doplněný o logy DHCP serveru (vazba na MAC) a Radiusu (vazba na identitu).
U IPv6 se nevyhneme podpoře autokonfigurace (Android), a pak jediné plně spolehlivé řešení je sbírat NetFlow/IPFIX data včetně MAC adres. Tj. součástí identifikace flow jsou nejen IP adresy ale i MAC adresa klienta, podle které se dělá vazba na identitu.
Problém je, že ne každý netflow probe toto umí. Nejelegantnější je sbírat netflow data přímo na routeru. Třeba FortiGate umí netflow probe v HW, což je fajn, a když se na něm zároveň dělá IPv4 NAT, tak mám data rovnou včetně informací z NAT tabulky. Jenže neumí v netflow posílat ty MAC adresy. Nasazením externí flow probe se všechno dost komplikuje a prodražuje, protože to v tomto případě vede na monitorování 4x 10Gb/s portů (HA setup) a stejně z routeru potřebuju dostávat data NAT tabulky...
Jasně, tohle je třeba nedokonalost FortiGate, jenže prostě ani v roce 2024 nejsou všechny produkty v konečném důsledku tak IPv6 ready, aby to nepřinášelo dodatečné komplikace a náklady.
Tak ona vam ani ta MAC adresa zrovna v pripade Androidu (a zrovnatak IOSu) moc nepomuze, kdyz uz se anonymizace dnes standardne povadi uz na druhe vrstve - ta adresa je proste nahodna (maximalne semi-nahodna, tzn. pro jedo AP se dlouhodobe nemeni). Tzn. ten problem s problematickou vazbou na indentitu, co se tu snazite popsat mate tak jako tak a bez ohledu na verzi IP.... a pouzivat MAC jako identifikator je dnes stejne useless jako mit IP jako nejaky identifikator...
V případě 802.1x tohle zrovna není problém, protože stejná MAC adresa, kterou zařízení používá k posílání dat zároveň musí být použita pro autentizaci, jinou autentikátor do sítě nepustí. Takže bez ohledu na to, jakým způsobem MAC adresa vznikla a jak často se mění tu bude vždy vazba mezi MAC adresou a 802.1x identitou.
Akorat ze o 802.1x v tom komentovanem prispevku rec vubec nebyla, ze? ;-) A rozhodne bych netvrdil, ze ti zapskli odpurci IPv6 kverulujici nad problemy bezne tohle v danych sitich opravdu resi... spis tam je zvyk mit staticke DHCP leases na MAC, protoze to tak delaji uz tricet let a prece to nebudou delat jinak...
MAC samozřejmě není trvale persistentní identifikátor. To ale vůbec nevadí. V rámci jedné 802.1x session se měnit nemůže, to hlídá access vrstva. Při příští autentizaci ať si ji klient klidně změní. Netflow collector to spojí s logem z Radius serveru, ale k tomu potřebuje mít právě tu informaci o MAC adrese - ideálně přímo ve flow datech, nebo nějak z ND tabulky routeru (ale pak spíš real-time sledováním změn, ne dumpem jednou za hodinu jak to popisuje článek).
Možná kdybyste napsal jak to tedy řešit lépe, pomohlo by to všem kdo řeší problém efektivní implementace identifikace IP provozu s identitou uživatele v přístupové síti typu Eduroam.
Standardní netflow data - session je kombinace zdrojová/cílová ip/port/protokol, k tomu čas začátku a konce komunikace a objem dat.
Nevím jak je to teď u ISP s Data Retention, dřív měli povinnost cca tohle ukládat po dobu 6 měsíců (ukládání provozních a lokalizačních údajů za účelem vyšetřování trestné činnost).
DR je tu s nami porad, ta povinnost se nikdy nezrusila. Ale rozhodne to neni tak, ze by v pricetne fungujici siti nekdo brecel nad tim, ze klientovi se meni IPv6 adresa, stejne tak neni problem menici se MAC. Proste mate nejakym mechanismem danou koncovou pripojku overenou... a dokazete tedy vse, co od daneho koncaka prislo naparovat.
Tohle je jednoduché u ISP, kde má každý účastník vlastní pevně přiřazený port na agregačním prvku. Dělat to v síti typu eduroam, která je bezdrátová a množina uživatelů není předem daná, je mnohem složitější, protože nejspíš skončíte s tím, že máte jednu podsíť /64 ve které používají různí účastníci různé podmnožiny jednotlivých adres. Pokud tedy potřebujete identifikovat konkrétního účastníka, skutečně nezbývá nic jiného, než párovat MAC adresy a konkrétní IP adresy.
Já bych spíš polemizoval s tím, jestli skutečně i taková síť musí ze zákona takové informace sbírat a uchovávat. V Česku je tisíc a jedna free Wi-Fi, kde k žádné identifikaci účastníků nedochází a nezdá se, že by to byl nějaký zásadní problém. V případě eduroamu je vždycky možné OČTŘ poskytnout seznam účtů které měly v předmětné době aktivní relaci a už to může vyšetřování dostatečně pomoci.
Jenže tady se nebavíme o ISP s přípojkou a často nějakým CPE, ale o WiFi síti pro hosty s 802.1x (Eduroam zmíněn už v prvním postu vlákna). Takže ověření identity klienta je to 802.1x. Povinnost DR pak přímo nemám, ale je rozumné taková data mít z více důvodů. A ve chvíli kdy takovou síť, resp. požadavky na ni, navrhuji, tak zjišťuji že IPv6 - kterou tam rozhodně chci - je v tomto ohledu pořád nezanedbatelná komplikace a podpora potřebných nástrojů i u velkých vendorů ne-výjimečně schází. Což ukazuje i ta šílenost v článku se stahovanám ND table jednou za hodinu přes SNMP.
Ještě mě napadlo, že jedna z možností, jak párovat MAC adresy a IP adresy je utilita addrwatch. Nemusí běžet přímo na routeru a dokonce zvládne sama zpracovat 802.1q tagy, takže může logovat pro víc VLAN zároveň. Vazby se logují v jednoduchém textovém formátu. Není to tak ideální řešení jako exportování MAC adres do Netflow, ale je to lepší než nic.