Inlägg

Tyvärr är väl IoT-prylar förmodligen de som riskerar att sakna IPv6-stöd.

Det är ju definitivt en risk, ja. Rent generellt behöver man göra sin research innan man köper IoT-prylar.

Kan du visa din konfiguration i routern?

Har du kollat om den subdomän du fått tilldelad faktiskt uppdaterats att peka på din externa IP? Du kan testa genom att köra kommandot:

nslookup xxxx.ddns.net

Brandväggen på routern lär också blockera anslutningar utifrån eftersom det generellt är en väldigt dålig idé att exponera gränssnittet mot internet. Dessa typer av konsumentroutrar visar sig ofta förr eller senare ha sårbarheter som folk kan utnyttja för att ta över ditt nätverk, göra den del av ett botnät, eller liknande.

Problemet med Unifi Express är att möjligheterna att bygga vidare på den är väldigt begränsade med tanke på att den bara har stöd för att hantera 4 ytterligare Unifi-enheter.

Nej, men skulle gärna läsa mer om det.

Om du inte har kvar en backup från controller-mjukvaran så får du fabriksåterställa alla Unifi-APs och sätta upp en ny controller någonstans som du adopterar dina APs till.

Mobilappen har stöd för en AP i standalone mode, men det är inte så man kör flera APs och du förlorar en hel del funktionalitet då.

Ja, det beror ju på planlösningen men jag tycker att det känns på gränsen. Då tycker jag man ska vara försiktig med att köpa en enhet där man redan från början är väldigt nära gränsen för vad den klarar. Man bör också vara inställd på att man måste ta räckviddssiffrorna med en stor nypa salt då de är i optimala förhållanden, vilket praktiskt taget ingen har.

Det styrs ju också av vilka prestandakrav man har. Jag räknar exempelvis inte annat än 5 GHz och 6 GHz som tillräckligt för annat än IoT-prylar. 2.4 GHz är helt enkelt för långsamt och "överbefolkat" för att förlita sig på.

Du kan såvitt jag vet stänga av Remote Access (dvs. möjligheten att nå den via unifi.ui.com) även på Cloud Gateway-enheterna, precis som man kan göra i sin separata controller.

Det går dock inte att stänga av den interna controllern eller managera dem med en annan controller.

I ditt fall låter det som att du bör satsa på UXG-Lite eller en UXG-Max istället eftersom du troligen redan har en bra lösning för att köra controllern.

En perimeterbrandvägg minskar attackytan, vilket knappast skadar. Så länge man sedan kan släppa igenom trafik rakt till/från en enhet (via IPv6) så ser jag inte vad nackdelen skulle vara. Du får fortfarande alla fördelar.

Detta är irrelevent dock eftersom min kommentar var en reaktion på det implicita påståendet att IPv4 + NAT är bättre för att vi minskar risken med IoT-prylar direkt anslutna till internet då. Min poäng var att praktiskt taget alla uppsättningar av IPv6 har en brandvägg mellan så i praktiken är vi lika skyddade med "IPv6 + brandvägg" som av "IPv4 + NAT".

För att "det centrala navet" (routern) uppdateras regelbundet medan IoT-prylen i många fall inte uppdateras alls eller enbart några enstaka gånger. Många av IoT-enheterna kommer ju redan från början med sårbar mjukvara och resurserna som läggs på den mjukvaran tenderar att vara väldigt begränsade, vilket troligen är själva grundorsaken.

Pratar man om egna servrar eller liknande är det ju en annan sak, men när man diskuterar IoT-prylar med dålig säkerhet är det oftast inte dessa man syftar på, vilket gör dem ganska ointressanta i sammanhanget.

En del ISP:er ger dig en IPv6-adress för din routers WAN-interface (tror att det handlar om enbart en eller ett fåtal), men detta är egentligen onödigt då det går utmärkt att din router och nästa hopp i kedjan kommunicerar med varandra via deras Link-Local-adresser. Eftersom man med IPv6 får nät tilldelade och routade till sig istället för enskilda IP-adresser så kommer man behöva någon enhet som agerar router. Min routers WAN-interface har ingen IPv6-adress annat än sin Link-Local.

Man tilldelas normalt ett /56 som privatkund via prefix delegation, dvs. 256 st /64-nät. En switch bör inte göra att du får fler /56-nät, men det vore ju faktiskt lite intressant att testa. Det finns ju dock någon stor ISP i USA som enbart tilldelar dig ett /64 istället för ett /56 (eller ett /60 som jag tror Comcast kör med), men det går att begära ut flera separata /64 så pfSense/OPNsense har ett fulhack inbyggt för att göra detta.

