Open source modální textový editor Helix, inspirovaný editory Vim, Neovim či Kakoune, byl vydán ve verzi 25.07. Přehled novinek se záznamy terminálových sezení v asciinema v oznámení na webu. Detailně v CHANGELOGu na GitHubu.
Americký výrobce čipů Nvidia získal od vlády prezidenta Donalda Trumpa souhlas s prodejem svých pokročilých počítačových čipů používaných k vývoji umělé inteligence (AI) H20 do Číny. Prodej těchto čipů speciálně upravených pro čínský trh by tak mohl být brzy obnoven, uvedla firma na svém blogu. Americká vláda zakázala prodej v dubnu, v době eskalace obchodního sporu mezi oběma zeměmi. Tehdy to zdůvodnila obavami, že by čipy mohla využívat čínská armáda.
3D software Blender byl vydán ve verzi 4.5 s prodlouženou podporou. Podrobnosti v poznámkách k vydání. Videopředstavení na YouTube.
Open source webový aplikační framework Django slaví 20. narozeniny.
V Brestu dnes začala konference vývojářů a uživatelů linuxové distribuce Debian DebConf25. Na programu je řada zajímavých přednášek. Sledovat je lze online.
Před 30 lety, tj. 14. července 1995, se začala používat přípona .mp3 pro soubory s hudbou komprimovanou pomocí MPEG-2 Audio Layer 3.
Výroba 8bitových domácích počítačů Commodore 64 byla ukončena v dubnu 1994. Po více než 30 letech byl představen nový oficiální Commodore 64 Ultimate (YouTube). S deskou postavenou na FPGA. Ve 3 edicích v ceně od 299 dolarů a plánovaným dodáním v říjnu a listopadu letošního roku.
Společnost Hugging Face ve spolupráci se společností Pollen Robotics představila open source robota Reachy Mini (YouTube). Předobjednat lze lite verzi za 299 dolarů a wireless verzi s Raspberry Pi 5 za 449 dolarů.
Dnes v 17:30 bude oficiálně vydána open source počítačová hra DOGWALK vytvořena v 3D softwaru Blender a herním enginu Godot. Release party proběhne na YouTube od 17:00.
McDonald's se spojil se společností Paradox a pracovníky nabírá také pomocí AI řešení s virtuální asistentkou Olivii běžící na webu McHire. Ian Carroll a Sam Curry se na toto AI řešení blíže podívali a opravdu je překvapilo, že se mohli přihlásit pomocí jména 123456 a hesla 123456 a získat přístup k údajům o 64 milionech uchazečů o práci.
________ +------------+ / | | | +-------------+ Provider 1 +------- __ | | | / ___/ \_ +------+-------+ +------------+ | _/ \__ | if1 | / / \ | | | | Local network -----+ Linux router | | Internet \_ __/ | | | \__ __/ | if2 | \ \___/ +------+-------+ +------------+ | | | | \ +-------------+ Provider 2 +------- | | | +------------+ \________
Linux router je klasicky nastaveny na multihoming (s pouzitim viacerych smerovacich tabuliek pre jednotlivych providerov, pravidiel "ip rule", a iptables Maskarady pre oba rozhrania (if1 a if2) v pripade spojeni inicializovanych z vnutra lokalnej siete)... toto chodi bezproblemovo.
V lokalnej sieti (privatny IP rozsah) sa nachadza sluzba (nad protokolom TCP), ktora ma byt dostupna zvonka cez Providera 2 na IP adrese rozhrania if2 Linux routra a na definovanom porte.
To znamena, ze bolo potrebne do iptables pravidiel pridat DNAT pravidlo (aj s prislusnym FWD pravidlom pre filter tabulku), pre prichadzajuce TCP spojenia na IP adresu rozhrania if2 a konkretny tcp port.Na linux routri je predvolena brana v main tabulke nastavena cez providera 1.
V com je problem? Packet prichadzajuci na DNATovanu sluzbu zvonka dorazi na router, spravne je DNATovany a forwardnuty na lokalny server s verejnou sluzbou. Avsak odpoved z tejto sluzby (odpovedny TCP segment) je naspat cez smerovac forwardnuty sice so spravnou prelozenou adresou (IP adresa rozhrania if2) ale preposlany von rozhranim if1 miesto if2!!
Je mi jasne, ze v uvedenom scenari zafungovala predvolena brana na providera 1 z primarnej smerovacej tabulky... otazka je vsak, ci je to bug alebo feature? Da sa nejak zapnut kontrola odpovedajucich paketov so spojeni prichadzajucich zvonka v pripade multihomed linux servera? Myslel som, ze taketo spojenia su nejak trackovane a system vie urcit spravny odchadzajuci interfejs smerom do internetu.
Ano.. workaround existuje... staci na routri markovat pakety posielane z lokalneho servera a tym ich posielat spravne cez providera 2... ale toto nie je uz dynamicke, ale staticke rozhodovanie o odpovedajucej cesty naspat pre dany IP packet na zaklade mnou napisaneho pravidla...
Řešení dotazu:
Prave takto to mam nastavene teraz... ok, aby som bol presny, pre terajsiu situaciu pouzivam split access (popisovany v uvedenej kapitole z druheho vasho linku)... dokonca aj ten obrazok pre tuto otazku som bral odtial. Vysledok? Ten ktory popisujem v otazke.. smerom spat sa pakety smeruju cez main tabulku... nie je tam ziadna kontrola toho, ci packet povodne naozaj prisiel providerom 1 alebo nie.
Predstavoval som si funkcnost na principe, ze napr. do hlavnej smerovacej tabulky sa prida docasny host record s informaciou o tom, ktora brana (provider) sa ma pre dany IP packet cestou spat pouzit resp. podobne riesenie na zaklade internych tabuliek.
Ahoj
Jeden (asi hloupy) napad - na lokalnim rozhrani mit dve adresy (samozrejme z ruznych podsiti), na servery taky a pakety od Providera_1 posilat na LAN_Addr_1 a od Providera_2 na LAN_Addr_2? Myslenka je ta, ze server posle odpoved do stejne subsite a router podle toho pozna, pres ktereho providera ji ma poslat ven.
Mozna taky pouzit virtualni rozhrani (eth1.1, eth1.2)...
Dejv
Ahoj, dik za reakciu.
rozmyslal som aj nad tymto variantom. Problem vsak je, ze ak tych verejnych sluzieb v lokalnej sieti je viac (per server), tak sa pre kazdy server nasobia adresy a vznika podla mna este vacsia neprehladnost. Jednoduhsia varianta je markovat pakety od lokalneho servera s verejnou sluzbou a tym ich posielat von spravnym providerom. Avsak toto riesenie sa neda pouzit pre pripad, kedy by mala byt rovnaka sluzba dostupna cez oboch providerov zaroven a teda rozhodovanie Linux routra by muselo byt dynamicke (avsak tento scenar zatial nehrozi).
Split access funguje pri kontaktovani samotneho Linux routra konfigurovaneho na SplitAccess, takze ak je cielovym hostom pre IP packet zvonka samotny Linux router (a jeho nejaka verejna adresa), tak smerovanie cestou spat bude spravne (zafunguje ip rule from <IP> lookup <table>
s naslednym lookupom do smerovacej tabulky priradenej danej kontaktovanej IP adrese).
Ano, mam to presne tak, a tento moj vyssie popisovany postup SplitAccessu funguje (overene). Avsak pri mojom probleme sa jedna o jeho modifikaciu, kedy packet neskonci na samotnom Linux routri (konfigurovany na SplitAccess), ale je presmerovany kdesi do priamo pripojenej lokalnej siete. A v tom je ten rozdiel... to znamena ze nezafunguje ip rule from <IP> lookup <table>
na vracajuci sa IP packet od vnutornej sluzby, ale linux router sa k nemu sprava ako k normalnemu paketu, ktory v jeho tabulkach podlieha jedine spetnemu DNATtu (resp. od-DNAT-ovaniu). A ja riesim ci to tak ma byt a ci sa to neda nejak dynamicky osetrovat.
zial varim z toho co je (nedostatok verejnych adries). sluzba je zaroven dostupna inou formou pre inych klientov. toto je alternativa, ktora je pouzitelna a da sa povedat ze aj nutna. a ak sa nemylim DNAT je urceny prave pre taketo pripady pouzitia.
Ale ano, nie je to podla kucharok typu "Best Practices".
doufam, ze to spravne chapu, ale myslel jsem si, ze na podobne veci je mozne pouzit connection marking (-j CONNMARK) ve spolupraci s packet markem (-j MARK).
Nekde v preroutingu si nova spojeni z venku omarkovat, pro vracejici established obnovit connection marky a podle nich pak paket nechat s pomoci "ip rule fwmark" odroutovat spravnou smerovaci tabulkou.
TomasVyborne, toto je presne to, co zabralo a zaroven je to dynamicke :). O cieli CONNMARK som len pocul, nevedel na co je a kvoli comu realne vzniklo (prave kvoli tomuto typu problemu... "Very useful especially for asymmatric routing in combination with MASQUERADE" ...vid lwn.net)
V principe na linux routri staci pridat nasledovne pravidla:
-t mangle -A PREROUTING -j CONNMARK --restore-mark -t mangle -A PREROUTING -i $if1 -j MARK --set-mark 1 -t mangle -A PREROUTING -i $if1 -j CONNMARK --save-mark -t mangle -A PREROUTING -i $if1 -j MARK --set-mark 0 -t mangle -A PREROUTING -i $if2 -j MARK --set-mark 2 -t mangle -A PREROUTING -i $if2 -j CONNMARK --save-mark -t mangle -A PREROUTING -i $if2 -j MARK --set-mark 0
...a packet cestou spat dostane znova znacku (-j CONNMARK --restore-mark
), ktoru dostal jeho paket predchodca (-j MARK --set-mark X
) z toho isteho spojenia ked vchadzal routrom dnu.
Pravidla, ktore tu pisem som musel doplnit pravidlami so "--set-mark 0
", nakolko konektivita bez nich nefungovala - Lebo vchadzajuci paket bol hned oznackovany, tym automaticky vyhovel pravidlu "ip rule from all fwmark 0xZNACKA lookup <table>
" a hned zbehol to odchodzej smerovacej tabulky pre zvoleneho ISP. Preto som tym pridanym pravidlom znacku paketu zas odstranil (ale ta uz bola zapamatana v connmark (-j CONNMARK --save-mark
) takze to nevadilo) a nasledne bol paket smerovany spravne.
tomk, velke dik. Ostatnym diki za rady a napady.
Tiskni
Sdílej: