DHCP továbbítás korlátozása (OpenWrt)

Hálózatok egyéb

Egy Telekomos otthoni hálózat a következő felépítésű:

WAN
  |
Cisco EPC3925 modem --- LAN1 (192.168.0.0/24), DHCP 1. (192.168.0.50-200)
  |
  | (DMZ) 192.168.0.8/24
  |
OpenWrt router ----------- LAN2 (192.168.1.0/24), DHCP 2. (192.168.1.100-200)

Mostanában azt tapasztaltam, hogy LAN2-ben lévő PC-nek a Telekomos Cisco kábelmodem oszt IP-címet (pl. 192.168.0.50-et) valószínűleg indításkor az OpenWrt és annak DHCP szervere kicsit később éled fel és a LAN2-ben lévő eszközök DHCP kérésre a LAN1-ben lévő már működőképes DHCP 1. szerver válaszol.
Arra lennék kíváncsi, hogy a DHCP kérések ilyen jellegű átjárása mennyire normális (értsd alapértelmezett, vagy én állítottam el valamit, illetve hogy tudnám az OpenWrt routeren, ezt a DHCP továbbítást megszüntetni, letiltani?

  • 4815 megtekintés

( dotnetlinux | 2016. 05. 13., p – 21:39 )

"Alapból nem szabadna onnan DHCP-t kapnia" akartam írni, de észrevettem a DMZ-t. Szép kis hálózat, pont olyan, mint amikor az egy itthoni gépemhez van két szerver és AD-t használnék :)

Viccet félretéve, tiltani kellene a Cisco EPC3925 modem felé menő 67-68-es portokat (UDP). Ebben az esetben az OpenWrt fixIP-s lehet csak (mint ahogy most is van). Port tiltás módja az OpenWRT tűzfalában az alapból nyitott Output irányba egy szabály.

HUP-on gyakran azért írok, mert érdekelnek a miért-ek. Most az a kérdés: Miért van két DHCP? Vendéghálózatod van a kevésbé biztonságos családtagoknak? :)

Persze, de esetemben a Cisco EPC3925-nek mindenképp mennie kell, mivel (coax) kábel modem is egyben, azt meg az OpenWrt alatti hardverem nem tudja.
Amúgy OpenWrt alatt az egyik switch port vlan-nal el van különítve a többitől és van rajta egy harmadik hálózat (guest). Csak ezt direkt nem említettem, mert ezzel már nem akartam ingerelni senkit. :)

Köszönöm válaszod.
Igazából a LAN2-es hálózatom már korábban megvolt aztán cserélték a korábbi modemem erre az újabb Cisco kábel routerre.
Lehet, hogy paranoid, de nem igazán bízok a külső szolgáltató által távolról menedzselhető eszközökben. No meg bármikor cserélhetik egy újabbra. Ezzel a felállással mindig megmarad egy NAT-olt, bekonfigurált tűzfallal védet, belső hálózatom.

A Miért:
Lassan minden smart otthoni cucc hazabeszél, a frissítések hiánya és érdektelenség következtében biztonságilag elavult, sérülékeny szoftvereket futtatnak, talán egy kicsit nyugodtabb vagyok, ha ezek egy külön úgymond külső hálózatba kerülnek.
A LAN1 külső hálózaton most még csak a DMZ-be tett OpenWrt router lóg, de ebbe a hálózatba jöhetnek nyugodtan ahogy te is írtad "a kevésbé biztonságos családtagok", rokonok ismeretlen állapotú eszközei, otthoni smart cuccok. Windows 10-es gépek :)
Ráadásul, így a Cisco EPC3925 wifije meg működhet vendég wifiként.

Sejtettem, hogy valami ilyesmi lesz mögötte...véletlenek nincsenek, épp ma üzemeltük be kollégámnál a régi Wrt54G-met, hogy 5W fogyasztás mellett 5 percenként jelentse az aktuális DNS-t és az otthoni hálózat állapotát...de a kérdésre visszatérve:

Nálam pont ilyen a felállás: szolgáltatói router 192.168.0.x-es hálózaton, Wifi bekapcsolva, látszik is az SSID, gyerekek tabletjei ezen lógnak, ide engedem be a vendégeket is.

Alatt/mögötte egy 192.168.1.x-es hálózat, amely "kliense" a 192.168.0.x-es hálózatnak, egy profibb, N-es dualchannel routerrel van megoldva. Ehhez kapcsolódnak a dolgozós gépek, a TV és az okos(fa)ház, meg a NAS:
- TV: a publikus hálózaton lenne, akkor a barátaim a házunk előtti parkolóból tudnának youtube videot indítani a TV-men, mert szilveszterkor beengedtem a mobiljukat a tv-mre. Köszi.
- Okos(fa)ház: kísérleti céllal (arduino nano, nyák, forrasztás, led lámpák) csináltam egy projektet, amely tele van Iot eszközökkel, a faházban (6nm) van egy 8 portos switch, 13 (!) konnektor és külön notebook a fejlesztéshez, raspberry pi SSD-vel, 4 foglalt IP címmel.

Nos ezek mind a belső hálón lógnak, aminek az SSID-je nem látszik, főleg kábeles eszközök vannak rajta és MAC szűrés.

A mese lényege, hogy kapcsold ki a DMZ-t! A belső háló ne legyen az alapértelmezett kiszolgáló, legyen védett! Te döntsd el, hogy a kívülről jövő szolgáltatások közül miket engedsz be! Ezeket vedd fel port forwarding-gal a szolgáltatói routeren, megcélozva a belső háló szerverét, majd ott még egy forward. (Nekem a raspberry pi-hez, csak a házon belül 3 aktív eszközön megy át a forgalom, de az irodából így is látom, csak konfig kérdése).

DMZ-t lődd ki és legyen ez egy védett alháló. A topológia miatt a belső hálóról (192.168.1.x) látsz mindent ami felette (192.168.0.x) van, a kevésbé biztonságos eszközöket.

Akkor majdnem ugyan az a topológiánk (a DMZ-t leszámítva). Csak Nálad már eldurvultak a dolgok :)

"A belső háló ne legyen az alapértelmezett kiszolgáló, legyen védett"
Az alapértelmezett kiszolgáló alatt mire gondolsz?

Korábban a belső hálóm (OpenWrt-s router) egy szimpla kábelmodem mögött lógott. Úgymond olyan folt mint a mostani Cisco EPC3925 LAN1-es külső hálózat. A modem szolgáltatta a WAN IP címet, az OpenWrt tűzfala és NAT funkciója meg védett a kívülről jövő látogatóktól. Aztán a modemet cseréltek és jött ez a modem-router funkcióval ellátott Cisco EPC3925 csoda. Gondoltam, ha DMZ-be teszem az OpenWrt semmivel sem lesz rosszabb a helyzet a korábbi állapothoz képest, és nem kell forward szabályokat felveni a Cisco-n, meg egyéb dolgokkal szívni.
Biztos biztonságosabb, ha két tűzfalon folyik keresztül a forgalom. Ha azt mondod, hogy OpenWrt-s port forwarding szabályokat megfeleltetem a Cisco routeren és kész, nem lesz más probléma akkor kiveszem a DMZ-ből.

"A topológia miatt a belső hálóról (192.168.1.x) látsz mindent ami felette (192.168.0.x) van"
Ez igaz. De a külső hálózatban lévő eszközök nem látnak be, csak ha belülről néznek rájuk, amire néha szükség lehet. Ilyen esetekhez akár szűrni is lehetne, hogy csak bizonyos IP című eszközök legyenek láthatóak belülről. De javíts ki ha tévedek.

"Az alapértelmezett kiszolgáló alatt mire gondolsz?"
Furcsán fogalmaztam, arra gondoltam, hogy a DMZ miatt minden kérés, ami bejön, elmegy az OpenWRT-re. Ez az "alapértelmezett". Ez túl van egyszerűsítve. Szvsz.

"De a külső hálózatban lévő eszközök nem látnak be, csak ha belülről néznek rájuk, amire néha szükség lehet."
Pont ez a lényeg az alárendelt hálózatokban. Az OpenWrt egy ajtó (mögötte pár másik ajtó), amin eddig bementél. Most eléhúztak egy várót (Cisco), amibe be kell menni és csak ott látszik az OpenWRT ajtó. De ki van kordonozva, hogy a Cisco ajtóból csak az OpenwRT ajtóhoz lehet menni. Kifelé kilincs, befelé gomb van az ajtókon.

Amikor összerakod h mit szeretnél, akkor kell dönteni egy topológiáról, annak minden kellemetlenségével együtt. Nálam a belső háló védelme fontos. Emiatt inkább kézzel konfigolom a port forwarddal azt a pár szolgáltatást, amit ezen el akarok érni.

( gergov | 2016. 05. 14., szo – 07:46 )

Szvsz az a jelenseg oka, hogy az openwrt-s routered portjai hardveresen egyetlen switchez tartoznak, es a LAN es WAN portok elkulonitese VLAN-okkal tortenik. Indulaskor a switch eloszor alap L2 buta switchkent kezd mukodni, csak a boot folyamat egy kesobbi szakaszaban konfigolja megfeleloen az operacios rendszer. Ebben a rovid idoben pedig at tudnak "szivarogni" a DHCP keresek (is) a LAN es WAN portok kozott.

Gergov szerint akkor ez baj lehet a DHCP kiosztásban. De a kliensek (Windows is *nix is) újraindítás után is tárolják a kapott IP címet /release-ig vagy amíg le nem jár. Ha openWRT teljes indulása (2-5sec?) után kapnak címet, akkor a kikapcsolt DMZ miatt biztos, hogy belsőset kapnak.

Másik megoldás lehet, hogy az OpenWRT helyett visszateszed a gyári Wrt54G firmware-t, hogy kis ideig se működjön switch-ként az eszköz.

( AiRLAC v | 2016. 05. 15., v – 17:14 )

Miért nem rakatod a Ciscot bridge módba?

( matatron | 2016. 05. 15., v – 18:47 )

A DMZ megszüntetése, és a tűzfalszabályok sem oldották meg a problémát. Elég lassan indult az OpenWrt-s router, volt hogy már nem is győztem kivárni.
Ma frissítettem a legújabb Chaos Calmer 15.05.1-re, konfig fájlokat sem hagytam meg, mindent újra beállítottam.
Most már sokkal fürgébb az indulás és úgy tűnik a DHCP beszivárgás probléma is megszűnt :)

Hogy mi okozhatta: talán ahogy feljebb gergov és gemnon is írta a switch VLAN kezelésé, vagy esetleg a bootolás során jelentkezett valami probléma, ami megakasztotta az indulást és lehetővé tette a külső DHCP szerver válaszok belső LAN-ra való bejutását.