Tekniskt sett behöver ju en router inte nödvändigtvis också agera brandvägg, även om den rimligen gör det för i princip alla användarna i praktiken. Det är som du säger därför en närmast obefintlig risk som inte på något sätt borde tillåtas hämma utrullningen av IPv6.

Har aldrig använt WPS så att vara utan det känns inte som någon större nackdel för mig personligen.

Vad händer när du försöker ansluta skrivaren på normalt sätt? Vilken skrivarmodell är det?

De behöver förhandla om avtalet, förutsatt att föreningen inte fortfarande är bunden på något sätt. Alla ISP:er offererar 1000/1000 som standard för en låg kostnad. Alla hastigheter under det låter som ett resultat av ett gammalt avtal.

Erbjud dig att hjälpa till med denna omförhandling om du vill kunna påverka resultatet.

Bra fråga. Du får nog undersöka avtalet. Misstänker att exklusiviteten inte nödvändigtvis gäller för evigt, men bör framgå.

Känns ändå värt att undersöka om det inte finns en annan ISP som du kan kopplas över till i närmaste kopplingspunkt så att du slipper Telia. Brukar kunna bli betydligt mer rimliga priser.

Låter som ett tillfälle då Chromecast Audio skulle fungera ypperligt. Tyvärr säljs de ju inte längre, men de gjorde ju godtyckliga ljudanläggningar med AUX-ingång till Sonos-liknande högtalare i Googles ekosystem.

Det är inte heller sant, särskilt globalt. Vissa länder är ju över 70% IPv6 och de allra flesta av de populäraste tjänsterna har stöd för det. Flera länder börjar ju även kräva att myndigheter blir antingen dual stack eller i flera fall IPv6-Only.

Varför skulle man ansluta IoT-enheter rakt till internet bara för att man kör IPv6? Som standard har ju de allra flesta routrar en brandvägg som blockerar alla inkommande IPv6-trafik som inte är anslutningar initierade av någon enhet på insidan. På det sättet skiljer det sig inte från IPv4 + NAT (där man förövrigt också normalt har en brandvägg utöver NAT).

De routrar som inte har det är sådana riktade mot enterprise-marknaden där enheter bakom den inte ens kan nå internet innan man konfigurerat den. De som använder sådana har rimligen något slags hum om vad de håller på med.

Behovet för reverse proxies tror jag inte kommer försvinna. De fyller fortfarande ett syfte. NAT kan man dock i de allra flesta fall slippa, vilket är väldigt skönt.

Så längde din ISP inte godtyckligt ändrar ditt prefix då och då så kan du använda DNS för att lösa det. Det finns ju även mDNS som löser samma sak.

Det hade jag faktiskt inte sett. Riktigt missvisande marknadsföring.

En vanlig anledning till att vissa APs saknar 6 GHz, utöver kostnad, är att de även är tänkta att kunna användas utomhus. Kraven för att få köra WiFi på 6 GHz-bandet utomhus är ganska höga. Detta gäller åtminstone i USA, men oavsett om det gäller globalt eller ej så kommer ju produkterna oftast anpassas till de mest strikta kraven.

WiFi 7 garanterar inte 6 GHz, nej. Det är sant oavsett region.

Om du läser Readme:n där så ser du att det är gamla moddar som inte fungerar bra på Unifi OS 3.x (och senare).

Suricata används väl redan behind the scenes så att säga för IDS/IPS-funktionaliteten i Unifi OS. Den är dock betydligt mer begränsad än vad Suricata kan leverera.

Det är sannolikt att det fungerar, men det är inget de officiellt ger support på.

Det duger fint med CAT 6 över kortare avstånd eller CAT 6a över längre.

Bör ju funka även med CAT 8 givetvis. Bra att du skippade CAT7.

Du utelämnar en del viktig information. Letar du efter 10GBASE-T (dvs. RJ45-kontakt) eller SFP+? Hur många PCI-E lanes har du lediga, och vilken version?

Själv kör jag ett Intel X710-DA2 från eBay som ursprungligen kommer från en Dell-server för att kunna få 10 Gbit/s till min switch via fiber.

Ok, ja det är riktigt mystiskt. Har inget bra förslag tyvärr.