Kokemuksia Ubiquitin reitittimistä (ja muista verkkovermeistä).

Onko kukaan soveltanu tai kokeillu tuota ad blocking systeemiä edgerouterilla ?
Ubiquiti Networks Community
linkki vie : community.ubnt.com keskusteluun.

Eli ois mahdollista saada mainosten esto tai blokkaus jo edgerouterilla ?
 
Eli ois mahdollista saada mainosten esto tai blokkaus jo edgerouterilla ?
En ole kokeillut, mutta idea on simppeli: blacklist.

ER:n DNS-nimipalvelin antaa monien koneiden nimille sellaisen (saman) IP-osoitteen, josta ei löydy html-sisältöä. Nimipalvelimelle haetaan sensurointilista verkosta.
 
Ei nyt varsinaisesti liity vastaukseesi tämä asia (kiitos silti). Aloin tuossa jo tutkiskelemaan tuota Dnssec mahdollisuuta, er-x antaa mahdollisuuden siihen ilmeisesti kyllä. Mutta. Quad9 taitaa olla ainoita joka tukee tuota dnsseciä. Opendns ei tue, 1.1.1.1 ei tue. Nyt en enempää muista alkaa olla aivot solmussa ja nukkumaanmeno aika :)

Mitäköhän eroa noilla Quad9:llä ja Opendns:llä on nyt sitte ? Ei juuri mitään, paitsi dnssec ?
Voi olla että nyt muutankin nuo omat dns osoitteet edgestä opendns-> quad9

Voi olla että rohkeus ei ihan vielä riitä sekoittamaan tuota edgeä tuolla mainoksen esto toiminnalla. Sitten kun haluaa vaikka tv:tä pitää verkossa on edgeen tuo mainosten esto kohdallaan.
 
Viimeksi muokannut ylläpidon jäsen:
Onko kenelläkään tullut USG 3P:n kanssa sellaista ongelmaa, että laite ei saa sillatusta modeemista julkista IP:tä? :confused:

Itsellä käytössä Telialta 4G liittymä ja siinä kyljessä lisäpalveluna Telia Yhteyspiste, joka mahdollistaa vaihtuvan julkisen IP:n operaattorin NAT IP:n sijaan. Yhteyspisteen pitäisi toimia sillä modeemi saa osoitteen operaattorin NATin ulkopuolelta sekä whatmyip.org antaa saman IP:n minkä modeemi saa.

Kun laitan modeemin siltaan ja isken sen kiinnni USG:n WAN porttiin niin USG herjaa kokoajan, että ei saa yhteyttä Internettiin sekä pyytää tarkistamaan konffit. Olen tarkistanut, että WAN-asetuksessa on DHCP, kokeillut bootata USG:tä ja modeemia uusiksi, tarkistanut laitteissa olevan tuorein firmis, tarkistanut modeemista kaikki ne palvelut pois, joita ei tarvita kuten palomuuri, wlan jne. USG saa yhteyden kyllä Internettiin, jos laitan modeemin reitittäväksi sekä määritän USG.hen staattisen IP, mutta tämä ei ole ideaalinen ratkaisu tupla NATin takia. Vanhassa osoitteessa oli aiemmin käyttössä DNA:n kaapeli, jonka kanssa ei ongelmaa ole ollut.

En sitten tiedä onko syyllinen itse modeemi, joka on Huawei B525s-65a vai jokin muu. DNA:n kaapelin kanssa modeemin virkaa hoiti Cisco EPC3825. Huawein laite on myös operaattorivapaa..
 
Onko kenelläkään tullut USG 3P:n kanssa sellaista ongelmaa, että laite ei saa sillatusta modeemista julkista IP:tä? :confused:

Itsellä käytössä Telialta 4G liittymä ja siinä kyljessä lisäpalveluna Telia Yhteyspiste, joka mahdollistaa vaihtuvan julkisen IP:n operaattorin NAT IP:n sijaan. Yhteyspisteen pitäisi toimia sillä modeemi saa osoitteen operaattorin NATin ulkopuolelta sekä whatmyip.org antaa saman IP:n minkä modeemi saa.

Kun laitan modeemin siltaan ja isken sen kiinnni USG:n WAN porttiin niin USG herjaa kokoajan, että ei saa yhteyttä Internettiin sekä pyytää tarkistamaan konffit. Olen tarkistanut, että WAN-asetuksessa on DHCP, kokeillut bootata USG:tä ja modeemia uusiksi, tarkistanut laitteissa olevan tuorein firmis, tarkistanut modeemista kaikki ne palvelut pois, joita ei tarvita kuten palomuuri, wlan jne. USG saa yhteyden kyllä Internettiin, jos laitan modeemin reitittäväksi sekä määritän USG.hen staattisen IP, mutta tämä ei ole ideaalinen ratkaisu tupla NATin takia. Vanhassa osoitteessa oli aiemmin käyttössä DNA:n kaapeli, jonka kanssa ei ongelmaa ole ollut.

En sitten tiedä onko syyllinen itse modeemi, joka on Huawei B525s-65a vai jokin muu. DNA:n kaapelin kanssa modeemin virkaa hoiti Cisco EPC3825. Huawein laite on myös operaattorivapaa..

Modeemi antaa julkisen ip:n vain yhdestä portista. En muista mikä, ehkä 1. (vasen takaa päin)
Oletko kokeillut toisella laiteella, esim. PC? Saako ip:n?
 
Onko kenelläkään tullut USG 3P:n kanssa sellaista ongelmaa, että laite ei saa sillatusta modeemista julkista IP:tä? :confused:

Itsellä käytössä Telialta 4G liittymä ja siinä kyljessä lisäpalveluna Telia Yhteyspiste, joka mahdollistaa vaihtuvan julkisen IP:n operaattorin NAT IP:n sijaan. Yhteyspisteen pitäisi toimia sillä modeemi saa osoitteen operaattorin NATin ulkopuolelta sekä whatmyip.org antaa saman IP:n minkä modeemi saa.

Kun laitan modeemin siltaan ja isken sen kiinnni USG:n WAN porttiin niin USG herjaa kokoajan, että ei saa yhteyttä Internettiin sekä pyytää tarkistamaan konffit. Olen tarkistanut, että WAN-asetuksessa on DHCP, kokeillut bootata USG:tä ja modeemia uusiksi, tarkistanut laitteissa olevan tuorein firmis, tarkistanut modeemista kaikki ne palvelut pois, joita ei tarvita kuten palomuuri, wlan jne. USG saa yhteyden kyllä Internettiin, jos laitan modeemin reitittäväksi sekä määritän USG.hen staattisen IP, mutta tämä ei ole ideaalinen ratkaisu tupla NATin takia. Vanhassa osoitteessa oli aiemmin käyttössä DNA:n kaapeli, jonka kanssa ei ongelmaa ole ollut.

En sitten tiedä onko syyllinen itse modeemi, joka on Huawei B525s-65a vai jokin muu. DNA:n kaapelin kanssa modeemin virkaa hoiti Cisco EPC3825. Huawein laite on myös operaattorivapaa..
Hyvin toimi ennen kuitua Telian opengate (Yhteyspiste), USG ja Zyxel LTE7460 kombo. Eli epäilisin nyt tuota Huaweitä tässä kohtaa.
 
Modeemi antaa julkisen ip:n vain yhdestä portista. En muista mikä, ehkä 1. (vasen takaa päin)
Oletko kokeillut toisella laiteella, esim. PC? Saako ip:n?

Kokelin äsken heittää laitteesta bridgen päälle sekä omasta myllystä DHCP:n päälle. Kävin äsken laitteen portit läpi sekä ajoin cmd:stä ipconfig /release, /flushdns ja /renew. Kone ei kyllä saanut IP:tä. Muistaakseni vanhemmissa Huawein modeemissa siltaportti oli joko 1 tai 4.

Hyvin toimi ennen kuitua Telian opengate (Yhteyspiste), USG ja Zyxel LTE7460 kombo. Eli epäilisin nyt tuota Huaweitä tässä kohtaa.

Äskeisen testin jälkeen epäilen samaa. Modeemia olen kanssa resetoinut ja konffaillut uusiksi. Pitää napata töistä yksi vanha Zyxel LTE3301 ja testata sillä siltausta USG:hen ja sekä Huaweista siltaus esim. Zyxel USG 20W muuriin... Muuten pitänee olla Teliaa yhteyksissä...
 
Jees. Testasin nyt siltausta Zyxelin LTE3301 modeemilla opengaten APN:llä ja boottasin sen sekä USG 3P. USG löysi tämän jälkeen julkisen IP:n kuten pitääkin testasin vielä laittaa USG:n asetuksiin WAN IP:n staattiseksi sekä syötin opengaten osoitteet jotka löytyi Zyxelin dashboardista. Tälläkään tuo USG ei suostunut Internettiin yhdistämään joten vika on tuossa Huawein purkissa tai sen konfissa jota itse nyt epäilen vahvasti. Pitää jatkaa tutkimuksia... :smoke:
 
Uutta firmistä (4.0.30) pukkaa.

Varsin kattava muutoslista.

Koodi:
Firmware changes since 4.0.30:

[UAPG2/G3] Fix corrupt UBNT IEs.
[UAPG2/G3] Handle broadcast DHCP replies properly while using dynamic VLANs.
[UAPG1/G2] System optimizations.
[UAPG2] Fix 100FDX negotiation issue after wired uplink state change.
[UAPG2] Fix downlink AP crash when using a DFS channel for wireless uplink.
[UAPG2] Fix wireless uplink priority selection fail.
[UAPG1] Fix Ethernet negotiation.
[UAPG1] Fix issue causing no Ethernet link when link partner uses manual negotiation.
[UAPG1] Fix remaining issues with establishing an Ethernet link.
[AC-Pro/EDU/M-Pro] Fix performance regression in 4.x when uplink is 100Mbps.
[HD/SHD/XG/BaseStationXG] Fix mDNS leak when Broadcast and Multicast Filter enabled (reported HERE).
[HD/SHD/XG/BaseStationXG] Fix reset button behavior.
[HD/SHD/XG/BaseStationXG] Stability and compatibility improvements when using `Auto-Optimize Network` or `High Performance Devices`.
[HD/SHD/XG/BaseStationXG] Update kernel.
[HD/SHD/XG] Fix bug causing lower than expected MCS and throughput when TX power >=25dBm.
[BaseStationXG] Fix GPS support.
[nanoHD/IW-HD/UDM-B] Add association tracking support.
[nanoHD/IW-HD/UDM-B] Add support for `High Performance Devices` (also part of `Auto-Optimize Network`).
[nanoHD/IW-HD/UDM-B] Add support to display which client STAs support Fast Roaming.
[nanoHD/IW-HD/UDM-B] Enable client STA keepalive support.
[nanoHD/IW-HD/UDM-B] Fix 802.11w (PMF) provisioning.
[nanoHD/IW-HD/UDM-B] Fix a crash when running RF Environment scanning.
[nanoHD/IW-HD/UDM-B] Fix a null pointer access issue.
[nanoHD/IW-HD/UDM-B] Fix AndesSendCmdMsg warnings (reported HERE and HERE).
[nanoHD/IW-HD/UDM-B] Fix downlink AP TX rate degradation issue.
[nanoHD/IW-HD/UDM-B] Fix false anomalies/failures.
[nanoHD/IW-HD/UDM-B] Fix some memory leaks.
[nanoHD/IW-HD/UDM-B] Fix speed regression caused by unaligned access.
[nanoHD/IW-HD/UDM-B] Fix TX retry and drop count (reported HERE).
[nanoHD/IW-HD/UDM-B] Fix wireless uplink packet forwarding issue.
[nanoHD/IW-HD/UDM-B] Improve multi-client performance.
[nanoHD/IW-HD/UDM-B] Stability improvements.
[nanoHD/IW-HD/UDM-B] System optimizations.
[nanoHD/IW-HD/UDM-B] Tweak WiFi Experience scoring.
[UDM-B] Disable RF Environment scanning as it's unsupported.
[UAP-IW] Fix behaviour so ports are switched instead of isolated.
[UAP-IW] Fix link flapping and switch VLAN behavior.
[UAP-IW] Fix port/management VLAN provisioning.
[UAP-IW] Fix reported inittab respawn errors (reported HERE).
[UAP] Add DFS backup channel feature.*
[UAP] Add initial RFC-5176 support.*
[UAP] Add U-NII-2C support for Panama country code.
[UAP] Fix a bug which causes mcad to be removed unexpectedly after a provision.
[UAP] Fix a bug with guest portal redirection.
[UAP] Fix and improve User Groups support.
[UAP] Fix Apple Watch support when using `Auto-Optimize Network` feature.*
[UAP] Fix connectivity issue for 2.4GHz only devices when using `Auto-Optimize Networks` or `High Performance Devices`.
[UAP] Fix false `Blocked by access control` anomalies.
[UAP] Fix false DHCP timeout/failure anomalies.
[UAP] Fix incorrect/lower than expected 2.4GHz TX power limits.
[UAP] Fix issues when multiple guest networks on an AP.*
[UAP] Fix RADIUS failover behavior.
[UAP] Fix RF Environment scanning bug which caused APs to require a power cycle after running a scan (reported HERE and HERE).
[UAP] Improve client STA compatibility when using `High Performance Devices` (also part of `Auto-Optimize Networks`).
[UAP] Regulatory updates for Russia.
[U-LTE] Disable RF Environment scanning as it's unsupported.
[USW] Fix timeout issue when provisioning 200+ VLANs.
[UIS] Improve PD compatibility.*
[USW-Pro/XG-6POE] Add initial routing support.**
[USW-Pro/XG-6POE] Add LCM brightness/sync support.**
[USW-Pro/XG-6POE] Change throughput update interval on LCM to 1 second.
[USW-Pro/XG-6POE] Fix a bug that may cause the in-row SFP port to disable when setting an Ethernet port to Disabled.
[USW-Pro/XG-6POE] Fix a rare bug in LCM initialization during boot.
[USW-Pro/XG-6POE] Further improvements to PD autodetection.
[USW-Pro/XG-6POE] Improve handling when no uplink detected.
[USW-Pro/XG-6POE] Improve PoE reliability.
[USW-Pro/XG-6POE] Improve reliability of LCM sync feature.
[USW-Pro/XG-6POE] Tweak LCM touch event behaviour.
[USW-Flex] Fix a bug which may prevent device from booting.
[USW-Flex] Improve device initialization reliability.
[US8] Disable IPv6 on VLAN interfaces (reported HERE).
[USW] Add Wired User Experience support.**
[USW] Fix 10/100Mbps manual negotiation.
[USW] Fix false PoE overload events.
[USW] Fix SNMPv3 data leaking without auth.
[USW] Improve Fault Status text when checking PoE info via shell.
[SEC] Fix CVE-2019-8912.
[HW] Fix alerts generated when inittab restarts a process.
[HW] Fix STUN URL resolution.
[HW] Fix support for Custom Upgrades via FTP.
[HW] Miscellaneous bug fixes and improvements.

Ubiquiti Networks Community
 
Mikähän tässä nyt mättää kun en saa portforwardeja toimiin vieläkään?
WAN interface 4 (0 ei jostain syystä toimi)
Hairpin NAT = ON
Lan interface eth3 ja laitoin siihen kaikki portit, mutta ei toimi?
Muutenkin ihmetyttää kun TP-linkin kautta 1000/100 toimi 175/100, mutta edgerouterillakaan ei päässy yli 450/100. :-/
 
Mikähän tässä nyt mättää kun en saa portforwardeja toimiin vieläkään?
WAN interface 4 (0 ei jostain syystä toimi)
Hairpin NAT = ON
Lan interface eth3 ja laitoin siihen kaikki portit, mutta ei toimi?
Muutenkin ihmetyttää kun TP-linkin kautta 1000/100 toimi 175/100, mutta edgerouterillakaan ei päässy yli 450/100. :-/

Onko ER:ssä Hardware offload päällä?
 
Mikähän tässä nyt mättää kun en saa portforwardeja toimiin vieläkään?
WAN interface 4 (0 ei jostain syystä toimi)
Hairpin NAT = ON
Lan interface eth3 ja laitoin siihen kaikki portit, mutta ei toimi?
Muutenkin ihmetyttää kun TP-linkin kautta 1000/100 toimi 175/100, mutta edgerouterillakaan ei päässy yli 450/100. :-/

Edgerouter X lienee kyseessä? Onko ne LAN portit bridgessä? Jos on niin port forward pitää tehdä siihen bridge interfaceen eli todennäköisesti br0, switch0 tms eikä eth3. Sama selittäisi myös sen miksi suorituskyky on kehno, kun bridge hanskataan softalla. WAN interfacenahan toimii sitten juuri se portti minkä olet sinne konfiguroinut.
 
Viimeksi muokattu:
Onko ER:ssä Hardware offload päällä?
Mistä se löytyy?
Edgerouter X lienee kyseessä? Onko ne LAN portit bridgessä? Jos on niin port forward pitää tehdä siihen bridge interfaceen eli todennäköisesti br0 eikä eth3. Sama selittäisi myös sen miksi suorituskyky on kehno, kun bridge hanskataan softalla. WAN interfacenahan toimii sitten juuri se portti minkä olet sinne konfiguroinut.
Ainut paikka mistä löytyy mitään bridgestä on config tree -> interfaces -> bridge ja se on tyhjä.
 
Pitäiskö tää homma alottaa siitä, että sais tuon lan0 portin kautta netin toimiin? Miksi siitä ei saa yhteyttä läpi? Tuo käyttöohje ei kerro mistään mitään.
Tuo firewall/NAT -> masquerade for WAN näkyy vaativan toimiakseen eth4, mutta vaikka sen vaihtaa eth0 niin se ei toimi.
 
Pitäiskö tää homma alottaa siitä, että sais tuon lan0 portin kautta netin toimiin? Miksi siitä ei saa yhteyttä läpi? Tuo käyttöohje ei kerro mistään mitään.
Tuo firewall/NAT -> masquerade for WAN näkyy vaativan toimiakseen eth4, mutta vaikka sen vaihtaa eth0 niin se ei toimi.

Sillä ei varsinaisesti ole mitään merkitystä onko sulla WAN portti konfiguroituna eth0 vai eth4. Ei se porttiohjauksen toimivuutta maagisesti estä. Mitä tarkoittaa ettei siitä saa yhteyttä läpi? Oletko muutanut konfiguraatiota välissä ja eth0 ei toimi mutta eth4 toimii? Molemmat ei samaan aikaan kuulukaan toimia ellet ole jotain erikoista konfiguraatiota sisään laittanut.

Olihan porttiohjausten ohessa availtu myös palomuuria jos tuota bridgeä ei tosiaan löydy?

NAT julkiverkkoon ei luonnollisesti toimi kuin siitä portista missä WAN on kiinni ja konfiguroituna.
 
Viimeksi muokattu:
Mistä se löytyy?

EdgeRouter - Hardware Offloading


Screenshot_20190602-090223_Chrome.jpg



Elikkäns CLI:n kautta puukotat päälle. Ipsec offloadin käynnistäminen/sammuttaminen vaatii reitittimen boottauksen

Ilman offloadia ER:n troughput jää tuonne 400Mbps haminoille, offloadin kanssa pitäisi päästä sinne 900Mbps.
 
Kiitos vinkeistä.
Uudella firmiksellä ja offloadilla sain nopeudet tuplattua Max. 430 -> 840 avg 255 -> 550.
Yritin sitten saada noita portteja auki ja päädyin vielä tekeen resetin purkille.
Nyt eth0 portti toimii oikein ja ilman offloadia pääsee 500-700Mbps nopeuksiin.
Portin ohjauksen advanced settings näyttää sen täpän automaattiselle palomuurin ohjaukselle. Eikö se toimi jos palomuuriin pitää vielä erikseen tehdä muutoksia?
Jostain syystä Logi ikkunaan tulee n.7s välein joku login failed blah blah user=root jostain Kiinalaisesta IP:stä. Kuuluuko tämä asiaan?
 
Jostain syystä Logi ikkunaan tulee n.7s välein joku login failed blah blah user=root jostain Kiinalaisesta IP:stä. Kuuluuko tämä asiaan?
Kuuluu asiaan, botit siellä jauhaa. Access listillä disabloit reitittimen hallinnan wan interfacesta. Tähän taisi olla GUI:lla oma asetuskin jossain...
 
Kiitos vinkeistä.
Uudella firmiksellä ja offloadilla sain nopeudet tuplattua Max. 430 -> 840 avg 255 -> 550.
Yritin sitten saada noita portteja auki ja päädyin vielä tekeen resetin purkille.
Nyt eth0 portti toimii oikein ja ilman offloadia pääsee 500-700Mbps nopeuksiin.
Portin ohjauksen advanced settings näyttää sen täpän automaattiselle palomuurin ohjaukselle. Eikö se toimi jos palomuuriin pitää vielä erikseen tehdä muutoksia?
Jostain syystä Logi ikkunaan tulee n.7s välein joku login failed blah blah user=root jostain Kiinalaisesta IP:stä. Kuuluuko tämä asiaan?

Onko tuo peruskonfiguraatio tehty wizardin kautta? Siinä on vaihtoehtona luoda default firewall säännöt jolloin tuo koputtelu ei onnistu. Mitään liikennettä ei kannata sallia sisäänpäin oletuksena.

Kurkkaa CLI:n puolelta miltä näyttää nuo automaattiset firewall säännöt:

sudo iptables -t filter -nvL UBNT_PFOR_FW_HOOK
sudo iptables -t filter -nvL UBNT_PFOR_FW_RULES
 
Viimeksi muokattu:
Onko tuo peruskonfiguraatio tehty wizardin kautta? Siinä on vaihtoehtona luoda default firewall säännöt jolloin tuo koputtelu ei onnistu. Mitään liikennettä ei kannata sallia sisäänpäin oletuksena.

Kurkkaa CLI:n puolelta miltä näyttää nuo automaattiset firewall säännöt:

sudo iptables -t filter -nvL UBNT_PFOR_FW_HOOK
sudo iptables -t filter -nvL UBNT_PFOR_FW_RULES
Ei ole wizardin kautta.
Koodi:
Chain UBNT_PFOR_FW_HOOK (1 references)                                         
pkts bytes target     prot opt in     out     source               destination
                                                                              
2318K 8483M UBNT_PFOR_FW_RULES  all  --  eth0   *       0.0.0.0/0            0.0
.0.0/0

ja
Koodi:
Chain UBNT_PFOR_FW_RULES (1 references)                                         
 pkts bytes target     prot opt in     out     source               destination
                                                                                
  760 25080 ACCEPT     udp  --  *      *       0.0.0.0/0            192.168.1.38
         udp multiport dports 7707:7708                                         
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            192.168.1.38
         udp dpt:7717                                                           
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            192.168.1.38
         tcp dpt:28852                                                         
 1163 61591 ACCEPT     udp  --  *      *       0.0.0.0/0            192.168.1.38
         udp dpt:28852                                                         
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            192.168.1.38
         tcp dpt:8075                                                           
 2433  156K ACCEPT     udp  --  *      *       0.0.0.0/0            192.168.1.38
         udp dpt:20560
 
Ei ole wizardin kautta.
Koodi:
Chain UBNT_PFOR_FW_HOOK (1 references)                                        
pkts bytes target     prot opt in     out     source               destination
                                                                             
2318K 8483M UBNT_PFOR_FW_RULES  all  --  eth0   *       0.0.0.0/0            0.0
.0.0/0

ja
Koodi:
Chain UBNT_PFOR_FW_RULES (1 references)                                        
 pkts bytes target     prot opt in     out     source               destination
                                                                               
  760 25080 ACCEPT     udp  --  *      *       0.0.0.0/0            192.168.1.38
         udp multiport dports 7707:7708                                        
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            192.168.1.38
         udp dpt:7717                                                          
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            192.168.1.38
         tcp dpt:28852                                                        
 1163 61591 ACCEPT     udp  --  *      *       0.0.0.0/0            192.168.1.38
         udp dpt:28852                                                        
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            192.168.1.38
         tcp dpt:8075                                                          
 2433  156K ACCEPT     udp  --  *      *       0.0.0.0/0            192.168.1.38
         udp dpt:20560

Kyllähän nuo ihan oikealta näyttäisi. Miten olet toimimattomuuden testannut, jollain porttiskannerilla tms?
 
Kyllähän nuo ihan oikealta näyttäisi. Miten olet toimimattomuuden testannut, jollain porttiskannerilla tms?
Tuossa on esim. Steam gameserver port josta port checker sanoo, että se on kiinni ja serveriä ei näy listassa. Port chekker sanoo, että portti 8075 on auki ja sinne pääsee LANin kautta ja toisesta verkosta, mutta ei samasta verkosta WAN IP:llä (joku nat asetus?).
Mitä noista nyt kokeilin porttiskannerilla niin 20560 oli kiinni, 28852 oli kiinni, 7717 oli kiinni ja 8075 oli auki.
Tässä on vielä selitykset noille porteille.
Koodi:
7707 UDP/IP (Game Port)
7708 UDP/IP (Query Port)
7717 UDP/IP (GameSpy Query Port)
28852 TCP/IP and UDP (Allows your Server to Connect to the Master Server Browser)
8075 TCP/IP (Port set via ListenPort that your WebAdmin will run on)
20560 UDP/IP (Steam Port)
 
Tuossa on esim. Steam gameserver port josta port checker sanoo, että se on kiinni ja serveriä ei näy listassa. Port chekker sanoo, että portti 8075 on auki ja sinne pääsee LANin kautta ja toisesta verkosta, mutta ei samasta verkosta WAN IP:llä (joku nat asetus?).
Mitä noista nyt kokeilin porttiskannerilla niin 20560 oli kiinni, 28852 oli kiinni, 7717 oli kiinni ja 8075 oli auki.
Tässä on vielä selitykset noille porteille.
Koodi:
7707 UDP/IP (Game Port)
7708 UDP/IP (Query Port)
7717 UDP/IP (GameSpy Query Port)
28852 TCP/IP and UDP (Allows your Server to Connect to the Master Server Browser)
8075 TCP/IP (Port set via ListenPort that your WebAdmin will run on)
20560 UDP/IP (Steam Port)

Vaikea kuvitella, että osa porttiohjaus säännöistä toimisi ja osa ei, kun ne on tehty samalla tavalla. Statsithan näkee rulekohtaisesti myös tuolta webbikälin kautta, että osuuko niihin mitään paketteja. Mikään porttihan ei aukinaisena näy toki, jos ei siellä taustalla oleva sisäverkon kone todellisuudessa sitä kuuntele, tai esim sen oma palomuuri estää yhteydet jostain syystä.

WAN IP-osoite ei toimi sisäverkosta ilman hairpin nattia, eli käytännössä sisäverkon puolella on silloin vastaava rule mikä WAN interfacessa on. Aika harvassa tilanteessa tuo mitenkään tarpeellinen oikeasti on, jos/kun samaan kohteeseen pääsee sisäverkon osoitteella.
 
Viimeksi muokattu:
Vaikea kuvitella, että osa porttiohjaus säännöistä toimisi ja osa, kun ne on tehty samalla tavalla. Statsithan näkee rulekohtaisesti myös tuolta webbikälin kautta, että osuuko niihin mitään paketteja. Mikään porttihan ei aukinaisena näy toki, jos ei siellä taustalla oleva sisäverkon kone todellisuudessa sitä kuuntele, tai esim sen oma palomuuri estää yhteydet jostain syystä.

WAN IP-osoite ei toimi sisäverkosta ilman hairpin nattia, eli käytännössä sisäverkon puolella on silloin vastaava rule mikä WAN interfacessa on. Aika harvassa tilanteessa tuo mitenkään tarpeellinen oikeasti on, jos/kun samaan kohteeseen pääsee sisäverkon osoitteella.
Ok. Asensin Steamin läppärille ja kokeilin niin serveri toimii toisesta liittymästä.
Eli se Net hairpin asetus on rikki? Sehän on oletuksena päällä ja se ei toimi.
On kyllä minulle ensimmäinen laite 16 vuoteen missä kyseinen ominaisuus ei toimi. :grumpy:
 
Ok. Asensin Steamin läppärille ja kokeilin niin serveri toimii toisesta liittymästä.
Eli se Net hairpin asetus on rikki? Sehän on oletuksena päällä ja se ei toimi.
On kyllä minulle ensimmäinen laite 16 vuoteen missä kyseinen ominaisuus ei toimi. :grumpy:

Eiköhän se ne hairpin NAT säännöt luo kuten pitää, mutta vika jossain muualla. Hienoahan näissä vehkeissä on se, että tekevät pitkälti juuri niinkuin käsketään tekemään ja ovat laajasti konfiguroitavissa myös GUI:n ulkopuolella, toisin kuin perus markettireititin. Jonkin verran kannattaa siis opiskella itsekin miten nuo ominaisuudet todellisuudessa tekevät niin niitä on helpompi selvitellä. Ubiquitilla on hyvä FAQ:t eri aiheisiin ja esimerkkejä GUI:n, sekä CLI:n osalta.
 
Löytyisikö apuja reitittimen kanssa?
Edgerouter lite katkaisi yhteyden kesken asetusten tallennuksen enkä enää saa purkkiin yhteyttä. Koitettu resetointi -> ei apua.(resetoitaessa ainoastaan eth2 portin ledi vilkkuu oranssina)
 
ER-L:n ollessa kyseessä tuikkaa serial piuha konsoliin kiinni ja ihmettele Puttyllä mitä se tekee kun se boottaa.
EdgeRouter - How to Connect to Serial Console

Tuosta sinun ongelmastasi kun on näin yhtäkkiä vaikea sanoa yhtään sen kummempaa. Konsoli yhteydellä kuitenkin näet mitä se tekee kun se boottaa ja jos se valittaa jotakin niin se näkyy.

Tuossa ohjetta TFTP recoveryyn, huomaa bootloader versio
EdgeRouter - Manual TFTP Recovery

Edit: Aiheeseen liittyen vanhaa videota.

Ja linkkiä tuohon videolla mainittuun rescue kittiin mikä pitäisi olla se vihoviimeisin vaihtoehto. If all else fails...
EdgeMax rescue kit (now you can reinstall EdgeOS from scratch) | Ubiquiti Community
 
Viimeksi muokattu:
Ubiquiti näköjään päätti yhtä äkkiä jostain oudosta syystä poistaa nettisivuiltaan "community" osion forumin ja korvata sen kasalla sekavaa paskaa. Ainakin osa käyttäjistä on aika nyrpeitä tästä (ja ihan ymmärrettävästi) mutta mielenkiintoisinta on kuinka tuolta huokuu sellainen uskon loppuminen tähän lafkaan. Itsellekkin on kyllä käynyt vähän niin.
 
Ubiquiti näköjään päätti yhtä äkkiä jostain oudosta syystä poistaa nettisivuiltaan "community" osion forumin ja korvata sen kasalla sekavaa paskaa. Ainakin osa käyttäjistä on aika nyrpeitä tästä (ja ihan ymmärrettävästi) mutta mielenkiintoisinta on kuinka tuolta huokuu sellainen uskon loppuminen tähän lafkaan. Itsellekkin on kyllä käynyt vähän niin.

Jep, niin päätti. Minunkin mielestä se on höyryävä kasa paskaa ja kommentoinkin siitä pariin otteeseen. Saa nähdä kuuntelevatko käyttäjiä.. Kun ei tuo Q&A formaatti kuitenkaan ole kovin järkevä tuollaiselle kohderyhmälle jne.

Mitä siihen uskon loppumiseen taas tulee, noh en nyt tiiä. Negatiiviset asiat nousee enemmän kuin positiiviset ja niin edespäin.
Itse osakekurssi ihan hyvällä mallilla vaikka se notkahtikin aika hervottomasti (~160-170$ > 120-130$) toukokuun alkupuolella johtuen Q3 tuloksista jotka oli hyvät mutta ei niin hyvät kuin olisi haluttu ja siihen päälle sitten vielä jenkki-kiina tariffi perseilyt. Suunta kuitenkin näyttäisi olevan ylöspäin ja YoY tällä hetkellä +53% tai vuoden alusta +33%. Q4 tuloksia odotellessa.
 
Unifi sarjan reititin ja wlan-ap pistetty tilaukseen.
Miten tuo controller-softa, saako tuon toimimaan freenassissa? Lähinnä tuo verkon lokitoiminto kiinnostaisi.
4def00235adcf1b88d92997678c03de1.jpg
 
Itse laittaisin Controllerin suosiolla ilmaiseen pilveen, niin ei ole riippuvainen siitä onko fyysinen laite hengissä (esim. sähkökatkos / salamanisku).
 
Itse laittaisin Controllerin suosiolla ilmaiseen pilveen, niin ei ole riippuvainen siitä onko fyysinen laite hengissä (esim. sähkökatkos / salamanisku).

Ja sitten on se toinen koulukunta eli ei tulisi mieleenkään laittaa kontrolleria julkiseen pilveen ilman vpn-tunnelia oman lähiverkon ja sen kontrollerin välillä. Ja tähän toteutukseen ei enää saakkaan ilmaisia palveluita.
 
Eikös controlleri ole sisäänrakennettuna tuossa USG:ssa?

Ei.

Unifi sarjan reititin ja wlan-ap pistetty tilaukseen.
Miten tuo controller-softa, saako tuon toimimaan freenassissa? Lähinnä tuo verkon lokitoiminto kiinnostaisi.

Löytyy docker imagena (ei virallinen). Softan voi myös askarrella virtuaalipalvelimeen (ubuntu/debian löytyy ubiquitin viralliset paketit). Molemmille on tuki freenas 11 eli onnistuu kyllä.

Itse laittaisin Controllerin suosiolla ilmaiseen pilveen, niin ei ole riippuvainen siitä onko fyysinen laite hengissä (esim. sähkökatkos / salamanisku).

Ja sitten kun yhteys on poikki ja jotain pitäisi debugata niin lämmittää kun se controller on siellä pilvessä. Toki ihan hyvä optio jos ei tarvetta kuin satunnaiselle konffailulle ja statistiikan hämmästelylle ja ilmaiseksi kapasiteettia jostain saa ja jaksaa viritellä VPN:ää väliin.
 
Viimeksi muokattu:
Eikös controlleri ole sisäänrakennettuna tuossa USG:ssa?

USG ei sisällä controlleria. Rasperry pyörittämään controlleria on helppo ja halpa kokoonpano. Itse en kanssa laittaisi contolleria julkiseen pilveen ilman vpn konffausta. On tuohon vpn ratkaisuunkin ilmaisia tarjolla, esim OpenVPN tai Zerotier mutta tarvitsee säätöä ja vastakoneen kuitenkin kotona.
 
Ja sitten kun yhteys on poikki ja jotain pitäisi debugata niin lämmittää kun se controller on siellä pilvessä. Toki ihan hyvä optio jos ei tarvetta kuin satunnaiselle konffailulle ja statistiikan hämmästelylle ja ilmaiseksi kapasiteettia jostain saa ja jaksaa viritellä VPN:ää väliin.
Mitä tarkoittaa "jotain pitäisi debugata" kun yhteys on poikki? Säilyyhän se konffis siellä laitteessa, vaikka internet-yhteys olisikin hetkellisesti poikki.

Toivottavasti se Controller on muillekin "satunnaiseen konffailuun", eikä säännölliseen räpeltämiseen. Oikein säädettynä, verkkolaitteisiin ei juurikaan tarvitse koskea. Leikkipaikat sitten erikseen.

Pilvi-controller ei tarvitse minkälaista VPN:ää. Pilvipään voi kiristää pilven omalla palomuurilla ja sieltä voi sallia halutut työpaikan ja koti-IP:stä. Vaihtoehtoisesti kaikki IP:t ja portit voi estää ja mennä controllerille Ubiquitin oman portaalin kautta jossa on myös mm. 2FA-suojausmahdollisuus. Sitä kautta pääsee myös paikalliseen controlleriin joka on myöskin yhteydessä internettiin.





Set up UniFi Controller on Google Cloud Platform - Metis.fi


ps. Jos Googlen pilvi pelottaa, alle 3€/kk hinnalla saa tuusulalaista pilveä: Truly thrifty cloud hosting - Hetzner Online GmbH
 
Mitä tarkoittaa "jotain pitäisi debugata" kun yhteys on poikki? Säilyyhän se konffis siellä laitteessa, vaikka internet-yhteys olisikin hetkellisesti poikki.

Toivottavasti se Controller on muillekin "satunnaiseen konffailuun", eikä säännölliseen räpeltämiseen. Oikein säädettynä, verkkolaitteisiin ei juurikaan tarvitse koskea. Leikkipaikat sitten erikseen.

Pilvi-controller ei tarvitse minkälaista VPN:ää. Pilvipään voi kiristää pilven omalla palomuurilla ja sieltä voi sallia halutut työpaikan ja koti-IP:stä. Vaihtoehtoisesti kaikki IP:t ja portit voi estää ja mennä controllerille Ubiquitin oman portaalin kautta jossa on myös mm. 2FA-suojausmahdollisuus. Sitä kautta pääsee myös paikalliseen controlleriin joka on myöskin yhteydessä internettiin.

Tietysti konffi säilyy, mutta mahdollisen vian paikantaminen on aika ankeaa jos yhteys controlleriin katkeaa. Erityisesti jos on usg:tä, ap:ta ja kytkimiä niin etsi nyt siinä vian aiheuttaja kun juuri mitään infoa et näe

Konffin tarve nyt riippuu ihan käyttötarkoituksesta. Toki jollekin riittää se fire and forget konffi ja homma oli siinä.

VPN ei tietysti pakollinen ole.
 
Viimeksi muokattu:
Tietysti konffi säilyy, mutta mahdollisen vian paikantaminen on aika ankeaa jos yhteys controlleriin katkeaa. Erityisesti jos on usg:tä, ap:ta ja kytkimiä niin etsi nyt siinä vian aiheuttaja kun juuri mitään infoa et näe
Mitä vikaa tarkoitat? Ei signaalia -> tarkistus että tukari on hengissä -> tukari alhaalla -> tarkistus että PoE-kytkin tai itse tukari on hengissä. Ei verkkoliikennettä -> tarkistus mihin asti liikenne kulkee vai pysähtyykö ensimmäiseen steppiin jne. Eipä tuohon troubleshoottaukseen tarvita controlleria etenkin kotiverkon tapauksessa.

Yritysmaailmassa varsinkin lähes kaikki alkaa olemaan keskitettyä johonkin päin nettiä, ja osa ihan tarkoituksella ilman minkälaista VPN:ää, koska sitä ei aina tarvita.

Voidaan me jossitella tästä loputtomasti, mutta uskon silti että tajuat pointtini. :)

No ainakin ne näkyy luottavan aika vahvasti tohon omaan webhallintakikkareeseensa kun ohjeissa tykitetään any/any avaukset muurille:tup:
Palomuuria voi ja kannattaa kiristää omien tarpeiden mukaan. Rajaus ainoastaan esim koti- ja työpaikan julki-IP:siin on suotavaa.
 
Tottakai voi kiristää ja pitääkin. Ei mitään syytä pitää noita webhallintoja auki julkiverkkoon. Nauratti vaan aikasempi kommenttis ja linkin kera kun sieltä vendorin toimesta jäänyt kuitenkin best practiset neuvomatta. Toki sentään vinkkinä heittivät SSHn muurauksen...
 
