En ole kokeillut, mutta idea on simppeli: blacklist.
Modeemi antaa julkisen ip:n vain yhdestä portista. En muista mikä, ehkä 1. (vasen takaa päin)Onko kenelläkään tullut USG 3P:n kanssa sellaista ongelmaa, että laite ei saa sillatusta modeemista julkista IP:tä?
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.Onko kenelläkään tullut USG 3P:n kanssa sellaista ongelmaa, että laite ei saa sillatusta modeemista julkista IP:tä?
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..
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.
Ä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ä...
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.
Onko ER:ssä Hardware offload päällä?
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.
Mistä se löytyy?
Ainut paikka mistä löytyy mitään bridgestä on config tree -> interfaces -> bridge ja se on tyhjä.
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.
EdgeRouter - Hardware Offloading
Kuuluu asiaan, botit siellä jauhaa. Access listillä disabloit reitittimen hallinnan wan interfacesta. Tähän taisi olla GUI:lla oma asetuskin jossain...
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.
Ei ole wizardin kautta.
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/0Chain 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:20560Kyllä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?).
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ä.
Ok. Asensin Steamin läppärille ja kokeilin niin serveri toimii toisesta liittymästä.
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.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.
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.
Eikös controlleri ole sisäänrakennettuna tuossa USG:ssa?Unifi sarjan reititin ja wlan-ap pistetty tilaukseen.
Miten tuo controller-softa, saako tuon toimimaan freenassissa? Lähinnä tuo verkon lokitoiminto kiinnostaisi.
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.
Ei.
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ä.
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.
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.
Mitä tarkoittaa "jotain pitäisi debugata" kun yhteys on poikki? Säilyyhän se konffis siellä laitteessa, vaikka internet-yhteys olisikin hetkellisesti poikki.
Meinaat ettei edes Ubiquiti tiedä mitä on tekemässä? UniFi - Install a UniFi Cloud Controller on Amazon Web Services
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
No ainakin ne näkyy luottavan aika vahvasti tohon omaan webhallintakikkareeseensa kun ohjeissa tykitetään any/any avaukset muurille
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.
Palomuuria voi ja kannattaa kiristää omien tarpeiden mukaan. Rajaus ainoastaan esim koti- ja työpaikan julki-IP:siin on suotavaa.No ainakin ne näkyy luottavan aika vahvasti tohon omaan webhallintakikkareeseensa kun ohjeissa tykitetään any/any avaukset muurille
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.
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).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.
Eipä löydy elämää...
Raspberry pi hoitaman wlan-sillan tehtävää, tai sitten joku wlan-reititin jolla tuon voi tehdä.
