Johdanto
Kuvaan tässä kotiverkkoni nykyisen konfiguraation omaa dokumentaatiotani varten. Jos konfiguraatiossa on jotain pahasti pielessä, olet tervetullut huomauttamaan asiasta kommenttiosiossa. Verkko koostuu seuraavista laitteista:
- Ubiquiti EdgeRouter X (reititin)
- Netgear GS108Ev3 (hallittava kytkin)
- Ubiquiti UniFi UAP-AC-Lite (langaton AP)
Verkko on jaettu viiteen virtuaalisen lähiverkkoon (VLAN), joiden välisiä yhteyksiä on rajattu reitittimen palomuurisäännöillä. VLAN-verkkojen välinen reititys toteutettiin Router on a stick -tavalla, eli kytkimen ja reitittimen välillä on yksi Trunk-linkki, joka kuljettaa useiden eri VLAN-verkkojen liikennettä ali-interfacejen kautta. Hallittavan kytkimen ja langattoman AP:n välillä on toinen Trunk, joka kuljettaa eri langattomien verkkojen VLAN-liikenteen. Langattomia verkkoja on kokonaisuudessaan kolme.
Kaikki verkkolaitteet ovat samassa ylläpitoverkossa VLAN99. Siirrän henkilökohtaisen koneeni kyseiseen verkkoon ainoastaan, kun minun tulee tehdä muutoksia verkon konfiguraatioon. Muulloin se on täysin erillään kotiverkkoni päätelaitteista.
Verkkolaitteiden ylläpito-osoitteet:
Device | VLAN | IPv4 Address | Subnet Mask | Default Gateway | Description |
---|---|---|---|---|---|
EdgeRouterX | VLAN99 | 10.0.99.1 | 255.255.255.0 | n/a | Maintenance |
NetgearSW | VLAN99 | 10.0.99.100 | 255.255.255.0 | 10.0.99.1 | Maintenance |
UAP-AC-Lite | VLAN99 | 10.0.99.200 | 255.255.255.0 | 10.0.99.1 | Maintenance |
Reititin: Ubiquiti EdgeRouter X
VLAN-verkot:
Hinnastaan huolimatta EdgeRouter X sisältää monia yrityslaitteista tuttuja ominaisuuksia. Reitittimen interfacelle eth1 on luotu viisi virtuaalista ali-interfacea, jotka kuuluvat omiin VLAN-verkkoihinsa. VLAN-verkot jakautuvat seuraavasti:
- VLAN10 – Pyhahima Internal (verkko kodin luotetuille kiinteille laitteille, kuten pöytäkoneelle)
- VLAN20 – Pyhahima Internal WLAN (verkko kodin luotetuille langattomille laitteille, kuten kannettavalle tietokoneelle)
- VLAN30 – Pyhahima IoT (verkko kodin IoT-laitteille: Raspberry Pi, ESP-12E jne.)
- VLAN40 – Pyhahima Guest (vierasverkko)
- VLAN99 – Maintenance (verkon ylläpitoa varten)
Jokaiselle on luotu oma ali-interface eth1-interfacen alaisuuteen. Ali-interfacen numero täsmää VLAN-verkon numeron kanssa:
Esimerkki VLAN10-verkon ja sen ali-interfacen eth1.10 tiedoista:
Reitittimen osoitetaulukko näyttää tältä:
Interface | IPv4 Address | Subnet Mask | Default Gateway | Description |
---|---|---|---|---|
Eth1.10 | 10.0.10.1 | 255.255.255.0 | N/A | Pyhahima Internal (VLAN10) |
Eth1.20 | 10.0.20.1 | 255.255.255.0 | N/A | Pyhahima Internal WLAN (VLAN20) |
Eth1.30 | 10.0.30.1 | 255.255.255.0 | N/A | Pyhahima IoT (VLAN30) |
Eth1.40 | 10.0.40.1 | 255.255.255.0 | N/A | Pyhahima Guest (VLAN40) |
Eth1.99 | 10.0.99.1 | 255.255.255.0 | N/A | Maintenance (VLAN99) |
Reititin loi itse automaattisesti reitityssäännöt verkkoja varten:
DHCP:
Jokaiselle VLAN-verkolle on luotu omat DHCP-poolit, joista ne jakavat IP-osoitteet verkkoon kuuluville päätelaitteille. Esimerkki VLAN10-verkon DHCP-poolista:
Kaikki DHCP-poolit:
DHCP Pool | Subnet | Range Start | Range Stop | Network |
---|---|---|---|---|
VLAN10-Pyhahima-Internal-DHCP | 10.0.10.0/24 | 10.0.10.5 | 10.0.10.254 | Pyhahima Internal |
VLAN20-Pyhahima-Internal-WLAN-DHCP | 10.0.20.0/24 | 10.0.20.5 | 10.0.20.254 | Pyhahima Internal WLAN |
VLAN30-Pyhahima-IoT | 10.0.30.0/24 | 10.0.30.5 | 10.0.30.254 | Pyhahima IoT |
VLAN40-Pyhahima-Guest | 10.0.40.0/24 | 10.0.40.5 | 10.0.40.25 | Pyhahima Guest |
VLAN99-Maintenance | 10.0.99.0/24 | 10.0.99.5 | 10.0.99.25 | Maintenance |
Palomuuri:
VLAN-verkkojen ali-interfaceihin on myös konfiguroitu palomuurisäännöt, jotka rajoittavat pääsyä tietyistä verkoista toisiin. Verkot saavat liikennöidä sisäverkossa seuraavasti:
- VLAN10: Pääsy VLAN20.
- VLAN20: Pääsy VLAN10.
- VLAN30: Ei pääsyä muihin VLAN-verkkoihin.
- VLAN40: Ei pääsyä muihin VLAN-verkkoihin.
- VLAN99: Pääsy VLAN10, 20, 30 ja 40.
Jokaista VLAN-verkkoa varten on luotu uusi sääntölista (ruleset), joiden oletustoiminto on pudottaa paketit (drop).
VLAN10 sääntölista:
- Listan ensimmäinen sääntö sallii kaikki protokollat, joiden tila on joko “Established” tai “Related”. “Established” tarkoittaa kaikkea sitä liikennettä, joka on jo assosioitu johonkin olemassa olevaan yhteyteen, jossa liikennettä on kulkenut molempiin suuntiin. “Related” tarkoittaa kaikkea sitä liikennettä, joka on seurausta uudesta yhteydestä, mutta joka on assosioitu jo olemassa olevaan yhteyteen liittyväksi.
- Listan toinen sääntö sallii kaikki protokollat verkosta 10.0.99.0/24, eli ylläpitoverkosta (VLAN99), jolla on pääsy kaikkiin muihin VLAN-verkkoihin.
- Listan kolmas sääntö sallii kaikki protokollat verkosta 10.0.20.0/24, eli luotetusta langattomasta lähiverkosta Pyhahima Internal WLAN (VLAN 20).
VLAN20 sääntölista:
VLAN20 sääntölista on lähes identtinen VLAN10:n kanssa, mutta tässä kolmas sääntö sallii kaikki protokollat verkosta 10.0.10.0/24, eli luotetusta kiinteästä lähiverkosta Pyhahima Internal (VLAN10). VLAN10 ja 20 voivat siis kommunikoida esteettä keskenään.
VLAN30 sääntölista:
- Listan ensimmäinen sääntö sallii kaikki protokollat, joiden tila on joko “Established” tai “Related”.
- Listan toinen sääntö sallii kaikki protokollat verkosta 10.0.99.0/24, eli ylläpitoverkosta (VLAN99), jolla on pääsy kaikkiin muihin VLAN-verkkoihin.
VLAN40 sääntölista:
VLAN40 sääntölista on identtinen VLAN30:n kanssa. Säännöissä ei ole eroa.
VLAN99 sääntölista:
- Listan ensimmäinen sääntö sallii kaikki protokollat, joiden tila on joko “Established” tai “Related”.
- Muita sääntöjä ei tarvita, sillä pääsyä ylläpitoverkkoon muista verkoista ei ole.
Lopuksi kukin sääntölista määriteltiin toimimaan kunkin VLAN-verkon ali-interfacessa seuraavan esimerkin mukaisesti:
Eli VLAN10:n sääntölistan mukaiset säännöt pätevät kaikkeen eth1.10-interfacelta ulospäin suuntautuvaan (outbound) liikenteeseen. Kyseessä on siis se liikenne, joka lähtee reitittimen virtuaalisesta interfacesta eth1.10 kyseistä VLAN10-verkkoa kohti (reitittimeltä VLAN10-verkon laitteille).
HUOM: Jotta kykenin testaamaan VLAN-verkkojen välisiä sääntöjä, jouduin ottamaan Windows 10:n palomuurin pois molemmilta eri verkoissa VLAN 10 ja 20 olevilta testikoneilta. Ilmeisesti Windowsin palomuuri estää oletuksena paketit verkoista, jotka eivät ole samassa sisäverkossa. Windowsin palomuuria varten tulee siis tehdä omat säännöt.
Hardware Offloading:
Reitittimessä on otettu laitteistopohjainen offloading käyttöön. Tällöin reititin suorittaa toimintojaan suoraan fyysistä rautaansa hyödyntäen, eikä ohjelmallisesti pelkän prosessorin toimesta.
Toiminto otettiin käyttöön SSH-yhteydellä seuraavia komentoja käyttäen:
configure set system offload hwnat enable commit save exit
Reitittimen hallinnan rajoittaminen
Oletuksena reitittimen hallintaan pääsee käsiksi kaikkien VLAN-verkkojen default gateway -osoitteista sekä reitittimen julkisesta IP-osoitteesta. Webhallinta ja SSH-yhteydet kannattaa rajoittaa siten, että niihin päästään vain hallintaverkon interfacen IP-osoitteesta.
Määritykset otettiin käyttöön SSH-yhteydellä seuraavia komentoja käyttäen:
configure set service gui listen-address 10.0.99.1 set service ssh listen-address 10.0.99.1 commit save
Nuo muutokset tarkoittavat sitä, että graafiseen käyttöliittymään ja SSH-yhteyteen pääsee ainoastaan eth1.99-interfacen IP-osoitteen 10.0.99.1 kautta. Tuo siis estää pääsyn julkisesta verkosta, mutta ei vielä rajoita yhdistämistä sisäverkon toisesta VLAN:ista, kunhan käyttäjä vain tietää oikean IP-osoitteen. Täydellinen eristys edellyttäisi vielä LOCAL-palomuurisäännöt kunkin VLAN-verkon interfacea varten, sillä tekemäni palomuurisäännöt interfaceihin (eth1.XX/OUT) eivät estä suoraan itse interfacelle kohdistuvaa liikennettä.
Kytkin: NetGear GS108E-300PES
Kytkimen portit on konfiguroitu NetGearin ProSafe Plus Configuration Utilityn kautta seuraavasti:
Port | Mode | VLANs (T/U) |
---|---|---|
1 | Access | VLAN10 (Untagged) |
2 | Access | VLAN10 (Untagged) |
3 | Access | VLAN10 (Untagged) |
4 | Trunk | VLAN20 (Tagged) VLAN30 (Tagged) VLAN40 (Tagged) VLAN99 (Untagged) |
5 | Access | VLAN30 (Untagged) |
6 | Access | VLAN30 (Untagged) |
7 | Access | VLAN 99 (Untagged) |
8 | Trunk | VLAN10 (Tagged) VLAN20 (Tagged) VLAN30 (Tagged) VLAN40 (Tagged) VLAN99 (Tagged) |
Eniten ongelmia tuotti portin 4 konfigurointi, joka toimi Trunk-porttina ja oli kiinni langattomassa AP:ssa. Ubiquitin UniFi UAP-AC-Litellä oli VLAN99-verkon IP-osoite 10.0.99.200. Siihen ei saatu yhteyttä UniFi Controller -ohjelmistosta, joka oli asennettu samassa verkossa olleelle pöytäkoneelle. Aluksi kaikkiin portin 4 VLAN-verkkoihin oli laitettu 802.1Q VLAN -tagit. UniFi AP ei kuitenkaan ollut itse tietoinen siitä, mihin VLAN-verkkoon sen tulisi kuulua, eikä siltä kytkimelle lähtevä liikenne siten kuulunut mihinkään VLAN-verkkoon. Ongelma korjaantui poistamalla tagi VLAN99-verkon liikenteestä kyseisessä Trunk-portissa 4. Sitten portin 4 PVID:ksi asetettiin 99 (native VLAN). Tällöin kaikki liikenne, jossa ei ole tagia, katsotaan kuuluvan native VLAN99:een. Yhteys UniFi Controllerin ja AP:n kanssa alkoi muutoksen jälkeen toimimaan.
VLAN-verkot eri porteissa:
PVID-asetukset kullekin portille (native VLAN):
Langaton AP: Ubiquiti UniFi UAP-AC-Lite
Ubiquiti UniFi UAP-AC-Liten AP on konfiguroitu pöytäkoneelle asennetun UniFi Controller -ohjelmiston kautta. Laitteelle on annettu staattinen IP-osoite VLAN99-verkosta.
Langattomalle AP:lle on luotu kolme WLAN-verkkoa, joista jokainen kuuluu omiin VLAN-verkkoihinsa:
Esimerkki Pyhahima Internal WLAN -verkon asetuksista:
Mielenkiintoinen teksti ja auttoi jonkin verran tuossa verkon asettelussa. Tuli hankittua Ubiquiti UniFi Security Gateway -reititin eikä verkko sen jälkeen oikein toimi. Onko kokemusta Security Gateway tuotteesta
Hei,
Ei valitettavasti ole kokemusta. EdgeRouterilla on oma hallintakäyttöliittymänsä, kun taas UniFi Security Gatewayta hallitaan UniFi Controllerin kautta. On vaikea kommentoida, miksi verkko ei toimi USG:n kanssa tietämättä tarkempia tietoja konfiguraatiosta. Vika tulisi kuitenkin rajata systemaattisesti johonkin tiettyyn konfiguraation komponenttiin, palomuurisääntöön tms. Esimerkiksi:
– Saako reititin julkisen IP-osoitteen operaattorin DHCP-palvelimelta?
– Reitittääkö mikään sisäverkon laite reitittimen kautta julkiseen internettiin?
– Reitittävätkö sisäverkon laitteet keskenään?
– Reitittivätkö sisäverkon laitteet ylipäätänsä reitittimelle asti?
– Onko verkko segmentoitu useaan virtuaaliseen lähiverkkoon (VLAN), ja jos kyllä, niin miten ne on määritetty liikennöimään keskenään?
– Onko välissä hallitsematon tai hallittu kytkin? Jos laitat päätelaitteen kiinni suoraan reitittimeen ja jätät kytkimen välistä, toimiiko yhteys tuolloin?
– Oletko testannut yhteyttä pingaamalla vain IP-osoitetta, jotta tiedät, ettei kyse ole vain nimipalvelun (DNS) toimimattomuudesta?
Oheiselta Ubiquiti-foorumilta voi yrittää kysellä lisäneuvoja ja siellä varmasti voidaan opastaa tarkemmin: https://community.ui.com/questions
Moi – ilahduin kun löysin suomenkielisen sivustosi. Olen hankkimassa Ubiquiti EdgeRouter X -reitittintä. Haluan parantaa kotiverkkomme suojausta erillisellä palomuurilla. Mutta, minulla ei ole it-alan osaamista. Siksi olen etsinyt netistä helppoa ymmärrettävää tietoa Ubiquiti-tyyppisen palomuurireitittimen asentamisesta tai pitäisikö puhua konfiguroimisesta. Tai oikeastaan etsin ihan selkeää perustietoa mitä pitää ottaa huomioon kun tällainen palomuuri otetaan käyttöön. Opastaako laitteen asennusohjelmisto mitä pitää tehdä? Kotiverkossamme on kiinteässä yhteydessä pari Applen kannettavaa, Android-televisio, Linux-pohjainen tallentava digiboksi ja wifinä Applen Airport Express. Myös pesukoneemme on wifi-yhteydessä kun sitä käytetään. Yhteys ulkomaailmaan tapahtuu kuituverkon avulla.
Kiitos Markus detaljeista ohjeista!
Rakensin niihin pohjautuen taloyhtiöömme DNA Koti5G-yhteydenjaon.
Koska halusin itselleni kaksi eth-porttia (toinen sisään ja toinen varastoon palvelimeen) jouduin käyttämään switch0, jonka konfiguroin “VLAN awareksi”, käytännössä muuten sama, mutta eth1 ja eth2 niputettiin switch0:n alle, jotta niihin sai levitettyä halutut VLANit.
Seuraavaksi homma jatkuu Ubiquiti AP Liten saapuessa WLAN konfiguroinnilla.
Pienen lisäyksen suosittelen tekemään, nimittäin lisäämään Firewall/NAT osioon masqueraden eli source NATin sisäverkon liikenteelle, jotta liikenne sisältä toimii myös ulospäin.
Käytössäni on Ubiquitin 5- ja 8-porttisia kytkimiä ja niiden VLANien määrittely tuotti hieman tuskaa, mutta lopulta sekin selvisi, miten portit pitää konfiguroida Trunkiksi ja management Laniksi, jotta ne saa näkyviin Ubiquitin Controlleriin.
Moi Markus!
Satuitko juuri aiemmin päivittämään kotisivuasi, kun ei latautunut ollenkaan 🙂 Ja nyt on hiukan eri taitto. Eilen siis löysin sivusi ensimmäistä kertaa. Joka tapauksessa kiitos hyvästä artikkelista! Kaivoin varastojen kätköistä Edge-reitittimen takaisin käyttöön ja voin sanoa, että alkoi olla tuskaa säätää muurisääntöjä, kun en millään meinannut päästä kärryille logiikasta. En vieläkään oikein niitä tajua, mutta näyttämilläsi out-säännöillä sain kotiverkkoni vlanit juttelemaan oikein keskenään.
Yksi kysymys eli mitä vlanisi 1. sääntö siis tekee, eli kun olet määritellyt protocol = all ja action = accept? Ensiksi ajattelin, että sallitaan kaikki, mutta kun ei ole IP-osoitetta määritetty, niin se ei kuitenkaan päästä läpi? Ja seuraavissa säännöissä annetaan IP:t mitkä saavat luvan?
Hei Harri,
Pahoittelut viiveestä vastauksen kanssa. Minulla on ollut sivuston uusimisprojekti pitkään kesken aikataulukiireiden vuoksi, ja siksi reagoin myös kysymykseesi myöhässä.
VLAN-verkkojen ensimmäinen sääntö ei kieltämättä selviä kuvankaappauksista selkeästi. Sääntö on määritetty seuraavin määrityksin:
Action: Accept
Protocol: All protocols
State: Established, Related
Se ei siis salli kaikkea liikennettä, vaan ainostaan kaiken sellaisen liikenteen, jonka tila on joko “Established” tai “Related”. Sääntö ei kohdistu mihinkään aiemmin tuntemattomaan liikenteeseen, sillä liikenteen tila ei voi olla kumpikaan edellä mainituista, ellei liikenne ole jo ensin sallittu jonkin toisen palomuurisäännön toimesta (muuten tila olisi “New”). Säännön toiminta perustuu siihen, että EdgeRouter on tilallinen palomuuri. Et normaalisti näkisi vastaavaa sääntöä perinteisen tilattoman palomuurin sääntölistalla.
Käyttäjä “waterside” selittää säännön logiikan aika Ubiquitin foorumeilla hyvin tässä ketjussa: https://community.ui.com/questions/Allow-Established-Related-Good-practice-to-have-source-destination/96d06bf4-cd1c-4725-a73a-fba4a474046b. Toivottavasti tämä selkeytti asiaa.
Mielenkiintoinen teksti ajatellen oamn ympäristön IoT- ja Guest-verkkojen eriyttämistä, kiitos.
Yksi huomio omasta ympäristöstä.. Otin reitittimen Wireguard-VPN:n käyttöön ja ihmettelin pitkään sen huonoa suorituskykyä. Kunnes puolittain vahingossa keksin laittaa “system offload hwnat” -toiminnan pois päältä.