Dle plánu certifikační autorita Let's Encrypt nově vydává také certifikáty s šestidenní platností (160 hodin) s možností vystavit je na IP adresu.
V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Forgejo byla vydána ve verzi 14.0 (Mastodon). Forgejo je fork Gitei.
Just the Browser je projekt, 'který vám pomůže v internetovém prohlížeči deaktivovat funkce umělé inteligence, telemetrii, sponzorovaný obsah, integraci produktů a další nepříjemnosti' (repozitář na GitHubu). Využívá k tomu skrytá nastavení ve webových prohlížečích, určená původně pro firmy a organizace ('enterprise policies'). Pod linuxem je skriptem pro automatickou úpravu nastavení prozatím podporován pouze prohlížeč Firefox.
Svobodný multiplatformní herní engine Bevy napsaný v Rustu byl vydán ve verzi 0.18. Díky 174 přispěvatelům.
Miliardy korun na digitalizaci služeb státu nestačily. Stát do ní v letech 2020 až 2024 vložil víc než 50 miliard korun, ale původní cíl se nepodařilo splnit. Od loňského února měly být služby státu plně digitalizované a občané měli mít právo komunikovat se státem digitálně. Do tohoto data se povedlo plně digitalizovat 18 procent agendových služeb státu. Dnes to uvedl Nejvyšší kontrolní úřad (NKÚ) v souhrnné zprávě o stavu digitalizace v Česku. Zpráva vychází z výsledků víc než 50 kontrol, které NKÚ v posledních pěti letech v tomto oboru uskutečnil.
Nadace Wikimedia, která je provozovatelem internetové encyklopedie Wikipedia, oznámila u příležitosti 25. výročí vzniku encyklopedie nové licenční dohody s firmami vyvíjejícími umělou inteligenci (AI). Mezi partnery encyklopedie tak nově patří Microsoft, Amazon a Meta Platforms, ale také start-up Perplexity a francouzská společnost Mistral AI. Wikimedia má podobnou dohodu od roku 2022 také se společností Google ze skupiny
… více »D7VK byl vydán ve verzi 1.2. Jedná se o fork DXVK implementující překlad volání Direct3D 5, 6 a 7 na Vulkan. DXVK zvládá Direct3D 8, 9, 10 a 11.
Byla vydána verze 12.0.0 knihovny libvirt (Wikipedie) zastřešující různé virtualizační technologie a vytvářející jednotné rozhraní pro správu virtuálních strojů. Současně byl ve verzi 12.0.0 vydán související modul pro Python libvirt-python. Přehled novinek v poznámkách k vydání.
CreepyLink.com je nový zkracovač URL adres, 'díky kterému budou vaše odkazy vypadat tak podezřele, jak je to jen možné'. Například odkaz na abclinuxu.cz tento zkracovač převádí do podoby 'https://netflix.web-safe.link/logger_8oIlgs_free_money.php'. Dle prohlášení autora je CreepyLink alternativou ke zkracovači ShadyURL (repozitář na githubu), který dnes již bohužel není v provozu.
Na blogu Raspberry Pi byla představena rozšiřující deska Raspberry Pi AI HAT+ 2 s akcelerátorem Hailo-10 a 8 GB RAM. Na rozdíl od předchozí Raspberry Pi AI HAT+ podporuje generativní AI. Cena desky je 130 dolarů.
Wed Mar 02 23:14:19 2016 WARNING: --remote address [1.2.3.15] conflicts with --ifconfig subnet [1.2.3.17, 255.255.255.0] -- local and remote addresses cannot be inside of the --ifconfig subnet. (silence this warning with --ifconfig-nowarn).
Řešení dotazu:
Odtud bych měl rád dostupné sdílené tiskárny, adresáře ve firemní veřejné síti přes OpenVPNPocitam, ze nemate tiskarny s dostupne z internetu, takze bych navrhoval tvuj cely dotaz preformulovat tak aby daval vetsi smysl ve veci adres. Plus dolozit aktualni konfiguraci a idealne i schema.
Pocitam, ze nemate tiskarny s dostupne z internetu, takze bych navrhoval tvuj cely dotaz preformulovat tak aby daval vetsi smysl ve veci adres. Plus dolozit aktualni konfiguraci a idealne i schema.Ano, tiskárny mají veřejnou IP v rozsahu subnetu také, jejich zabezpečení je na jinou debatu. Aktuální konfiguraci jsem myslím dostatečně popsal, co je vám nejasné? Chci jen návrh funkčního přístupu ve smyslu jak jsem popsal. Děkuji za věcné příspěvky.
server má dvě ethernet rozhraní eth0 s IP 1.2.3.15/24 a eth1 s IP 1.2.3.16/24To je prece ukazkova kolize, nemuzes mit na dvou rozhranich stejnou IP sit, to uz ti musi zahlasit i system pri konfiguraci. Zadruhuhe je ti jasne, ze VPN funguje tak, ze mas jednu sit pro tunel a jednu sit tunelujes. Tvuj navrh totiz nemuze fungovat uz z principu veci. Zatreti, chtel jsem te pozadat aby jsi dolozil aktualni konfiguraci openvpn.conf pokud to neni problem.. Tzn. jeden teoreticky navrh padl verejnou sit rozdelit a pres jeden protlacit ten druhy. Otazka je jestli je to vubec realne.
Jeste bych se pozastavil napriklad nad timto:Ano, tohle všechno je pravda. Ale mě šlo právě o to jak to udělat (netrvám na VPN) abych bez nutnosti přeadresování a tedy bez použití NAT, mohl být doma součástí firemní PUBLIC sítě (proto režim bridge) - s využitím volného rozhraní eth1 na serveru, který by fungoval jako "port switche", jestli mi rozumíte? Rozdělit veřejnou síť reálné opravdu není, jak jsem už napsal v dotazu.server má dvě ethernet rozhraní eth0 s IP 1.2.3.15/24 a eth1 s IP 1.2.3.16/24To je prece ukazkova kolize, nemuzes mit na dvou rozhranich stejnou IP sit, to uz ti musi zahlasit i system pri konfiguraci. Zadruhuhe je ti jasne, ze VPN funguje tak, ze mas jednu sit pro tunel a jednu sit tunelujes. Tvuj navrh totiz nemuze fungovat uz z principu veci. Zatreti, chtel jsem te pozadat aby jsi dolozil aktualni konfiguraci openvpn.conf pokud to neni problem.. Tzn. jeden teoreticky navrh padl verejnou sit rozdelit a pres jeden protlacit ten druhy. Otazka je jestli je to vubec realne.
root@artemis:~# ip a add 172.20.0.1/24 dev eth0 root@artemis:~# ip a add 172.20.0.2/24 dev dummy0 root@artemis:~# ip -4 a 1: lo inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever ... 2: eth0 inet 172.20.0.1/24 scope global eth0 valid_lft forever preferred_lft forever ... 21: dummy0 inet 172.20.0.2/24 scope global dummy0 valid_lft forever preferred_lft forever root@artemis:~# ip r ... 172.20.0.0/24 dev eth0 proto kernel scope link src 172.20.0.1 172.20.0.0/24 dev dummy0 proto kernel scope link src 172.20.0.2Nevyhody reseni jsou jasne, chovani trochu nepredikovatelne (hlavne zdrojova adresa pri zacatku komunikace), lepsi by bylo rozhrani bondovat a nastavit adresu na bond.
Pokud budou obě rozhraní připojena do stejného segmentu (což je podle popisu pravděpodobné), bude přinejmenším potřeba trochu poladit sysctl, aby stroj neodpovídal na ARP dotazy na "špatném" rozhraní.
Jinak souhlasím, bond/team by byl lepší a pokud bude tazatel chtít používat dvě různé adresy pro různé účely, není problém je na něm nastavit obě.
..., lepsi by bylo rozhrani bondovat a nastavit adresu na bond.Nějak nerozumím. Můžete mi prosím trochu objasnit, co tím myslíte? Děkuji.
V praxi by to vypadalo např. nějak takhle:
modprobe bonding max_bonds=0 ip link add bond1 type bond mode active-backup miimon 100 ip link set eth0 master bond1 ip link set eth1 master bond1 ip link set bond1 up ip link set eth0 up ip link set eth1 up ip addr add 1.2.3.4/24 brd + dev bond1 ip addr add 1.2.3.5/24 brd + dev bond1
Použití vysokého napětí místo virtual private network doporučuju.
:)
To ovšem není odpověď na skrytou otázku, co že se myslí tím VN?VPN = virtual private network VN = virtual network
Wed Mar 02 23:14:19 2016 WARNING: --remote address [1.2.3.15] conflicts with --ifconfig subnet [1.2.3.17, 255.255.255.0] -- local and remote addresses cannot be inside of the --ifconfig subnet. (silence this warning with --ifconfig-nowarn).
To je jednoduche. Na obou stranach pouzivate neverejne IP a nahodou obe site pouzivaji stejne 
Mate v zasade dve moznosti:
Takze zvolit pro firemni sit 192.168.0.0/24, pripadne 192.168.1.0/24 je spatny napad. Vetsina domacich routeru ma stejny rozsah.
Ja aktualne pouzivam 10.123.0.0/16 a zatim jsem nemel problem.
Chcete-li, mam na blogu nejake navody na OpenVPN.
Nástřel. Musíte si tu síť /24 rozseknout na nějaké podsítě /25, /26 ... a připojovat se na ip adresu z jiné podsítě, než ze které rozdáváte ip adresy klientům připojeným přes VPN.Ano, kdyby ten subnet /24 bylo možné rozdělit, tak není co řešit. Ale bohužel nelze... :(
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
17.3.2016 11:20
ip route, ať vidíme, jak s tím navázaným tunelem vypadá routovací tabulka. Co přesně znamená „připojení nefunguje“? Zkuste po připojení ping na tu protistranu VPN spojení (1.2.3.15) a na nějaké jiné zařízení v té vzdálené síti. Ideální by bylo, pokud můžete na tom 1.2.3.15 spustit tcpdump na ICMP echo pakety a zároveň ověřit, které ty vaše pingy dorazí a zda k nim dorazí nějaká odpověď.
Mimochodem, když v popisu změníte IP adresy, je dobré to uvést, může to být matoucí.
Co přesně znamená „připojení nefunguje“? Zkuste po připojení ping na tu protistranu VPN spojení (1.2.3.15) a na nějaké jiné zařízení v té vzdálené síti. Ideální by bylo, pokud můžete na tom 1.2.3.15 spustit tcpdump na ICMP echo pakety a zároveň ověřit, které ty vaše pingy dorazí a zda k nim dorazí nějaká odpověď.To že připojení nefunguje znamená přesně to, že není ze na strany serveru odezva na ping (žádná "živá" adresa z toho subnetu). Klient se sice připojí a také přidělí adresu, masku i DNS z veřejného subnetu (direktiva "push"), ale ping nejde... Jak už tady vícekrát zaznělo, vidím problém prostě v tom, že pro připojení k serveru je použita adresa z rozsahu stejné sitě, kterou připojuji. Bohužel nevím, jak to obejít. Opravdu si myslíte, že to může fungovat? Jinak vám děkuji za odpověď.
Není ta chyba prostě jenom v nastavení firewalu na vašem serveru/klientu?Tak na serveru jsem měl při testech skript s pravidly firewallu vypnutý, ale ne tak doma na klientu s Windows. Doma zkusím připojení po jeho vypnutí a podívám se s pomocí tcdump, kde se to ztrácí... Prozatím vám moc děkuji, dám vědět jak to dopadlo. :)
Sice by ping měl tuhle adresu zvolit sám
Jediná situace, kdy si ping určuje zdrojovou adresu sám, je když mu ji explicitně zadáte pomocí "-I".
Ono to patrně nefunguje proto, že se jedná o veřejné IP adresy.Uh?
Kdyby se jednalo o neveřejné ip adresy, tak se tazatel neptá v diskusi, ale dávno mu to chodí.
Ne. Ten problém je naprosto nezávislý na tom, jestli jsou adresy "veřejné" nebo ne. Není problém vyrobit fungující konfiguraci s "veřejnými" adresami, stejně jako nefungující s "neveřejnými".
Nějak jsem si nevšiml, že byste zde poradil něco smysluplného.
V době, kdy to mělo smysl, jsem neměl čas snažit se zorientovat ve zmateném a mlhavém popisu situace a odhadovat, co asi měl tazatel skutečně na mysli. Když se to vyjasnil (a já se k diskusi dostal znovu), nemělo smysl psát znovu to, co už napsal někdo přede mnou.
A aspoň nepíšu věci, které nejsou pravda. Jako třeba že problém je v použití "veřejných" adres. To je prostě zjevný nesmysl a nadáváním ani jinými výpady na tom nic nezměníte.
Například doporučit bonding, aby se to ještě více zatemnilo.
Rozhodně je to rozumnější, než bez potřebných opatření připojit dvě rozhraní do stejného segmentu a divit se, proč mám problémy s ARP.
Je smutné, jak jsou někteří ostatní komentující tak zblblí NATy, že komunikaci na veřejných IP adresách považují za anomálii a neustále vymýšlejí, jak někam ty privátní rozsahy IP adres nacpat. Už aby IPv4 zaniklo, dokud si ještě někteří lidé pamatují, jak vypadá normální IP síť.Ano, bylo to i na vás.
.
Obávám se, že vámi nenáviděné ipv4 tady ještě nějakou dobu bude (včetně privátních rozsahů), protože spousty dosud používaných zařízení prostě ipv6 neumí.
server:
...15 adresa eth0
...16 adresa br0
br0 je bridge mezi eth1 a tap0
routa server: ...0/24 -> eth0
...17/32 -> br0
klient:
...17 adresa br0
routa klient: ...0/24 -> tap0
...15/32 -> eth0
Takze kdyz jde paket z klienta ...17, tak se posle do tap0. Tam jej openVPN zabali a posle na adresu ...15. Na serveru ...15 se paket vybali a dorazi pres eth0 k cili. Cil posle paket na ...17, ten OpenVPN zabali a posle a adresu klienta.
Tolik k teoreticke rovine. Prakticky by bylo potreba videt vypisy routovacich tabulek a kazdy krok odsledovat tcpdumpem, zda kazdy krok posle paket tam, kam ma.
Tohle je klasický use case pro IPv6 z roku 1995, který by jistě posloužil lépe než IPv4 z roku 1975.
Nemá smysl bojovat s nepoužitelností IPv4. Ta už byla velmi dobře popsaná a prozkoumaná.
Možná by pomohlo, možná ne. To už záleží na konkrétní konfiguraci sítě. K samotnému obcházení firewallu se těžko najde něco lepšího než IPSec a tam IPv6 vskutku exceluje, například tím, že se dá použít stejná (samozřejmě veřejná) adresa pro IPSec i pro nešifrovanou komunikaci (tedy něco jako %dynamic ve StrongSwan) a na routeru nastavit, co k zařízením ve vnitřní síti projde a co ne. Takže například z nešifrovaného Internetu se spojení do vnitřní sítě navazovat nedají, zatímco z IPSec připojení (ke stejné veřejné IPv6 adrese) už ano.
Jenže opět je tady celá diskuse zaplevelená OpenVPN, protože některé uživatele magicky přitahuje to „VPN“ v názvu, přestože pro 999‰ případů VPN je nejlepším řešením IPSec. IPSec je prostě součástí síťového stacku přímo v kernelu, se všemi jeho efektivními vymoženostmi. OpenVPN je řešení s minimálně dvěma extra context-switchi kvůli každému paketu a s multi-threadingem v nedohlednu. To je snad horší případ než OpenBSD, co se týká efektivity, a to už je co říct.
server:/etc/openvpn # openvpn --config prvni_bridge.conf server:/etc/openvpn # tail /var/log/openvpn.log Tue Mar 22 16:30:12 2016 Socket Buffers: R=[212992->131072] S=[212992->131072] Tue Mar 22 16:30:12 2016 TUN/TAP device tap0 opened Tue Mar 22 16:30:12 2016 TUN/TAP TX queue length set to 100 Tue Mar 22 16:30:12 2016 GID set to nogroup Tue Mar 22 16:30:12 2016 UID set to nobody Tue Mar 22 16:30:12 2016 UDPv4 link local (bound): [undef] Tue Mar 22 16:30:12 2016 UDPv4 link remote: [undef] Tue Mar 22 16:30:12 2016 MULTI: multi_init called, r=256 v=256 Tue Mar 22 16:30:12 2016 IFCONFIG POOL: base=1.2.3.17 size=2, ipv6=0 Tue Mar 22 16:30:12 2016 Initialization Sequence Completed server:/etc/openvpn # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 1.2.3.1 0.0.0.0 UG 0 0 0 eth0 1.2.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 1.2.3.0 0.0.0.0 255.255.255.0 U 0 0 0 br0 server:/etc/openvpn #
dev tap0 proto udp server-bridge 1.2.3.16 255.255.255.0 1.2.3.17 1.2.3.18 # secret secret.key push "route-gateway 1.2.3.1" push "redirect-gateway def1" push "dhcp-option DNS 1.2.244.2" # certifikat certifikacni autority ca /etc/openvpn/ca.crt # certifikat serveru cert /etc/openvpn/server.crt # klic serveru key /etc/openvpn/server.key # parametry pro Diffie-Hellman protokol dh /etc/openvpn/dh1024.pem # Verbosity level verb 3 daemon # logy serveru log-append /var/log/openvpn.log # status serveru status /var/run/vpn.status 10 # uzivatel pod kterym bezi server user nobody # skupina pod kterou bezi server group nogroup # udrzuje spojeni nazivu, 10 (ping) a 120 (ping-restart) keepalive 10 120
Jedinou řekněme "vadou na kráse" je, že klient nedostává Default Gateway subnetu 1.2.3.1/24, jak je deklarováno, ale adresu vpn serveru 1.2.3.16/24.To je ale správně. V routovací tabulce máte záznamy, že nějaká síť je dostupná přes „next hop“. Platí to i pro výchozí bránu (což je jen speciální případ, kdy ta „síť“ je 0.0.0.0/0, tedy celý Internet). „Next hop“ vždy musí být dosažitelný přímo – routování probíhá tak, že se v tabulce najde nejspecifičtější síť a paket se přímo odešle na odpovídající „next hop“. Kdyby „next hop“ mohla být libovolná IP adresa, kterou by bylo nutné znova routovat, snadno by vznikla konfigurace, ze které by nebylo možné určit, kam se má paket poslat.
Tiskni
Sdílej:
