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.
Já jsem si na to udělal skript telnets
, ve kterém je:
openssl s_client -connect $server:$port
Některé protokoly používají STARTTLS (-starttls smtp
), tak pro ně se tam přidá jeden IF.
Pokud je protokol binární, tak si člověk se serverem tímhle způsobem povídat nemůže, ale často stačí ověřit, že se vůbec dá připojit (TCP) a že funguje šifrování (SSL/TLS) případně zkontrolovat, jestli je tam důvěryhodný certifikát.
Pak už nastupuje tcpdump/wireshark, kde se člověk dozví zase o něco víc. Pakety můžeme zachytávat jak na straně kliente, tak někde cestou, tak na cílovém serveru (posílat si je k sobě v reálném čase přes SSH nebo si je uložit do souboru a později stáhnout).
Ještě bych pro jistotu zkusil netstat
/ss
nebo se připojoval na IP adresu, abych vyloučil nějaké problémy s DNS (kdyby se jméno překládalo na špatnou adresu).
telnet xx.xx.xx.xx 1194 telnet dyndns.dyn 1194preslo to vporiadku. ping tak isto fungoval. Neviem teda preco to nefunguje. Je uplne jasne, ze problem ma ISP, ale neviem aky. ISP tvrdi, ze nic neblokuje. A aj keby blokoval, tak sa neprizna. S tcpdump a traceroute az tak neviem pracovat, takze zrejme budem musiet postudovat.
S tcpdump a traceroute az tak neviem pracovat, takze zrejme budem musiet postudovat.traceroute se spustí přesně tak jak jsem napsal (nevšiml jsem si že máš openvpn přes TCP, takže jenom ty varianty s -T). tcpdump se používá "tcpdump -ni eth0 port 1194". Ale ty píšeš že ti telnet prochází? Jako že se to spojí (ale pak už nic neuděláš, alespoň moje openvpn mě odpojí když tam něco napíšu -- a zaloguje
2022-02-19 19:59:50 localhost openvpn[414]: TCP connection established with [AF_INET]86.49.249.167:61240 2022-02-19 19:59:54 localhost openvpn[414]: 86.49.249.167:61240 WARNING: Bad encapsulated packet length from peer (26212), which must be > 0 and <= 1626 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...] 2022-02-19 19:59:54 localhost openvpn[414]: 86.49.249.167:61240 Connection reset, restarting [0] 2022-02-19 19:59:54 localhost openvpn[414]: 86.49.249.167:61240 SIGUSR1[soft,connection-reset] received, client-instance restarting). Každopádně pokud spojení projde a umře to až později, tak o tom určitě bude napsána spousta věcí v openvpn logu. Ještě mě napadá že by problém mohlo být MTU a třeba se to zasekne v okamžiku kdy se pokusí odeslat TLS certifikáty. Zkusil bych
ip l s mtu 1280 dev eth0
.
Feb 20 09:26:46 jojo-Latitude-D610 ovpn-client[1240]: OpenVPN 2.3.2 i686-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Jun 22 2017 Feb 20 09:26:46 jojo-Latitude-D610 ovpn-client[1240]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info. Feb 20 09:26:46 jojo-Latitude-D610 ovpn-client[1240]: WARNING: file 'client.key' is group or others accessible Feb 20 09:26:46 jojo-Latitude-D610 ovpn-client[1240]: RESOLVE: Cannot resolve host address: domain.dyndns.com: Temporary failure in name resolution Feb 20 09:26:46 jojo-Latitude-D610 ovpn-client[1243]: RESOLVE: Cannot resolve host address: domain.dyndns.com: Temporary failure in name resolution Feb 20 09:26:51 jojo-Latitude-D610 ovpn-client[1243]: RESOLVE: Cannot resolve host address: domain.dyndns.com: Temporary failure in name resolution Feb 20 09:26:56 jojo-Latitude-D610 ovpn-client[1243]: RESOLVE: Cannot resolve host address: domain.dyndns.com: Temporary failure in name resolution Feb 20 09:27:01 jojo-Latitude-D610 ovpn-client[1243]: RESOLVE: Cannot resolve host address: domain.dyndns.com: Temporary failure in name resolution Feb 20 09:27:06 jojo-Latitude-D610 ovpn-client[1243]: Attempting to establish TCP connection with [AF_INET]xx.25.258.98:1194 [nonblock] Feb 20 09:27:07 jojo-Latitude-D610 ovpn-client[1243]: TCP: connect to [AF_INET]xx.25.258.98:1194 failed, will try again in 5 seconds: Connection refused Feb 20 09:27:14 jojo-Latitude-D610 ovpn-client[1243]: TCP: connect to [AF_INET]xx.25.258.98:1194 failed, will try again in 5 seconds: Connection refused Feb 20 09:27:50 jojo-Latitude-D610 ovpn-client[1243]: message repeated 6 times: [ TCP: connect to [AF_INET]xx.25.258.98:1194 failed, will try again in 5 seconds: Connection refused] Feb 20 09:27:56 jojo-Latitude-D610 ovpn-client[1243]: TCP: connect to [AF_INET]xx.25.258.98:1194 failed, will try again in 5 seconds: Connection refused Feb 20 09:28:21 jojo-Latitude-D610 ovpn-client[1243]: message repeated 4 times: [ TCP: connect to [AF_INET]xx.25.258.98:1194 failed, will try again in 5 seconds: Connection refused] Feb 20 09:28:27 jojo-Latitude-D610 ovpn-client[1243]: TCP: connect to [AF_INET]xx.25.258.98:1194 failed, will try again in 5 seconds: Connection refused Feb 20 09:28:33 jojo-Latitude-D610 ovpn-client[1243]: TCP: connect to [AF_INET]xx.25.258.98:1194 failed, will try again in 5 seconds: Connection refused Feb 20 09:28:39 jojo-Latitude-D610 ovpn-client[1243]: TCP: connect to [AF_INET]xx.25.258.98:1194 failed, will try again in 5 seconds: Connection refused Feb 20 09:28:45 jojo-Latitude-D610 ovpn-client[1243]: TCP: connect to [AF_INET]xx.25.258.98:1194 failed, will try again in 5 seconds: Connection refused Feb 20 09:29:15 jojo-Latitude-D610 ovpn-client[1243]: message repeated 5 times: [ TCP: connect to [AF_INET]xx.25.258.98:1194 failed, will try again in 5 seconds: Connection refused] Feb 20 09:29:20 jojo-Latitude-D610 ovpn-client[1243]: RESOLVE: Cannot resolve host address: domain.dyndns.com: Temporary failure in name resolution Feb 20 09:29:20 jojo-Latitude-D610 ovpn-client[1243]: TCP: connect to [AF_INET]xx.25.258.98:1194 failed, will try again in 5 seconds: Network is unreachable Feb 20 09:29:25 jojo-Latitude-D610 ovpn-client[1243]: RESOLVE: Cannot resolve host address: domain.dyndns.com: Temporary failure in name resolution Feb 20 09:29:25 jojo-Latitude-D610 ovpn-client[1243]: TCP: connect to [AF_INET]xx.25.258.98:1194 failed, will try again in 5 seconds: Network is unreachable .....Z coho je vidiet, ze nie je mozne vyriesit domain name. Server ma dynamicku verejnu IP. Este pred tym ked sme zistili problem, tak na servery admin zmenil IP adresu, ale problem sa nevyriesil. Vytvorenim novej dyndns adresy sa vsetko vyriesilo. Len neviem preco ISP dal tuto dyndns na svoj blacklist ? Je to OpenVPN, takze netusi co tam tecie, neviem ake mal dovody.
curl -vkI blokovana-domena.dns.com * Rebuilt URL to: blokovana-domena.dns.com/ * Trying xxx.25.251.35... * TCP_NODELAY set * Connected to blokovana-domena.dns.com (xxx.25.251.35) port 80 (#0) > HEAD / HTTP/1.1 > Host: blokovana-domena.dns.com > User-Agent: curl/7.53.1 > Accept: */* > < HTTP/1.1 200 OK HTTP/1.1 200 OK < Date: Mon, 21 Feb 2022 18:33:57 GMT Date: Mon, 21 Feb 2022 18:33:57 GMT < Server: Kestrel Server: Kestrel < * Connection #0 to host blokovana-domena.dns.com left intactZ ripe.net vypliva, ze ISP ma zakupeny blok /22 a tato IP xxx.25.251.35 rozhodne patri ISP. Cize to smeruje na svoj nejaky win server. Nova domena, ktora funguje bez problemov
curl -vkI nova-domena.dns.com * Rebuilt URL to: nova-domena.dns.com/ * Trying xx.103.29.165... * TCP_NODELAY set * Connected to nova-domena.dns.com (xx.103.29.165) port 80 (#0) > HEAD / HTTP/1.1 > Host: nova-domena.dns.com > User-Agent: curl/7.53.1 > Accept: */* > < HTTP/1.1 200 OK HTTP/1.1 200 OK < Server: nginx/1.14.2 Server: nginx/1.14.2 < Date: Mon, 21 Feb 2022 18:39:01 GMT Date: Mon, 21 Feb 2022 18:39:01 GMT < Content-Type: text/html Content-Type: text/html < Content-Length: 612 Content-Length: 612 < Last-Modified: Thu, 22 Apr 2021 18:10:24 GMT Last-Modified: Thu, 22 Apr 2021 18:10:24 GMT < Connection: keep-alive Connection: keep-alive < ETag: "6081bc10-264" ETag: "6081bc10-264" < Accept-Ranges: bytes Accept-Ranges: bytes < * Connection #0 to host nova-domena.dns.com left intactTato IP xx.103.29.165 je adresa skutocneho servera na ktorej sedi openvpn server. Koniec koncov na novej domene vsetko funguje, ale nerozumiem preco ISP nasu domenu blokoval. Domena je tretieho radu vytvorena na free dns servery, mozno sa mu v tej domene nepacilo pismeno "x". Inak si to neviem vysvetlit. A ked som vcera skusal ping a podobne srandy, tak sa zdalo, ze to funguje. Ono ping aj fungoval, ale ja som si nevsimol, ze to pinguje IP adresu, ktora patri ISP a nie openvpn serveru. Ja nie som nijaky specialista na siete, ale myslim, ze toto co robi ISP nie je v sulade z beznym ISP.
ale nerozumiem preco ISP nasu domenu blokovalSkús sa na toto opýtať ISP, predpokladám že má nejakú linku podpory zákazníkov. Žeby tá DynDNS doména vypršala nevylučujem. V prípade zadarmových služieb im bolo treba odklepnúť že ich človek stále chce. Upozornenie chodieva emailom. Ale používam Dynamické DNS od inej firmy.
dig @dns.server.isp doména
a dig @8.8.8.8 doména
.
nslookup ns1.isp.sk blokovana-domena.dns.com Server: 192.168.55.1 Address 1: 192.168.55.1 Name: ns1.isp.sk Address 1: xxx.25.248.2 ns1.isp.sk
nslookup 8.8.8.8 blokovana-domena.dns.com Server: 192.168.55.1 Address 1: 192.168.55.1 Name: 8.8.8.8 Address 1: 8.8.8.8 dns.google
$ nslookup root.cz 8.8.8.8 Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: root.cz Address: 91.213.160.188 Name: root.cz Address: 2001:67c:68::76Každopádně jsme se jako od "blokovanie portu" dostali přes "blokuje mi DNS resolving" a "resolvuje se to na povdrženou adresu" po "resolvuje se to na RFC1918 adresu" a do naprostého zmatení. Tímto s diskuzí končím, protože to nikam nevede. Zkus to příště popsat líp.
Je uplne jasne, ze problem je u ISP. Skusil som telnetpřičemž telnet přelozenou adresu aktivně vypisujetelnet xx.xx.xx.xx 1194 telnet dyndns.dyn 1194preslo to vporiadku.
$ telnet nix.cz 80 Trying 93.190.134.171... Connected to nix.cz. Escape character is '^]'.tak by si toho snad proboha všiml a pak zase že problém s DNS…
64 bytes from xx.103.29.165: seq=0 ttl=243 time=21.068 ms 64 bytes from xx.103.29.165: seq=1 ttl=243 time=21.562 ms 64 bytes from xx.103.29.165: seq=2 ttl=243 time=21.648 msale ono tam je toto
64 bytes from xxx.25.251.35: seq=0 ttl=61 time=2.092 ms 64 bytes from xxx.25.251.35: seq=1 ttl=61 time=2.193 ms 64 bytes from xxx.25.251.35: seq=2 ttl=61 time=2.197 msMohlo ma napadnut uz pri time 2ms, ze nieco nie je v poriadku. Cize ping nesmeroval na Ip adresu ovpn servera, ale niekde na server ISP. V #36 sa napisalo, ze doticny diskusiu konci. Ja som ale este skusil obratit dns a host a vysledky boli tieto
nslookup blokovana-domena.dns.com ns1.dns.sk Server: 192.168.55.1 Address 1: 192.168.55.1 Name: blokovana-domena.dns.com Address 1: xxx.25.251.34 redirect.whalebone.ioZ toho sa da dedukovat, ze ISP pouziva whalebone a ani o tom nevie, ze nieco moze byt cez whalebone odfiltrovane (kedze mi tvrdil, ze nic neblokuje). Zhodou okolnosti som medzi tym od uplne ineho ISP (ktory tak isto vyuziva sluzby od whalebone) skusil ping a tak isto to vratilo IP adresu od ISP (a nie skutocnu IP adresu ovpn servera). Cize dalsou opravou moze byt zmena DNS servera (u klienta, cize u mna). To som este zatial neskusil. Neviem ci whalebone ma nejake blacklisty, ktore su verejne dostupne, ale problem bude najskor u whalebone.
Mam od ISP privatnu IPv4 adresu.
Huh? Připoj se tam normálně přes IPv6. Nemá smysl řešit nějaký předpotopní nesmysl z roku 1975 (IPv4).
Tiskni
Sdílej: