Kokemuksia Ubiquitin reitittimistä (ja muista verkkovermeistä).

Äkkiä sen controllerin paras ominaisuus on se että se hihkaisee heti jos se näkee vieraan wifi tukiaseman samalla nimellä ilmestyvän kuuluvuusalueelle, muuten se on vähän meh...

No milloin noin kotona tapahtuisi? :D Siis joku naapuri pistäis saman ssid:n näkyville, on ainut mahdollisuus? Olis kyllä paskamainen naapuri.
 
No milloin noin kotona tapahtuisi? :D Siis joku naapuri pistäis saman ssid:n näkyville, on ainut mahdollisuus? Olis kyllä paskamainen naapuri.
Tuohan on siis yksi tapa koittaa haistella liikennettä, kotikäytössä ei liene erityisen todennäköinen skenaario, mutta onhan se nyt mahdollista jos esim duunin puolesta jotain riittävän mielenkiintoista tekee, niissä tapauksissa kun se konttori on todennäköisesti paremmin suojattu.

Pointti olikin että siitä kontrollerista ei ole kovinkaan kummoista hyötyä kotikäytössä, ts. se softakontrolleri pelkkään konffimiseen riittää ihan hyvin.
 
Tyhmänä vielä kyselen virtuaalisista laneista. Toimiiko kuvio niin että voin määrittää Unifin security gatewaylle ja Unifin 8-porttiselle poe-switchille porttikohtaiset vlan määritykset? Jos portin taakse taas kytketään muun valmistaja tyhmä kytkin, niin jokainen tyhmän kytkimen portti jakaa sitä Unifin laitteen portissa määriteltyä vlania?
Ja jos haluan periyttää erilaisia vlan-määrityksiä per portti ihan laiteliitäntään asti, niin kytkin pitää olla hallittava versio ja mielellään Unifi jos haluaa yhdestä paikasta koko ketjua hallita?
 
Nyt on hankittuna security gateway. Ajattelin kytkeä toistaiseksi modeemin ja google wifin väliin palomuuraamaan. Jännittävää. Jossakin kohtaa sitten katsoa poe-kytkintä ja tukiasemia. Homma etenee.
 
Security gateway asennettu. Olipa säätöä, että sai toimimaan Huawei-modeemin ja Google Wifin välissä. No mutta nyt vihdoin toimii.

Yritin saada Unifi Contollerin...anteeksi Unifi Network -sovelluksen (nimi vaihtunut) toiminaan mutta käynnistyttyään listaa 192.168.1.1 verkon, vaikka Unifin verkko on 192.168.8.1 (muutin sen käsin siis toiseksi). Selaimella näen nämä muutamat verkon perusasetukset, mutta sovelluksessa sitten ei oikeita tietoja ole lainkaan. Oletan että homma kyrvähtää siihen, että Network-sovellus on nyt työasemalla jonka ip on saatu Google Wifi dhcp:ltä/verkosta 192.168.86.X, kun taas security gateway istuu 192.168.8.1 osoitteessa. On tämä helppoa ja kivaa. :) Pitää varmaan huomenna jaksaa laittaa verkkokaapeli gatewayhin suoraan kiinni ja sitten kokeilla mitä Network-softa sanoo.

EDIT: ja LAN2/WAN2 -portti ei ole oletuksena ilmeisesti konfattuna, joten pitää kytkeytyä LAN1-porttiin käyttöönottaakseen toisen portin laitteesta käyttöön.
 
Viimeksi muokattu:
Security gateway asennettu. Olipa säätöä, että sai toimimaan Huawei-modeemin ja Google Wifin välissä. No mutta nyt vihdoin toimii.

Yritin saada Unifi Contollerin...anteeksi Unifi Network -sovelluksen (nimi vaihtunut) toiminaan mutta käynnistyttyään listaa 192.168.1.1 verkon, vaikka Unifin verkko on 192.168.8.1 (muutin sen käsin siis toiseksi). Selaimella näen nämä muutamat verkon perusasetukset, mutta sovelluksessa sitten ei oikeita tietoja ole lainkaan. Oletan että homma kyrvähtää siihen, että Network-sovellus on nyt työasemalla jonka ip on saatu Google Wifi dhcp:ltä/verkosta 192.168.86.X, kun taas security gateway istuu 192.168.8.1 osoitteessa. On tämä helppoa ja kivaa. :) Pitää varmaan huomenna jaksaa laittaa verkkokaapeli gatewayhin suoraan kiinni ja sitten kokeilla mitä Network-softa sanoo.

EDIT: ja LAN2/WAN2 -portti ei ole oletuksena ilmeisesti konfattuna, joten pitää kytkeytyä LAN1-porttiin käyttöönottaakseen toisen portin laitteesta käyttöön.
Onko joku syy miksi Google Wifi jakaa IP-osoitteita? Eikö järkevin konffi olisi, että Huawei on sillattuna, USG hoitaa reitityksen ja Google Wifi on pelkkä tukiasema (access point / AP).
 
Onko joku syy miksi Google Wifi jakaa IP-osoitteita? Eikö järkevin konffi olisi, että Huawei on sillattuna, USG hoitaa reitityksen ja Google Wifi on pelkkä tukiasema (access point / AP).

Joo, mutta silloin menettä googlen meshin. En osaa veikata kuinka paljon tuo mesh parantaa verkon käyttökokemusta, joten en uskaltanut mennä tuota muuttamaan.
Eikös tuo sitten toimisi niin, että USG jakaa dhcp:ltä omaa aluettaan, ja jokainen bridged moodissa oleva google ap edelleenjakaa sitä samaa dhcp-poolia?

Niin ja toimiiko jokaisen ap:n lan-portit vielä muutoksen jälkeen?
 
Joo, mutta silloin menettä googlen meshin. En osaa veikata kuinka paljon tuo mesh parantaa verkon käyttökokemusta, joten en uskaltanut mennä tuota muuttamaan.
Eikös tuo sitten toimisi niin, että USG jakaa dhcp:ltä omaa aluettaan, ja jokainen bridged moodissa oleva google ap edelleenjakaa sitä samaa dhcp-poolia?

Niin ja toimiiko jokaisen ap:n lan-portit vielä muutoksen jälkeen?


Herää kysymys, että miksi tuo usg on ylipäätään laitettu? Se on siis reititin, ja sinulla reitityksen hoitaa Google wifi? Google sisältää uskoakseni myös palomuurin, eli usg on tuossa nyt aivan turha. Jos haluat sitä käyttää pelkästään palomuurina, niin kytke siitä vähintään dhcp-palvelin pois.
 
USG on reititin ja palomuuri. Tuolla aiemmin kommentoin, että on itselleni kestämätön tilanne käyttää Googlen palomuuria josta ei näe mitään ja jolla ei voi teknisesti tehdä mitään. Nyt välissä on USG-palomuuri, josta aion jatkossa ottaa teknisesti enemmän irti palomuurauksen ja aliverkotuksen osalta. Ja on välissä Googlen palomuuri vielä myös, kun sitä ei voi kytkeä pois päältä kääntämättä Googlen reititintä (yhtä purkkia) sillaksi. Jos kääntää sillaksi, niin mesh katoaa ja jokainen google purkki on siitä hetkestä eteen päin standalone ap.

Viittasitko Googleen vai USG:hen tuossa kun puhuit "kytke siitä vähintään dhcp-palvelin pois"?
Jos tarkoitit Googlea, niin tosiaan mesh katoaa jos tuon muutoksen tekee.
Jos tarkoitus USG:tä, niin se kai olisi tässä tapauksessa mahdotonta.
 
USG:stä dhcp pois. Miksi se olisi mahdotonta? Nyt sinulla on kaikki laitteet tupla-NATin takana.

Eli tällä hetkellä USG on turha. Jatkossa pystyt sitä hyödyntämään kun hankkiudut Google Wifistä eroon.
 
USG:stä dhcp pois. Miksi se olisi mahdotonta? Nyt sinulla on kaikki laitteet tupla-NATin takana.

Eli tällä hetkellä USG on turha. Jatkossa pystyt sitä hyödyntämään kun hankkiudut Google Wifistä eroon.

Modeemi on sillattu. Modeemista lanka menee USG:lle. USG:llä dhcp-pooli, josta jaetaan Googlen reitittimelle yksi ip-osoite, jolla Googlen koko mesh-palvelun on mahdollista näkyä USG:lle. Googlen reititin jakaa omaa aliverkkoaan päätelaitteille.
Jos USG:stä ottaa dhcp:n pois, niin miten tuo muuttaa USG:n roolia modeemin ja Googlen reittimen välissä? Ja mä en kysy tätä vittuillakseni, vaan siksi kun en ymmärrä.

Ja tänne on tulossa nippu Unifin kytkintä ja tukaria kunhan vaan postimies tuo. Siihen menee tosin aikaa ja nyt eletään tällä viritelmällä jossa uutena palasena ketjun väliin on tullut USG palomuurin ja reitittimen roolissa.
 
Tarkemmin sanottuna myös NAT pitäisi kytkeä USG:stä pois, mutta tuo ei ole ihan yksinkertainen temppu. Nyt sinulla on tupla NAT ja tupla DHCP tilanne kotiverkossasi. Nettiyhteys suurimmaksi osaksi varmaan toimii, mutta tietyt palvelut eivät toimi. Googlaamalla double NAT ja double DHCP saat lisätietoa.
Käytännössä nyt Googlen NAT ei toimi, koska se ei saa ulkoverkon IP osoitetta.

Modeemin olet kuitenkin laittanut siltaavaksi, eli kytkenyt siitä NAT:n (ja DHCP:n) pois päältä, jotta netti toimisi oikein. Lisäämällä väliin USG:n NAT:n kerjäät ainoastaan ongelmia.

Toivottavasti sait ajatuksesta kiinni...
 
Tarkemmin sanottuna myös NAT pitäisi kytkeä USG:stä pois, mutta tuo ei ole ihan yksinkertainen temppu. Nyt sinulla on tupla NAT ja tupla DHCP tilanne kotiverkossasi. Nettiyhteys suurimmaksi osaksi varmaan toimii, mutta tietyt palvelut eivät toimi. Googlaamalla double NAT ja double DHCP saat lisätietoa.
Käytännössä nyt Googlen NAT ei toimi, koska se ei saa ulkoverkon IP osoitetta.

Modeemin olet kuitenkin laittanut siltaavaksi, eli kytkenyt siitä NAT:n (ja DHCP:n) pois päältä, jotta netti toimisi oikein. Lisäämällä väliin USG:n NAT:n kerjäät ainoastaan ongelmia.

Toivottavasti sait ajatuksesta kiinni...

Lähiverkko ja internet toimii ihan yhtä hyvin kuin UAGittomassa toteutuksessa. En huomannut mitään eroa vaikka yksi hoppi väliin tuli. Olin olettanut, että muutaman millisekunnin kasvaminen voisi ehkä näkyä selainkäytössä, mutta kaikki toimii hyvin. Kaikki palvelut toimivat normaali verkkokäytössä ja kotiautomaatiossakin edelleen sisäverkosta internetiin asti.

Tuplanat välissä on, mutta siitä ei ole mahdollista päästä eroon. Se on asia minkä kanssa pitää hetki elää, tosin kun se ei näytä tuottavan ympäristössä mitään ongelmia. Tupla dhcp:kin välissä on, mutta eihän tuo dhcp tuo väliin kuin lease-ajan päättymisen aikaisen katkon, joka ei pitäisi näkyä loppukäyttäjälle asti. Vaihtoehto olisi kytkeä dhcp pois ja laittaa staattinen ip, mutta sillä voitetaan ainoastaan dhcp-liisauksen uusiminen yhdelle osoitteelle.

Modeemi on siltaavana, koska muuten välissä olisi tosiaan triplanat. Tuon pystyi kytkemään pois ja paljastamaan julkisen ip:n aina UAG:n reunalle asti.

En siis näe mitään ongelmaan mikä tästä kombinaatiosta olisi minulle nyt syntynyt. Se mitä tässä nyt aion jatkossa tehdä kun unifin kikkareet saapuvat:
- unifin kytkin USG:n kiinni
- kytkimeen unifin wifi6 tukarit kiinni
- kytkimeen google wifi tukarit kiinni (ajattelin käyttää googlen ap:ta, jos nämä siltaavana toimivat kun meshin käyttö loppuu)
 
Miksi siitä googlen palikasta hajoaa mesh jos dhcp:n sammuttaa?? :hmm: Vai onko tuo jokin bugi siinä?
 
Miksi siitä googlen palikasta hajoaa mesh jos dhcp:n sammuttaa?? :hmm: Vai onko tuo jokin bugi siinä?

Dhcp:tä ei saa pois ennen kuin muuttaa pömpelin sillatuksi. Tällöin mesh kuolee ja jokainen ap on oma sillattu laitteensa,. Tohon mä en ole vielä valmis kun en osaa arvioida miten paljon tuo mesh parantaa dataperheen käyttökokemuksia.
 
ennen kuin muuttaa pömpelin sillatuksi. Tällöin mesh kuolee ja jokainen ap on oma sillattu laitteensa,. Tohon mä en ole vielä valmis kun en osaa arvioida miten paljon tuo mesh parantaa dataperheen käyttökokemuksia
Oletettavasti se reititin-moodissa oleva purkki toimii kontrollerina ja 802.11kv:n avulla koordinoi clienteja parhaimpiin google wifi -"pisteisiin"
 
Mikä logiikka USG:n dhcp:ssä on. Mulla on lan1 ja lan2 portti kytketty käyttöön. Molemmissa on dhcp päällä ja kummassakin omat aliverkkonsa:
LAN1 192.168.8.0/24
LAN2 192.168.9.0/24

dhcp-poolit 192.168.x100 - 150 kummallekin aliverkolle omansa.

Johto kiinni porttiin, läppäri ei saa alueelta kummastakaan portista ip-osoitetta automaattisesti.
Jos muutan käsin osoitteen lan1 portissa 192.168.8.5 (vaikkapa), niin homma toimii. Sama toisessa portissa esim. osoittella 192.168.9.49.

Onko tuolla vielä joku vipu, millä dhcp pitää vielä jotenkin nytkästä päälle?

EDIT: olin liian hätäinen. Kyllähän tuolta osoite tulee, mutta kestää vain yli 30sek ennen kuin osoite on käytössä. Tuossa ajassa ehtii jo avaamaan verkkosovittimen asetukset ja tekemään ties mitä. Toivottavasti ei ole ominaisuus, vaan johtuu nykyisestä installaatiosta yms.
 
Viimeksi muokattu:
Hei,

hommasin EdgerouterX:n ja nyt pitäisi saada toimimaan IPv6 DNA:n kaapeliverkossa. Tein tämän ohjeen mukaisesti: DNA Welho cable modem IPv6 with Ubiquiti EdgeMax | Juho Garo Mäkinen's blog mutta silti ei IPv6 kuso kulje clienteilta internetttiin päin, esim. kaikki "test ipv6" sivut feilaa.
Sitä vastoin Edgerouterilla IPv6 ping menee hienosti läpi esim. google.comiin.

Mitähän tässä nyt mättää? Jokin helppo palomuuriasetus vai onko tuo ohje vanhentunut?

ps. vanha TP-Link Edgerouterin tilalla toimi hienosti IPv6 osalta...
 
Hei,

hommasin EdgerouterX:n ja nyt pitäisi saada toimimaan IPv6 DNA:n kaapeliverkossa. Tein tämän ohjeen mukaisesti: DNA Welho cable modem IPv6 with Ubiquiti EdgeMax | Juho Garo Mäkinen's blog mutta silti ei IPv6 kuso kulje clienteilta internetttiin päin, esim. kaikki "test ipv6" sivut feilaa.
Sitä vastoin Edgerouterilla IPv6 ping menee hienosti läpi esim. google.comiin.

Mitähän tässä nyt mättää? Jokin helppo palomuuriasetus vai onko tuo ohje vanhentunut?

ps. vanha TP-Link Edgerouterin tilalla toimi hienosti IPv6 osalta...

Vastaan itse itselle että tämä lähti jostain mystisestä syystä nyt toimimaan... Mikähän tähän on syynä, sitä en tiedä. Joku valistuneempi voi vastailla jos osaa lonkalta heittää.
 
Asensin läppärille (piuhalla kiinni kytkimessä) UniFi Controllerin, jonka avulla konffasin kytkimen (USW-Lite-8-PoE) ja AP:n (U6-Lite).

Asensin sitten seuraavaksi omalla pöytäkoneelle (wifi yhteys) tuon saman Controllerin, mutta kun sen käynnistää, niin laitteista ei esimerkiksi näy mitään dataa. Läppärillä laitettu wifi kuntoon, mutta senkään asetukset eivät esimerkiksi näy pöytäkoneen controllerissa.

1630861312530.png


Molempiin asennuksissa käytetty tuota Ubiquitin globaalia käyttäjätunusta, jolla voidaan esimerkiksi kirjautua UniFi Network Portal

Kun läppärin contolleri pyörii niin voin kirjautua siihen pöytäkoneella olloin kaikki toimii normaalisti.

Mitäs mä en nyt ymmärrä / teen väärin?
 
Laitteet on naitettuna siihen läppärille asentamaasi controlleriin. Homma ei toimi niin, että controllereita asennetaan sinne tänne vaan niitä on yksi (erillinen softa tai cloudkey) joka on koko ajan, tai tarvittaessa käynnissä.
 
Hei apuja vlanittamiseen. Kertokaas karkea peruslinjaus vlan-roolien välillä, menisikö jotenkin näin:

- kamerat omaan
- lukot omaan
- lan omaan
- vieraat omaan
- iot omaan

Ja jos menisi niin mitä iotiin kannattaa laittaa. Jos laitteina esim hue bridge, google home kaiuttimet, robotti imuri ja smartthings hubi, niin onko kaikki iotia vai onko kotiautomaatiohubi syytä sijoittaa johonkin muuhun vlaniin tai jopa perus-laniin?
 
Hei apuja vlanittamiseen. Kertokaas karkea peruslinjaus vlan-roolien välillä, menisikö jotenkin näin:

- kamerat omaan
- lukot omaan
- lan omaan
- vieraat omaan
- iot omaan

Ja jos menisi niin mitä iotiin kannattaa laittaa. Jos laitteina esim hue bridge, google home kaiuttimet, robotti imuri ja smartthings hubi, niin onko kaikki iotia vai onko kotiautomaatiohubi syytä sijoittaa johonkin muuhun vlaniin tai jopa perus-laniin?
Itse laittaisin kaikki IoT-laitteet samaan VLAN:iin, olipa kyse Hue:sta, lukoista, vieraiden laitteista, kameroista (olettaen että juttelevat nettiin?) tai ties mistä. Tuon VLAN:in voi rajoittaa juttelemaan vain internetin suuntaan, ilman että laitteet voivat jutella keskenään sisäverkon sisällä. VLAN:ien määrää kannattaa pitää minimissään.

1 VLAN sisäverkolle, 2. VLAN IoT:lle sis vierasverkot yms., tarvittaessa 3. VLAN esim kameroille jos kyseessä ovat sisäverkossa toimivat kamerat ja jostain syystä niiden pitäminen 1.:ssä VLAN:issa on riski.
 
Jos kaikki IoT laitteet on samassa VLANissa, kytkentäisessä verkossa ne voi keskustella keskenään. Itse blokkaisin nimenomaan liikenteen internettiin, ihan yksityisyys jne. asioiden takia. "Oikea" tapa tuohon olisi tehdä hyppykone/proxy/VPN, jonka kautta juttelee tarvittaessa ulkomaailmasta IoT laitteiden kanssa. Lisäksi ehdottomasti erillinen verkko muulle atklle jne, jotta eivät näy noille IoT laitteille.
 
Jos kaikki IoT laitteet on samassa VLANissa, kytkentäisessä verkossa ne voi keskustella keskenään. Itse blokkaisin nimenomaan liikenteen internettiin, ihan yksityisyys jne. asioiden takia.
IoT-laite ilman internetiä, hmm... [toim. huom. IoT = internet of things).

Kiinalaiset web-kamerat yms., joita käytetään vain lähiverkon kautta kyllä blokkaisin internetiin pääsemästä. Sitten ne eivät enää olekaan IoT-laitteita
 
Jos kaikki IoT laitteet on samassa VLANissa, kytkentäisessä verkossa ne voi keskustella keskenään. Itse blokkaisin nimenomaan liikenteen internettiin, ihan yksityisyys jne. asioiden takia. "Oikea" tapa tuohon olisi tehdä hyppykone/proxy/VPN, jonka kautta juttelee tarvittaessa ulkomaailmasta IoT laitteiden kanssa. Lisäksi ehdottomasti erillinen verkko muulle atklle jne, jotta eivät näy noille IoT laitteille.
Osa IoT-laitteista ei välttämättä toimi lainkaan mikäli eivät saa yhteyttä internettiin. Tuntematta laitteita sen tarkemmin, jo rajaamalla sen etteivät voi liikkua sisäverkossa takaa huomattavasti paremman tietoturvan.

Nuo "kiinakamerat" yms laitteet jotka toimivat pelkästään sisäverkossa kannattaa rajata @mikajh ehdotuksen mukaan, eli WAN/internet/ulkomaailma on oletuksena estettynä.
 
Joo, hyviä pointteja ja hyvää rupattelua kaikilta. Eniten juuri tätä vlan määrää ja roolitusta tosiaan pohdin. Alunperin ajattelin tehdä vlanin kannettaville, puhelimille sun muille käyttäjähallinnassa oleville päätelaitteille. Sitten aloin miettimään, että mihin tuo kotiautomaatiopuoli pitäisi tiputtaa. Ehkäpä jos vlaneissa pyrkisi minimiin, niin fiksu jako voisi silloin olla:

1. main lan
2. iot
3. vieraat

Oliko iot-vlanin tarkoitus muurimielessä lähinnä blokata wanista sisääntulevat, sisältä ulosmenevät, vai kumpaankin. Tässä se haaste nimittäin on, kun valtaosa iot-vermeistä on jotain pilvipaskaa joka elää internetin avulla. Jos tapan smartthingsin pääsyn internetiin, koko palvelu lakkaa olemasta. Eli oletanko oikein, että iotissa olennaista on estää hallitsematon kulku main laniin, sekä internetistä sisään päin. Hallitut sisältä aloitetut yhteydet paluupaketteineen on se minkä kanssa kuvio pitäisi toimia?

Kamerat tosin vielä mietityttää. Täytyykin pohtia onko näiden koti main lanissa vai rajoitetussa iotissa. Liikenne kuitenkin pääsääntöisesti kulkee main lanissa olevalle videopalvelimelle, mutta kameroilla on myös natiivipilvipalvelu jossa videota voi yyteröidä internetin kautta.
 
Nyt kun Edgerouter X vaikuttaisi olevan kaikkialta loppu.
Onko Er-x sfp versio yhtälailla toimiva esim. Planet VC-231G tai vastaavan perässä?

Eli voiko VDSL modeemin kytkeä suoraan tuohon sfp porttiin ja käytännössä reitittimessä jää sitten yksi ylimääräinen LAN portti käytettäväksi?
 
Nyt kun Edgerouter X vaikuttaisi olevan kaikkialta loppu.
Onko Er-x sfp versio yhtälailla toimiva esim. Planet VC-231G tai vastaavan perässä?

Eli voiko VDSL modeemin kytkeä suoraan tuohon sfp porttiin ja käytännössä reitittimessä jää sitten yksi ylimääräinen LAN portti käytettäväksi?
Tuo ER-X SFP on muuten sama laite mutta siinä on muistaakseni tuo SFP portti lisänä. Eli käytännössä yksi portti reitittimeen enemmän. Ja VC-231G ei suoraan käy tuohon SFP porttiin. Tarviit joko RJ45 SFP:n tai sitten VC-231GF + 2kpl SFP ja kuitu väliin (jos haluaa hifistellä). Toki sen VC-231Gn voi kytkeä normaaliin RJ45 porttiin.
 
Oliko iot-vlanin tarkoitus muurimielessä lähinnä blokata wanista sisääntulevat, sisältä ulosmenevät, vai kumpaankin. Tässä se haaste nimittäin on, kun valtaosa iot-vermeistä on jotain pilvipaskaa joka elää internetin avulla. Jos tapan smartthingsin pääsyn internetiin, koko palvelu lakkaa olemasta. Eli oletanko oikein, että iotissa olennaista on estää hallitsematon kulku main laniin, sekä internetistä sisään päin. Hallitut sisältä aloitetut yhteydet paluupaketteineen on se minkä kanssa kuvio pitäisi toimia?

Kamerat tosin vielä mietityttää. Täytyykin pohtia onko näiden koti main lanissa vai rajoitetussa iotissa. Liikenne kuitenkin pääsääntöisesti kulkee main lanissa olevalle videopalvelimelle, mutta kameroilla on myös natiivipilvipalvelu jossa videota voi yyteröidä internetin kautta.

iot-vlanissa olennaisinta lienee blokata pääsy sisäverkkoon niiltä osin kuin ei ole tarvetta. Internetinkin suuntaan voi olla hyvä tehdä sääntöjä, että saa jutella esimerkiksi vain tiettyihin portteihin. Tästä tulee toki helposti melkoinen sillisalaatti ja saa selvitellä mitä mikäkin laite tarvitsee. Jos ei verkko ole täynnä kyseenalaisia romuja niin melko huoletta voi internetin suuntaan sallia liikenteen. Sisäänpäin tulevat yhteydethän on toki lähtökohtaisesti blokattu vlanista riippumatta (paluupaketit eri juttu) ja vain tarpeellinen on auki (harvemmin yhtään mitään iot laitteiden osalta).

Itsellä iot-vlanissa käytännössä kaikki mitkä ei ole puhelimia, tietokoneita, tai palvelimia eli digiboksit, telkkarit, vahvistimet, chromecast, kotiautomaatio ränkylät mitkä vaatii yhteyttä internetiin yms. mDNS lentää tuon "käyttö" vlanin ja iot-vlanin välillä jolloin esim. chromecast toimii vaikkei se saakaan jutella sisäverkkoon muilta osin lainkaan. Kamerat myös omassa vlanissaan ja ne saa sisäverkossa jutella vain NVR:lle, sekä DHCP-palvelimelle ja hakea internetistä aikaa NTP:llä eikä mitään muuta. Suurin syy kameroiden omalle vlanille on se, että ne on PoE kameroita ja sijaitsevat ulkona, eli teoriassa tuolta pääsisi joku helposti sisäverkkoon halutessaan jos ne ei olisi omassa vlanissaan.
 
Viimeksi muokattu:
Ennen kuin näihin määrityksiin nyt vihdoin pääsisin, niin miksi en voi adaptoida kytkintä controllerissa? Kytkin on "adopting" tilassa eikä muutu siitä mihinkään. USG lan1 portti kytketty kaapelilla switchin porttiin 15. Controlleriläppäri kytketty porttiin 14. Tällöin switch löytyy mutta sitä ei voi adaptoida.

Jos kytken controllerin USG:n porttiin lan2, niin switchiä USG:n portissa lan1 ei löydy ollenkaan. Aliverkot lan1:ssä 192.168.86.1/24 ja lan2:ssa 192.168.87.1/24. Apua?
 
Joudun käynnistämään Edgerouter 10X parin viikon välein uudestaan saadakseni verkon takaisin. Se ei laske liikennettä läpi muuten, hallintapaneeliin pääsee kyllä kirjautumaan ja ssh. Edessä kaapelimodeemi.
Mistä tämän laitteen lokeihin pääsee käsiksi? Ainakin GUI:ssa on hyvin rajallinen tietomäärä toimintahistorian suhteen mistä ongelmaa lähtisi selvittämään. Skannasin CLI:n komennot läpi, mutta sieltäkään en sen viisaammaksi tullut.
Ja on uusin firmis.
 
Joudun käynnistämään Edgerouter 10X parin viikon välein uudestaan saadakseni verkon takaisin. Se ei laske liikennettä läpi muuten, hallintapaneeliin pääsee kyllä kirjautumaan ja ssh. Edessä kaapelimodeemi.
Mistä tämän laitteen lokeihin pääsee käsiksi? Ainakin GUI:ssa on hyvin rajallinen tietomäärä toimintahistorian suhteen mistä ongelmaa lähtisi selvittämään. Skannasin CLI:n komennot läpi, mutta sieltäkään en sen viisaammaksi tullut.
Ja on uusin firmis.
Mikä kaapelimodeemi ja mikä operaattori? Koleile auttaako wan dhcp manuaali uusiminen (tai wan interface käyttö alhaalla hallinnasta). Itsellä on Telian technicolor paskeen kanssa samanlaista ongelmaa, mutta perässä on edgerouterin lisäksi pfsense jossa käy ihan sama. Wan osoitteen release ja renew auttaa kummassakin. Ongelma todennäköisesti technicolorissa.
 
Ja ongelma korjaantui, mutta en tiedä miksi ja miten. Provisioinnin kanssa on ollut hieman outoutta tai sitten controlleri vain raportoi hitaasti ja väärin välillä asioita. Joka tapauksessa sain kytkimen ja muutaman tukarin adoptoitua controlleriin ja kaikki tuntuu toimivan. Nyt yritän optimoida langatonta verkkoa. 2,4ghz:n alue on selkeä kun on vielä kaiken kukkuraksi vain 3 tukaria. 5ghz:n kanavavalinta on sitten taas arpomista. Olin asennoitunut käyttämään ohjeiden mukaisesti 36 , 48 ja 161 taajuuksia, mutta ei näistä saa kuin 36-48 ilman dfs:ää. Laitoin nyt sitten reunimmaisen 36:lle, keskimmäisen 48:lla ja sen jälkeen taas 36. Skannin mukaan pitäisi olla ihan ok nyt. 2,4ghz:n alueen tukkoisuudesta herjaa kanavilla 1 ja 6, ja tämä lienee nyt sitten Huen syytä.
 
Mikä kaapelimodeemi ja mikä operaattori? Koleile auttaako wan dhcp manuaali uusiminen (tai wan interface käyttö alhaalla hallinnasta). Itsellä on Telian technicolor paskeen kanssa samanlaista ongelmaa, mutta perässä on edgerouterin lisäksi pfsense jossa käy ihan sama. Wan osoitteen release ja renew auttaa kummassakin. Ongelma todennäköisesti technicolorissa.

Elisa ja Arris TG2492s. Täytyypä kokeilla ensi kerralla tuota, oletettavasti voisi toimiakin. Sitten se pitäisi vielä saada automatisoitua vaikka viikon välein tapahtuvaksi mikäli tätä ei saa oikeasti korjattua.
Eipä sinänsä yllättänyt, että kalliimmilla laitteilla tuli taas ongelmia. Vanha D-Linkin ripulipurkki päästi gigan läpi ilman mitään säätöä enkä buutannut sitä vuosien aikana kertaakaan vian takia.
 
Vastaan itse itselle että tämä lähti jostain mystisestä syystä nyt toimimaan... Mikähän tähän on syynä, sitä en tiedä. Joku valistuneempi voi vastailla jos osaa lonkalta heittää.

EdgeRouter käsittelee vasta kokonaan syvällisemmin kaikki asetusten muutokset, kun siitä ottaa virran pois tai käynnistää sen uudelleen manuaalisesti ja siinä kohtaa toiminta voi muuttua, myös paljon huonompaan suuntaan, koska se poistaa itsenäisesti mitään kysymättä liitäntöjä pois käytöstä, jos konfiguraatio on tarpeeksi pielessä, eikä sen jälkeen ledit enää pala niissä liittimissä, mutta mikään ei ole rikki, jos näin käy. Pahimmillaan EdgeRouter pitää resetoida tehdas asetuksille ja aloittaa yhtä alusta, kun se otetaan ensimmäistä kertaa myyntipakkauksesta ulos ja tuon takia olisi syytä opetalla tallentamaan konfiguraatiot kovalevylle talteen, että on se konfiguraatio mihin voi palata nopeasti takaisin lataamalla sen EdgeRouter:n.
 
EdgeRouter käsittelee vasta kokonaan syvällisemmin kaikki asetusten muutokset, kun siitä ottaa virran pois tai käynnistää sen uudelleen manuaalisesti ja siinä kohtaa toiminta voi muuttua, myös paljon huonompaan suuntaan, koska se poistaa itsenäisesti mitään kysymättä liitäntöjä pois käytöstä, jos konfiguraatio on tarpeeksi pielessä, eikä sen jälkeen ledit enää pala niissä liittimissä, mutta mikään ei ole rikki, jos näin käy. Pahimmillaan EdgeRouter pitää resetoida tehdas asetuksille ja aloittaa yhtä alusta, kun se otetaan ensimmäistä kertaa myyntipakkauksesta ulos ja tuon takia olisi syytä opetalla tallentamaan konfiguraatiot kovalevylle talteen, että on se konfiguraatio mihin voi palata nopeasti takaisin lataamalla sen EdgeRouter:n.
Jos sitä edgerouteria ei vedä ihan täysin solmuun (eli kunhan console yhteys toimii joko telnet/ssh/sarjaportti) niin niissähän on se erillinen rollback komento jolla laite palaa edelliseen konffikseen, tai vaikka useammankin konffiksen taaksepäin. Lisäksi niistä saa kyllä vielä erillisiä local backuppeja tai jos jaksaa hifistellä, niin taisi olla ominaisuus että config backup tehdään automaattisesti ftp sijaintiin joka commitin yhteydessä.
 
Mikä kaapelimodeemi ja mikä operaattori? Koleile auttaako wan dhcp manuaali uusiminen (tai wan interface käyttö alhaalla hallinnasta). Itsellä on Telian technicolor paskeen kanssa samanlaista ongelmaa, mutta perässä on edgerouterin lisäksi pfsense jossa käy ihan sama. Wan osoitteen release ja renew auttaa kummassakin. Ongelma todennäköisesti technicolorissa.
Mullakin täällä vähän sama ongelma eli Telia ja TECHNICOLOR CGA2121. Säännöllisen epäsäännöllisesti häviää himasta Internet yhteys vaikka WIFI (AP wifi 6), Edgerouter ja Switch Lite 8 PoE kaikki kunnossa. Mulla ei ole hermot kestänyt odottaa, että palautuuko verkko itsestään joten käy boottaamassa aina TECHNICOLOR, jonka jälkeen alkaa aika nopeasti toimimaan. Mulla ei siis vielä ole ollut ubiquiti tuotteiden kanssa ongelmia.

EdgeOS:n päästä kuitenkin näkyy että wan porttiin tulee jotain liikennettä ja normaali ip-osoite paikallaan mutta ei kuitenkaan toimi.

reititin.PNG

TECHNICOLOR siltaavassa tilassa eikä mitään ominaisuuksia käytetä. Laite myös tv-tason päällä joten ei kuumene oikeastaan lainkaan. Pitää seurailla tilannetta ja jos pahasti jatkuu, niin tarkistella muita vaihtoehtoja kuten FRITZ!Box 6591 tai FRITZ!Box 6660.
 
Mullakin täällä vähän sama ongelma eli Telia ja TECHNICOLOR CGA2121. Säännöllisen epäsäännöllisesti häviää himasta Internet yhteys vaikka WIFI (AP wifi 6), Edgerouter ja Switch Lite 8 PoE kaikki kunnossa. Mulla ei ole hermot kestänyt odottaa, että palautuuko verkko itsestään joten käy boottaamassa aina TECHNICOLOR, jonka jälkeen alkaa aika nopeasti toimimaan. Mulla ei siis vielä ole ollut ubiquiti tuotteiden kanssa ongelmia.

EdgeOS:n päästä kuitenkin näkyy että wan porttiin tulee jotain liikennettä ja normaali ip-osoite paikallaan mutta ei kuitenkaan toimi.

reititin.PNG

TECHNICOLOR siltaavassa tilassa eikä mitään ominaisuuksia käytetä. Laite myös tv-tason päällä joten ei kuumene oikeastaan lainkaan. Pitää seurailla tilannetta ja jos pahasti jatkuu, niin tarkistella muita vaihtoehtoja kuten FRITZ!Box 6591 tai FRITZ!Box 6660.
Mie tuota kerra kyttäsin paketti tasolla ja kun tuo katkos tapahtuu niin Telian verkko lakkaa vastaamasta reitittimelle kunnes dhcp release-renew tekee (broadcastina). Se liikemme mitä siellä itsellä katkoksen aikana liikkui oli reitittimen huutelu verkkoon ilman vastausta ja verkosta tuleva broadcast höttö (arp kyselyitä).
 
Mie tuota kerra kyttäsin paketti tasolla ja kun tuo katkos tapahtuu niin Telian verkko lakkaa vastaamasta reitittimelle kunnes dhcp release-renew tekee (broadcastina). Se liikemme mitä siellä itsellä katkoksen aikana liikkui oli reitittimen huutelu verkkoon ilman vastausta ja verkosta tuleva broadcast höttö (arp kyselyitä).

Miten tämä sitten korjattiin? Ajastetulla bootilla tai dhcp:n uusimisella?

Onko tämä joku meidän operaattoreiden erikoisuus vai miksi ulkomaisilta foorumeilta ei äkkiseltään löydy tukea asialle?
 
Mites onko seuraava tekemätön paikka?

Nykyinen tilanne:
Sisäinen verkko alueella 192.168.10.1/24 jonka palomuuri antaa vieraille.
Sisäinen verkko alueella 192.168.1.1/254 omille koneille.
Palomuuri (hp) jossa määritelty vlan 10
Kytkin (hp) jossa portille määritetty vlan 10.

hankittu
Cloud Key Gen 2
UC-LR

idea pois että data menee vlan10 uc-lr -> kytkin -> palomuuri -> josta saa tuolta 192.168.10.1/254 osoitteessa ip.n vieraille.
 
EdgeRouter käsittelee vasta kokonaan syvällisemmin kaikki asetusten muutokset, kun siitä ottaa virran pois tai käynnistää sen uudelleen manuaalisesti ja siinä kohtaa toiminta voi muuttua, myös paljon huonompaan suuntaan, koska se poistaa itsenäisesti mitään kysymättä liitäntöjä pois käytöstä, jos konfiguraatio on tarpeeksi pielessä, eikä sen jälkeen ledit enää pala niissä liittimissä, mutta mikään ei ole rikki, jos näin käy. Pahimmillaan EdgeRouter pitää resetoida tehdas asetuksille ja aloittaa yhtä alusta, kun se otetaan ensimmäistä kertaa myyntipakkauksesta ulos ja tuon takia olisi syytä opetalla tallentamaan konfiguraatiot kovalevylle talteen, että on se konfiguraatio mihin voi palata nopeasti takaisin lataamalla sen EdgeRouter:n.

Joo, tuli huomattua tämä näköjään kantapään kautta :). Nyt kuitenkin nykyinen konffis tallessa jotta jos tekee jotain "tymää" itse niin voi vaikka ottaa sen toimivan takaisin käyttöön.

Asiasta toiseen. Onko kenelläkään kokemusta ja tietoa mitä eroja Ubiquitin WLAN-silloilla on? Tarkoitus olisi rakentaa parin rakennuksen väliin WLAN-silta. Mitä eroja "LiteBeam", "GigaBeam", "NanoBeam" tuotteilla muuta kuin toisissa on 60GHz ja 5GHz tai toinen vain? Rakennusten välillä vajaa 100m joten varmaan pakko olla ainakin tuo 5GHz "failover" jotta toimii talvellakin vakaasti...
 
Miten tämä sitten korjattiin? Ajastetulla bootilla tai dhcp:n uusimisella?

Onko tämä joku meidän operaattoreiden erikoisuus vai miksi ulkomaisilta foorumeilta ei äkkiseltään löydy tukea asialle?
Siitä kun ei ole tietoa mikä tuon laukaisee niin ei siihen muuta konstia ole kuin joku scripti joka pingaa vaikka google ja jos pingi failaa määrän x peräkkäin niin wan dhcp vapautetaan ja haetaan uudelleen. Myös wan portin alhaalla käyttö toimii.

Ongelma lienee varmaan jossain joko technicolorin softassa (reittitiedot sekoaa eikä unicast liikenne löydä perille koska läpi kulkee vain broadcast ja dhcp kysely broadcastinä resetoi reitit) tai Telian verkon määrityksissä. Teliaa homman korjaus ei tuntunut kiinnostavan.
 
Mites onko seuraava tekemätön paikka?

Nykyinen tilanne:
Sisäinen verkko alueella 192.168.10.1/24 jonka palomuuri antaa vieraille.
Sisäinen verkko alueella 192.168.1.1/254 omille koneille.
Palomuuri (hp) jossa määritelty vlan 10
Kytkin (hp) jossa portille määritetty vlan 10.

hankittu
Cloud Key Gen 2
UC-LR

idea pois että data menee vlan10 uc-lr -> kytkin -> palomuuri -> josta saa tuolta 192.168.10.1/254 osoitteessa ip.n vieraille.
Jos nyt oikein tajusin niin eihän tuossa mitään ihmeellistä. Palomuurilta tagged vlan 10 ja untagged lan-verkko kytkimelle ja vastaavasti sieltä haluttuun porttiin johon tukari tulee niin samat vlan 10 tagged ja lan untagged. Cloudkey toiseen porttiin jossa lan untagged ja sitten cloudkeyn asennus ja lopuksi tukarin adoptointi. Sitten vaan unifista luo uuden verkon Networks -valikosta (”vlan only”) vlan id 10:llä ja liittää sen langattomaan verkkoon wireless networks -> create new wireless network -> network -> valitse dropdown valikosta juuri luomasi verkko ja laita muut asetukset millaisiksi haluat.
 
Viimeksi muokattu:
Jos nyt oikein tajusin niin eihän tuossa mitään ihmeellistä. Palomuurilta tagged vlan 10 ja untagged lan-verkko kytkimelle ja vastaavasti sieltä haluttuun porttiin johon tukari tulee niin samat vlan 10 tagged ja lan untagged. Cloudkey toiseen porttiin jossa lan untagged ja sitten cloudkeyn asennus ja lopuksi tukarin adoptointi. Sitten vaan unifista luo uuden verkon Networks -valikosta (”vlan only”) vlan id 10:llä ja liittää sen langattomaan verkkoon wireless networks -> create new wireless network -> network -> valitse dropdown valikosta juuri luomasi verkko ja laita muut asetukset millaisiksi haluat.
Moi

Oikein älysit mutta uudesta versiota ei löydy enää tuota vlan only juttua. En tiedä miksi se on jäänyt pois. Toki vanhasta löytyy mutta sitten kun uutta käyttää niin ei näy sit network aluetta ollenkaan.
 
Moi

Oikein älysit mutta uudesta versiota ei löydy enää tuota vlan only juttua. En tiedä miksi se on jäänyt pois. Toki vanhasta löytyy mutta sitten kun uutta käyttää niin ei näy sit network aluetta ollenkaan.
Ainiin se yrittää sitä uutta versiota pakottaa, kontrollerin itse hostattuna saa ainakin vaihdettua takaisin classic modeen mutta pitääpä vilkaista jossain vaiheessa miten tuo menisi siinä uudessa.
 
Nyt kun muutama päivä Ubiquiti Unifin kanssa leikitty, niin olen kyllä tyytyväinen. Kaikki toimii erittäinkin hyvin, eikä toistaiseksi ole mitään haasteita esiintynyt. Nyt vielä kaikki vermeet on tosin samassa aliverkossa ja vlanit teen jahka joudan. Alun asennusprobleeman lukuunottamatta controlleri on järkevä ja ymmärrettävä, controllerista nähtävä data on monipuolista ainakin alkuun. IDP:tä en ole kytkenyt päälle kun luin, että osalla on tullut ongelmia. Onko kellään ensikäden kokemusta IDP:tä Unifissa, että uskaltaako tuon laittaa päälle kunhan vain ymmärtää että läpimenevä kapa rajoitetaan 85mbps:n? Jotain muuta mitä pitäisi huomioida tuon suhteen?

Niin ja lisäksi en ole tehnyt juurikaan wifi-muutoksia, mitä nyt kanavat 2,4ghz:lle ja 5ghz:lle vaihdoin. ALempi taajuus helppo, mutta 5ghz tuotti hetken päänvaivaa ennen kuin tajusin, että eihän täällä Suomessa saa DFS-kanavien yläpuolista tarjontaan käyttöön kuten jenkeissä. Sääli. Nyt arvon kahdesta kanavasetistä joka toista käyttöön, ja tämä ei mikään ongelma edes sinällään ole.
 

Statistiikka

Viestiketjuista
259 114
Viestejä
4 502 371
Jäsenet
74 329
Uusin jäsen
Bopperhopper

Hinta.fi

Back
Ylös Bottom