Na konferenci LinuxDays 2025 byl oficiálně představen nový router Turris Omnia NG.
Přímý přenos (YouTube) z konference LinuxDays 2025, jež probíhá tento víkend v Praze v prostorách FIT ČVUT. Na programu je spousta zajímavých přednášek.
V únoru loňského roku Úřad pro ochranu osobních údajů pravomocně uložil společnosti Avast Software pokutu 351 mil. Kč za porušení GDPR. Městský soud v Praze tuto pokutu na úterním jednání zrušil. Potvrdil ale, že společnost Avast porušila zákon, když skrze svůj zdarma dostupný antivirový program sledovala, které weby jeho uživatelé navštěvují, a tyto informace předávala dceřiné společnosti Jumpshot. Úřad pro ochranu osobních údajů
… více »Google Chrome 141 byl prohlášen za stabilní. Nejnovější stabilní verze 141.0.7390.54 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 21 bezpečnostních chyb. Za nejvážnější z nich (Heap buffer overflow in WebGPU) bylo vyplaceno 25 000 dolarů. Vylepšeny byly také nástroje pro vývojáře.
eDoklady mají kvůli vysoké zátěži technické potíže. Ministerstvo vnitra doporučuje vzít si sebou klasický občanský průkaz nebo pas.
Novým prezidentem Free Software Foundation (FSF) se stal Ian Kelling.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za září (YouTube).
Vyšla kniha Počítačové programy a autorské právo. Podle internetových stránek nakladatelství je v knize "Významný prostor věnován otevřenému a svobodnému softwaru, jeho licencím, důsledkům jejich porušení a rizikům „nakažení“ proprietárního kódu režimem open source."
Red Hat řeší bezpečnostní incident, při kterém došlo k neoprávněnému přístupu do GitLab instance používané svým konzultačním týmem.
Immich byl vydán v první stabilní verzi 2.0.0 (YouTube). Jedná se o alternativu k výchozím aplikacím od Googlu a Applu pro správu fotografií a videí umožňující vlastní hosting serveru Immich. K vyzkoušení je demo. Immich je součástí balíčků open source aplikací FUTO. Zdrojové kódy jsou k dispozici na GitHubu pod licencí AGPL-3.0.
1 Mikrotik (RouterOS) jako NAT/FIREWALL/DHCP: - ether1 - WAN - ether2 - síť 100 - 10.100.0.1/24 - ether3 - síť 200 - 10.120.0.1/24 - ether4 - síť 300 - 10.130.0.1/24 - SFP - VLAN trunk do Mikrotik switchSwitch:
- port1 - síť 100 - port2 - síť 200 - port3 - síť 300 - port4 - síť 300 - port5 - síť 300 - SFP - VLAN trunk do Mikrotiku viz. výšeSwitch mám nastavený a vyzkoušený jak potřebuju. Pročítám manuály do Mikrotiku, jejich dokumentaci a tutoriály a docházím k závěru, že tento problém lze vyřešit dvěma způsoby (možná více). První způsob:
Vytvořit interface: - SFP-vlan-100 - SFP-vlan-200 - SFP-vlan-300 Vytvořit 3 bridge: - bridge-100 s interfaci: ether2, SFP-vlan100 - bridge-200 s interfaci: ether3, SFP-vlan200 - bridge-300 s interfaci: ether4, SFP-vlan300Druhý způsob:
Vytvořit bridge: - bridge1 s interfaci: ether2, ether3, ether4, SFP a nastavit VLAN: - vlan100: tagged: SFP, untagged: ether2 - vlan200: tagged: SFP, untagged: ether3 - vlan300: tagged: SFP, untagged: ether4Oboje by dle mého mělo fungovat (testovat budu zítra). Spíš mě zaráží (možná samozřejmost - se síťařinou začínám), že to lze udělat více způsoby, každý bude mít jistě pro a proti. Cíl je jasný - udělat 3 oddělené sítě, každá budou mít svůj rozsah adres, porty, DHCP server a všechny sítě budou za 1 NATem do WAN. Je nějaký zásadní rozdíl (jak v bezpečnosti, tak v rychlosti) mezi výše uvedenými postupy? Díky moc za poznámky k řešení
/interface bridge port print
. Ak ukazuje "H
" pri nazve portu a v stlpci HW je hodnota "yes", tak je vsetko ako ma byt.[user@RB] > /interface bridge port print Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload # INTERFACE BRIDGE HW PVID PR PATH-COST INTERNA... HORIZON 0 H eth01 br01-lan yes 1 0x 10 10 none 1 H eth02 br01-lan yes 1 0x 10 10 none 2 I H eth03 br01-lan yes 1 0x 10 10 none 3 I H eth04 br01-lan yes 1 0x 10 10 none 4 H eth05 br01-lan yes 1 0x 10 10 none 5 I H eth08 br01-lan yes 1 0x 10 10 none 6 H eth09 br01-lan yes 1 0x 10 10 none 7 H eth10 br01-lan yes 1 0x 10 10 none [user@RB] >... tiez je dobre nezabudnut, ze routing ide vzdy cez CPU a linka do CPU moze limitovat rychlost spojenia medzi roznymi subnetami.
Ještě taková drobnost, v konfiguraci /interface bridge vlan bude potřeba přidat port "cpu", aby byl provoz switchován i do Mikrotika a fungoval vlan na bridge interfacu.Můžeš to prosím upřesnit port "cpu"? Ve winboxu nevidím nic, co by tomu odpovídalo, v dokumentace se o tomto portu zmiňují, ale příklad jsem nenašel. Jestli to chápu správně: vytvořím z interfacu "my-bridge" interface "my-bridge-vlan100" s VLANem 100 a tento interface potom vložím do /interface bridge vlan ?
/interface bridge add name=bridge1 vlan-filtering=yes /interface vlan add interface=bridge1 name=bridge1-vlan100 vlan-id=100 add interface=bridge1 name=bridge1-vlan200 vlan-id=200 add interface=bridge1 name=bridge1-vlan300 vlan-id=300 /ip pool add name=vlan100 ranges=192.168.0.100-192.168.0.250 add name=vlan200 ranges=192.168.20.100-192.168.20.250 add name=vlan300 ranges=192.168.30.100-192.168.30.250 /ip dhcp-server add address-pool=vlan100 disabled=no interface=bridge1-vlan100 name=dhcp-bridge1-vlan100 add address-pool=vlan200 disabled=no interface=bridge1-vlan200 name=dhcp-bridge1-vlan200 add address-pool=vlan300 disabled=no interface=bridge1-vlan300 name=dhcp-bridge1-vlan300 /interface bridge port add bridge=bridge1 interface=ether2 pvid=100 add bridge=bridge1 interface=ether3 pvid=200 add bridge=bridge1 interface=ether4 pvid=300 add bridge=bridge1 interface=ether5 /interface bridge vlan add bridge=bridge1 tagged=ether5,bridge1 untagged=ether2 vlan-ids=100 add bridge=bridge1 tagged=ether5,bridge1 untagged=ether3 vlan-ids=200 add bridge=bridge1 tagged=ether5,bridge1 untagged=ether4 vlan-ids=300 /ip address add address=192.168.0.1/24 interface=bridge1-vlan100 network=192.168.0.0 add address=192.168.20.1/24 interface=bridge1-vlan200 network=192.168.20.0 add address=192.168.30.1/24 interface=bridge1-vlan300 network=192.168.30.0 /ip dhcp-server network add address=192.168.0.0/24 dns-server=192.168.0.1 gateway=192.168.0.1 netmask=24 add address=192.168.20.0/24 dns-server=192.168.20.1 gateway=192.168.20.1 netmask=24 add address=192.168.30.0/24 dns-server=192.168.30.1 gateway=192.168.30.1 netmask=24A při kopírování v rámci sítě VLAN100 jedu s využitím CPU 1-2% 3 oddělené sítě, v každé jedna ethernetka a trunk do switch. DNS ok, DHCP ok. Ještě nastavím Wi-Fi, aby se mi podle MAC adresy přiřazovali klienti do VLAN a hotovo. Vantomas: díky!
VLAN-y podporuju skoro vsetky MKT, ale nie vsetky maju HW podporu pre offloading, cize vsetko riesi hlavne CPU a nie CPU na switch-chip-e.4011 bohužel VLAN na switchi nepodporuje, takže jestli to chápu správně prostředky CPU oproti stávajícímu řešení neušetřím.
Tiskni
Sdílej: