Korektní přesměrování na welcome screen

[oliver.es]

Ahoj, řeším takovou složitější situaci.

Jelikož chceme bezezbytku naplnit povinnosti data retention, které nám ukládá zákon, musíme mimo jiné i z tohoto důvodu přesně vědět o každé klientské MAC adrese v síti. Doposud fungujeme na VLANách, tedy co zákazník to VLAN, a pro usnadnění práce technikům používáme DHCP servery, je to rozsubnetované, takže je evidence a zpětné určení kdo je kdo velmi jednoduchá. Chystáme se ale zákazníky sloučit pod jednu VLAN na 1 GPON port v OLT a proto že zákazník si za převodník může dát svůj switch a fungovat bez routeru, tak budeme muset každé zařízení nejprve povolit (to platí ještě víc pro IPv6, kdy musíme evidovat DUID a IAID).

Vybrali jsme si proto řešení pomocí DHCP serveru, kdy neznámé zařízení dostane IP z poolu, který je určen pouze pro welcome screen (DHCP může obsahovat i jednoúčelový DNS server) a aby se zařízení objevilo v DHCP leases. Následně technik z něj udělá statický záznam a změní přiřazenou IP na jiný dhcp pool, kde už je internet normálně povolen. Protože si ale zákazník může za převodník připojit kdykoliv nové zařízení, ať už nový WiFi router, nebo přímo PC atd., musí se mu zobrazit uvítací obrazovka, která mu řekne, že toto zařízení není zaregistrováno a musí volat podporu.

Hledám tedy způsob jak korektně přesměrovat jakýkoliv požadavek na otevření webové stránky na uvítací obrazovku bez použití hotspotu. V dnešní době, kdy prohlížeče začínají označovat stránky které nepoužívají https jako nebezpečné, je to docela složité. Primitivní způsob přesměrování IP a portů na cílový host samozřejmě znám, ale chci se vyhnout hláškám o chybných certifikátech a podobně. Nevím jak bez hotspotu zprovoznit funkce captive portal detection, která je dnes v moderních OS obsažená. Ví někdo jak tento problém vyřešit?

[rsaf]

Řešilo se to tady opakovaně, naposledy poměrně nedávno. Zákazníkovi je potřeba zakázat vše mimo DNS, na HTTP požadavky na portu 80 vracet HTTP 302 přesměrování na URL captive portalu. Potom by měla zafungovat detekce captive portalu v modrních OS/prohlížečích. Jiná šance není.

Nejsem si ale vůbec jistý, že existuje povinnost evidovat MAC adresu zákazníka, zvláště v sítích typu GPON kde máte své koncové zařízení (ONT), kterým je zákazník jednoznačně identifikován.
Huawei GPON umí přepisovat MAC adresu zákazníka tak, že tato MAC pak jednoznačně identifikuje port/ontid, kam je zařízení připojeno. Tuším, že se to jmenuje VMAC.

[oliver.es]

Minimálně na MAC OS funguje detekce captive portálu i u Mikrotik hotspotu pouze po připojení na WiFi. V případě použití Ethernetu to nezafunguje. To je ale nejspíš záležitos operačního systému.

Napadla mě možnost použití jakéhosi Dummy DNS, který by pomocí Response policy zone vracel na jakýkoliv požadavek (např www.seznam.cz) CNAME záznam welcomescreen.neco.cz a za ním by byla A záznam pro server kde je potřebný welcome screen. Teoreticky by to mělo fungovat i přes DNSSEC. Ale zatím se mi to nedaří zprovoznit. Klasicý blockmap na konkrétní domény nějak funguje, ale ne pro CNAME. Nevím proč.

[rsaf]

Jestli se vrátí CNAME nebo A je úplně jedno, pořád to bude přístup na www.seznam.cz a k tomu nebudeš mít validní certifikát.
Jinak si myslím, že i Windows (bohužel) detekují captive portal jen při připojení přes wifi a Chrome svou detekci vypíná, pokud běží na OS s detekcí.

[oliver.es]

Nejsem si ale vůbec jistý, že existuje povinnost evidovat MAC adresu zákazníka, zvláště v sítích typu GPON kde máte své koncové zařízení (ONT), kterým je zákazník jednoznačně identifikován.
Huawei GPON umí přepisovat MAC adresu zákazníka tak, že tato MAC pak jednoznačně identifikuje port/ontid, kam je zařízení připojeno. Tuším, že se to jmenuje VMAC.

Ano, podle vyhlášky k data retention povinnost logovat MAC adresu existuje. Ale ono nejde jen o MAC adresu. V případě použití jednoportového ONT, který je jen jako mediakonvertor se snadno může stát, že si zákazník za něj dá switch a připojí X zařízení, ty dostanou normálně IP a jsou na internetu. A já nebudu vědět které IP adresy (i MAC adresy) jsou za kterým port/ontid, tedy kdo je kdo. Vlastně pokud budu mít 64 zákazníků v 1 VLAN, tak absolutně při DHCP nebudu vědět jaké je čí IP adresa a ikdyž si udělám na začátku evidenci, tak pořád zákazník může za jednoportové ONT připojit cokoliv, udělat trestnou činnost a já se už pak nedozvím kdo to byl.

[rsaf]

No celý ten přístup je špatně už od počátku. Přece nemůžeš připustit, aby si tam zákazníci připojovali co se jim zachce a teoreticky tím mohli ohrozit síť (falešný DHCP server, ukradené ip/mac adresy... to je kravina).
Proč by měl mít JEDEN zákazník co platí JEDNU cenu připojené ve tvé sítí víc jak JEDNO zařízení - ať si tam dá router.
Za mě je to ONT rozhraní služby, eviduji jeho MAC a více mě nezajímá.
V DHCP požadavcích si můžeš posílat option82, kterým jednotznačně identifikuješ zákazníka (a DHPC server mu přidělí vždy správnou IP adresu), pak můžeš zapnout anti-ipspoofing aby si uživatele ipčka nemohli vzájemně krást...
Anebo použít VMAC. Pokud se nepletu, je tam pak limit 8 MAC na jedno ONT. Jednotlivá zařízení od jednoho zákazníka pak uvidíš třeba pod MAC adresami 02:00:00:08:60:08 - 02:00:00:08:60:0F (zákazník na slot2 port3 ont1).

[oliver.es]

No celý ten přístup je špatně už od počátku. Přece nemůžeš připustit, aby si tam zákazníci připojovali co se jim zachce a teoreticky tím mohli ohrozit síť (falešný DHCP server, ukradené ip/mac adresy... to je kravina).
Proč by měl mít JEDEN zákazník co platí JEDNU cenu připojené ve tvé sítí víc jak JEDNO zařízení - ať si tam dá router.
Za mě je to ONT rozhraní služby, eviduji jeho MAC a více mě nezajímá.
V DHCP požadavcích si můžeš posílat option82, kterým jednotznačně identifikuješ zákazníka (a DHPC server mu přidělí vždy správnou IP adresu), pak můžeš zapnout anti-ipspoofing aby si uživatele ipčka nemohli vzájemně krást...
Anebo použít VMAC. Pokud se nepletu, je tam pak limit 8 MAC na jedno ONT. Jednotlivá zařízení od jednoho zákazníka pak uvidíš třeba pod MAC adresami 02:00:00:08:60:08 - 02:00:00:08:60:0F (zákazník na slot2 port3 ont1).

To je samozřemě správný názor, ale pokud chci používat jednoportové ONT, tak musím provádět právě registraci MAC adres a pokud si tam někdo připojí něco svého, tak mu to musí zařvat že to zařízení není registrováno. Falešný DHCP server naštěstí filtruje OLT automaticky.

U toho VMAC si můžu definova masku (mustr) jak je má přiřazovat? A jak je to s IPv6 ? DUID/IAID?

[rsaf]

s IPv6 si nejsem jistý, zkusím to najít v dokumentaci.
Formát MAC adresy se zapnutým VMAC je popsán třeba zde zde http://support.huawei.com/hedex/pages/E ... lt-id.html
Formát je daný (co je na kterých bitech), dá se nastavit OLT-ID, dá se ovlivnit jak jsou číslovány sloty/porty, dá se nastavit limit počtu MAC za ONT.

[lemointernet]

Tak to zni velmi dobre. Vyresilo by to spoustu veci. Jeste tak kdyby se DUID pro delegovany IPv6 prefix generoval z VMAC. Pak bude vyresen i problem o kterem mluvil L. Ruzicka na seminari Cesnetu k IPv6 - ze kazdy ISP musi vedet komu priradil IPv6 adresu/prefix.

[oliver.es]

s IPv6 si nejsem jistý, zkusím to najít v dokumentaci.

Formát MAC adresy se zapnutým VMAC je popsán třeba zde zde http://support.huawei.com/hedex/pages/E ... lt-id.html
Formát je daný (co je na kterých bitech), dá se nastavit OLT-ID, dá se ovlivnit jak jsou číslovány sloty/porty, dá se nastavit limit počtu MAC za ONT.

Asi jsem při probírání soustav nedával pozor. Slot ID: 0, Port ID: 5, ONTID: 22 dostane VMAC: 02:FF:FF:18:A0:BE

02FFFF18A0BE - > 0000 0010 1111 1111 1111 1111 0001 1000 1010 0000 1011 1110
0 0000 1011 1 - > 23
ONT ID je ale 22


47-42: These six bits are the reserved bits. You can run the vmac reserved-bits command to set them.
41: One bit. Its value is 1 and indicates the local MAC address.
40: One bit. Its value is 0 and indicates the unicast MAC address.
39-24: These 16 bits are filled with the OLT ID.
23-18: These six bits indicate the slot ID of the user.
17-13: These five bits indicate the port ID of the user.
12-3: These 10 bits indicate the ONT ID of the user.
2-0: These three bits indicate the MAC address allocated to the user.

[oliver.es]

Odpovím si sám. V jiné dokumentaci je uvedeno:

NOTE: The value of this field is the actual ONT ID plus one.