Tottakai voi kiristää ja pitääkin. Ei mitään syytä pitää noita webhallintoja auki julkiverkkoon. Nauratti vaan aikasempi kommenttis ja linkin kera kun sieltä vendorin toimesta jäänyt kuitenkin best practiset neuvomatta. Toki sentään vinkkinä heittivät SSHn muurauksen...
Totta kai järkeä saa käyttää tässäkin asiassa. Kuten totesin pilvi-controlleri on täysin turvallinen ja kätevä tapa pyöritellä controlleria, ilman pelkoa että verkkoon tunkeudutaan jo sekunneissa. Täydellistä verkkotietoturvaa ei ole, eikä tule olemaan. Muussa tapauksessa käyttäisimme VPN:ää verkkopankkiasioinnissakin.
 
Mitä vikaa tarkoitat? Ei signaalia -> tarkistus että tukari on hengissä -> tukari alhaalla -> tarkistus että PoE-kytkin tai itse tukari on hengissä. Ei verkkoliikennettä -> tarkistus mihin asti liikenne kulkee vai pysähtyykö ensimmäiseen steppiin jne. Eipä tuohon troubleshoottaukseen tarvita controlleria etenkin kotiverkon tapauksessa.

Yritysmaailmassa varsinkin lähes kaikki alkaa olemaan keskitettyä johonkin päin nettiä, ja osa ihan tarkoituksella ilman minkälaista VPN:ää, koska sitä ei aina tarvita.

Voidaan me jossitella tästä loputtomasti, mutta uskon silti että tajuat pointtini. :)

AP nyt oli ehkä liikaa tuossa. Ei se ketju aina reitittimestä starttaa vaikka näin nyt suurin osa kotiverkoista onkin. Mielipidejuttuja nämä osin onkin enkä itse pidä siitä, että koko verkon hallinta riippuu jostain verkon yli käytettävästä softasta. Toisille se varmasti riittää, että näkyvyys tippuu täysin kun yhteys controlleriin katkeaa syystä X (syy kun voi olla itsekin aiheutettu vaikka konffimuutoksen seurauksena).

Totta on että jos liikenne on salattua niin usein palomuurirajaus riittää mainiosti. Ei se silti väärin ole, että sekin vähä mitä on mahdollisesti matkalla nähtävissä piilotetaan tunneliin. Poistaa myös sen mahdollisuuden ettei edes vahingossa pisteiden välillä kulje mitään täysin salaamattomana.
 
ER-L:n ollessa kyseessä tuikkaa serial piuha konsoliin kiinni ja ihmettele Puttyllä mitä se tekee kun se boottaa.
EdgeRouter - How to Connect to Serial Console

Tuosta sinun ongelmastasi kun on näin yhtäkkiä vaikea sanoa yhtään sen kummempaa. Konsoli yhteydellä kuitenkin näet mitä se tekee kun se boottaa ja jos se valittaa jotakin niin se näkyy.

Tuossa ohjetta TFTP recoveryyn, huomaa bootloader versio
EdgeRouter - Manual TFTP Recovery

Edit: Aiheeseen liittyen vanhaa videota.

Ja linkkiä tuohon videolla mainittuun rescue kittiin mikä pitäisi olla se vihoviimeisin vaihtoehto. If all else fails...
EdgeMax rescue kit (now you can reinstall EdgeOS from scratch) | Ubiquiti Community

Eipä löydy elämää...
Porttien ledit toimivat mutta kun usb-rj45 kaapelilla ja puttylla koitan saada yhteyttä tulos tasan 0.
screenshot.1.jpg
 
Olen rakentamassa lähiverkkoa, johon tarvisin kolme aliverkkoa.
Aliverkot pitäisi olla eristetty toisista aliverkoista.

Internet-yhteys tulee kuitumuuntimelta. Yhteydessä on 5kpl julkisia dynaamisia ip-osoitteita.
Verkkoon tulossa mm. 2 kpl XenServereitä, jotka tarvitsevat 4 kpl julkisia ip-osoitteita.
Muut laitteet jakavat 1kpl julkisia ip-osoitteita.

Laitteisto:
Reititin Ubiquiti Edgerouter-4
3 kpl hallittavat kytkimet ZyXEL GS1200-8

Aliverkot:
Aliverkko 192.168.1.0/24 kodin laitteita varten.
Tähän aliverkkoon myös WLAN AP ja mahdollisesti IoT-laitteet.

Aliverkko 192.168.2.0/24 xenserverien sisäverkko.

Aliverkko 192.168.20.0/24 laitteiden hallintaverkko (esim xenserver, zyxel kytkimet yms).


Kaipaisin vinkkejä tai ohjeita, miten tästä kannattaisi rakentaa toimiva ja turvallinen verkko?
 
Firman netti napsahti ukkosesta poikki ja nyt ollaan sitten hetki ilman. Onko mitään helppoa keinoa jakaa puhelimen nettiä Edgerouterille?
 
Onko kukaan kokeillu toimiiko fail2ban edgerouterissa ?
 
Onko kenelläkään ilmaantunut EdgeRouterin v.2.0.4 firmiksellä vastaavaa, että muistin käyttö olisi poikkeuksellisesti suurempi? Aiemmin toi mun ER-X näytti RAM usagen olevan pääsääntöisesti ~15%, mutta nyt havahduin sähkökatkon jälkeen että RAM usage oli parissa tunnissa noussut 35%:n ja tätä kirjoittaessa 2,5 tunnin jälkeen 39%?? Sitä en tiedä kuinka ylös tuo hiipii, kun en ole aiemmin tuota huomannut. Mikähän tuota mahdollisesti syö?
 

Statistiikka

Viestiketjuista
262 924
Viestejä
4 561 065
Jäsenet
75 065
Uusin jäsen
Winter

Hinta.fi

Back
Ylös Bottom