Új hozzászólás Aktív témák

• #19022 janos666 nagyúr vargalex #19020

  Új Válasz 2023-09-28 15:43:06 #19022

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  janos666

  nagyúr

  válasz vargalex #19020 üzenetére

  Kösz, ez elsőre tényleg egyszerűnek tűnik.
  Viszont a "dumb AP" nálam azt jelenti, hogy a Firewall/DHCP/DNS/stb nem fut, vagy még csak telepítve sincs az AP-re, illetve nincs WAN interfész se, minden csak össze van bridge-elve. Tehát ezt igazából talán tovább tartana beállítani és az AP CPU/RAM terhelését növelné, nem a router-ét (ami egy x86 gép, szóval ott halál elenyésző bármi).

  A másik megoldás akkor szétszedni egy (vagy akár több) ethernet interfészt a router-en és az AP-(ke)n is két VLAN interfészre: _main és _IoT.
  Az AP-(ke)n hozzáadni egy(-egy) új WLAN_IoT interfészt a rádió(k)hoz. A régi WLAN megy a VLAN_main-re, WLAN_IoT a VLAN_IoT-re bridge-be. Semmi Firewall/DHCP/DNS...

  Router oldalon a VLAN_main megy a régi LAN bridge-bre, ha több VLAN_IoT is van, akkor ezek mennek egy új bridge-be (előrelátóan akkor is, ha egyelőre egy csak egy szál VLAN_IoT megy rá, mert ki tudja, hogy sikeresen lefedi-e a ház összes IoT eszközét egy AP/rádió 2.4GHz-en "legacy B" módban, főleg, hogy a padlástér egyik sarkára tervezem, hogy az 5GHz a kertet fedje).
  Annyi kérdés marad, hogy mi kezeli router oldalon a br_IoT-t, mert jelenleg stateless tűzfalszabály NAT-ol amiatt, hogy a belső hálózatról is elérhető legyen a gép a WAN címekkel is (így meg lehet adni fixen mindennek egy aha.ddns.net címet, és működik kint is, bent is). Erre talán van más megoldás is, de ez volt a legegyszerűbb, hogy:
  -A POSTROUTING -j MASQUERADE
  Amíg benne volt az -i br0, addig bentről nem működött az aha.ddns.net címzés. Bár tudom, hogy a fentitől valami elegánsabbal kellett volna megoldani. Amíg ez a fenti opció él, addig végül is NAT-olni fog a router mindenhonnan mindenhova, ahová kell. Egyedül egy új tűzfalszabály kéne, hogy pl. 192.168.2.0/24-ből nem érhető el más, csak a WAN.
  Valami ilyesmi ezekhez?
  -A INPUT -i br_IoT -j REJECT
-A FORWARD -s 192.168.2.0/24 -i br_IoT -j ACCEPT

  Mondjuk lehet, hogy inkább a router-en fogok IoT-ket DHCP-vel ellátni, mert egyszerűbb, mint két dnsmasq-ot futtatni a router-en (miután megnéztem, nem tudok egyetlen dnsmasq folyamattal egyszerre két LAN-t is ellátni, ha nem ugyan abban a tartományban vannak).
  Sőt, lehet, hogy hagyom őket ugyan abban a tartományban, mint a br0, és azt a két eszközt külön kezelem, tehát pl. kizárólag ennyit szúrok be:
  -A INPUT -i br_IoT -j REJECT és kész. Gondolom már így sem lesz elérhető a br0 a br_IoT-ről akkor sem, ha mind 192.168.1.0/24, vagy ebben tévedek?

  De még rugalmasabb lehetne, ha a WLAN_main a fizikai interfésszel lenne bridge-elve router-en és AP-n is, és csak egy szál VLAN lenne, ami a router-en és AP-n is a WLAN_IoT-re bridge-el. Így akkor is működne a WLAN_main, ha ezt a tartalék AP-t átviszem bármi más tetszőleges helyre (jelenleg erre használom). Ez így működne?

Új hozzászólás Aktív témák