Příspěvky

541

Sítě / Re:Zjištění cizí veřejné IP adresy

« kdy: 08. 11. 2012, 11:33:48 »

Zdravím, chtěl bych se zeptat, jestli existuje možnost jak vyhledat cizí veřejnou IP adresu, pokud mám v počítači nainstalovaný program pro vzdálené sledování např. tiskárny a vidím v systému její připojení i momentální lokální IP adresu a její stav. Jedná se mi o toto. Sleduji u zákazníka tiskárnu a ta byla přemístěna někam jinam. V systému ji sice stále vidím včetně toho jak se na ní pracuje, ale potřebuji zjistit, kde momentálně fyzicky stojí. Vím, že takovou informaci je velmi obtížné zjistit, ale naivně si myslím, že nějaký způsob vyhledání existuje. Předem děkuji za vaše podněty a rady.

Kam se ta tiskárna připojuje? Je to váš server? Pokud ano, otevřete netstat a uvidíte odkud je připojená. Pokud to je cizí server, nebo nějaký cloud, máte zřejmě smůlu.

542

Hardware / Re:WiFi router - 120Mbps - domaci

« kdy: 27. 10. 2012, 10:43:52 »

TL-WDR4300 potrebuje na využitie potenciálu silnejší prímač, najlepšie taký, ktorý dokáže využiť obe pásma, napríklad http://www.alza.sk/tp-link-tl-wdn4800-d322961.htm , prípadne mini-PCI alebo miniPCI-e s chipsetom AR9390, do notebooku je to napríklad http://www.modem-help.co.uk/Atheros/XB114-AR9390-11abgn-PCIe-Mini-Card-Reference-Design.html

Obě pásma současně nepotřebuje, v tom routeru jsou dva naprosto nezávislé Wi-Fi adaptéry, jeden na 2.4 (s max rychlostí 300Mbps) a jeden na 5 GHz (s max rychlostí 450). Proto se router označuje N750, ale žádný protokol na používání obou pásem současně jedním klientem podporován není.

Jinak mnou naměřené hodnoty platí jak při originálním firmware, tak i s OpenWRT proti notebooku s kartou IWL4965 a krátké vzdálenosti.

543

Hardware / Re:WiFi router - 120Mbps - domaci

« kdy: 26. 10. 2012, 20:39:15 »

…IPv6, coz ale predpokladam je dnes samozrejmost…

Bohužel, zdaleka ne. Zrovna firmware zmíněného TL-WDR4300, o IPv6 neví ale vůbec nic. Dost ostuda. Naštěstí je podporován v OpenWRT, byť Wifi ovladač není tak zralý jako v originálním firmware.

Podařilo se mi přes 802.11an wifi protáhnout max. 30/60 Mbps. Netuším, proč je downstream pomalejší.

544

Sítě / Re:Vzdálené připojení k řídící jednotce

« kdy: 25. 10. 2012, 10:09:35 »

Nemusite krkavcum platit za verejnou ip.

Musí. Tedy za předpokladu, že xDSL přípojka dosud není zřízená a zároveň že řídicí jednotka neumí IPv6. Na xDSL přípojkách zřízených po 1. 7. 2012 je už jen privátní IPv4 adresa a IPv6. Takže přesměrování IPv4 portu nebude  možné.

545

Software / Re:Vážná chyba v ext4 v nových jádrech

« kdy: 25. 10. 2012, 10:01:43 »

Zdroj: https://lkml.org/lkml/2012/10/24/535

Ale i přesto, oddechl jsem si, když jsem zjistil, že mám 3.6.1

546

Server / Re:Google apps a reverzní záznam

« kdy: 25. 10. 2012, 09:36:44 »

A musí to být problém v DNS? Obvykle se při debuggování e-mailové komunikace vyplatí kontaktovat provozovatele mailserveru, popřípadě mailserverů obou stran, a zeptat se, zda pošta skutečně odešla, zda byla přijata, nebo proč byla vyhodnocena jako spam. Jen nevím, jak se na takové dotazy bude Google tvářit.

547

Server / Re:Google apps a reverzní záznam

« kdy: 24. 10. 2012, 22:19:03 »

Děkuji za info... Dostal jsem informaci, že některé emaily vůbec nedorazí - nemůže to být tím, že DNS vrací "truncated" a pak si nestáhne celou odpověď a vlastně to ani neodešle? Nebo to vše chápu úplně špatně a problém je jinde... ?

To by skutečně mohl být problém. Ale v tomto případě se to nezdá. maximální délka zprávy, včetně DNSSEC podpisů, je 973 bajtů, bez DNSSECu dokonce jen 255. Takže by k oříznutí nikdy dojít nemělo (bez EDNS0 je podporováno 512 B, s EDNS0, které je potřebné pro DNSSEC pak je podporováno až 4 KB):

Kód: [Vybrat]

$ dig rada.cz mx +notcp +dnssec

; <<>> DiG 9.9.1-P2 <<>> rada.cz mx +notcp +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10957
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 6, AUTHORITY: 5, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;rada.cz.                       IN      MX

;; ANSWER SECTION:
rada.cz.                816     IN      MX      40 ASPMX2.GOOGLEMAIL.COM.
rada.cz.                816     IN      MX      50 ASPMX3.GOOGLEMAIL.COM.
rada.cz.                816     IN      MX      1 ASPMX.L.GOOGLE.COM.
rada.cz.                816     IN      MX      20 ALT1.ASPMX.L.GOOGLE.COM.
rada.cz.                816     IN      MX      30 ALT2.ASPMX.L.GOOGLE.COM.
rada.cz.                816     IN      RRSIG   MX 5 2 3600 20121102085003 20121023085003 61340 rada.cz. bh166Hzz8+se0YXUrXvT2UA+RDL89Vd8cCMifDvUyv6QCOcxqre+NtV2 DPdFuTu7I7Mx5+lHzK5s7+qKOY65A3LDMdmlHBDw5rGqJdKiKGbL3frm fnQLSWvAwnrBEBQuXxU0KwoeW79NLR0OioL/s89go3DJ/VCd/NStT01O OLSHoxleH+dkxgsPmkonPjDnt3K4r7CjBjkvGejjrAtHJioJZJyE3Jwv 9kkH46V4Q+CzXsZHwLvRSzSCC9tKOFad3WGB8TdR1AqG4wjXzLvpBt6b ocstL3QsD1TQD22p5DsTs2XZ5g5Dd3+b7hpV3rZhDrUj0OPRXkOxMm1L Vn7Wu+CzEN+GKpHZGCQ1bDAiAqllwsLredG8Rxee1olwWnCcIchvSu1a 4Aqod8WezmIdxXoOVHD3z5KaVlDYcTWGxQ8=

;; AUTHORITY SECTION:
rada.cz.                816     IN      NS      ns4.tele3.sk.
rada.cz.                816     IN      NS      ns2.tele3.cz.
rada.cz.                816     IN      NS      ns1.tele3.cz.
rada.cz.                816     IN      NS      ns3.tele3.cz.
rada.cz.                816     IN      RRSIG   NS 5 2 3600 20121102085003 20121023085003 61340 rada.cz. V0QsZUUgBgqdBczx81m4cv8ulupZ5FWM+8PC1DcVYLplpoYBtVq47s3C fMI1VJRxihCZ7N6uuOTZUjylBbFqhgRVlKuyQuwrBbdnm5sci6g9J4ag iOMU6lAZIf0PrBxEfNpyK9cMT0InZL7w+nX82SFqfX20XBNukfvPByw5 byap8IwyBXMoNX/kDSyzwyEuyAvrUtNkrFGVo2glMib2VyWKoGFSdxRy N/iTtskUz3q0LGS+5knZFn8NRJmtlc2VDj9SFAZPPMwRRAns29eCtfi+ Ral6XMphMczwkiByhrA2FwfuoqEme7K0g5Nu0ieUShNCv936bwxHsUIJ X4WtNkjSJIhLpWVB6RV2wZrGcdbdE8CGaihrHbnBe5Eq8ohxEnMHd004 JbE7fVwqTNIdU+0SEwwnikKu65wzDrt5IN4=

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Oct 24 22:18:21 2012
;; MSG SIZE  rcvd: 973

548

Server / Re:Google apps a reverzní záznam

« kdy: 24. 10. 2012, 21:39:43 »

2) Při testu SMTP to píše "Reverse DNS does not match SMTP Banner" co s tím? Nejspíše kvůli tomuto problému nechodí dost důležité maily...

Obávám se, že toto není závada, ale vlastnost Google Apps a obecně všech cloudovitých řešení. V podstatě to znamená, že server, vedený jako MX pro danou doménu − já vidím např ASPMX.L.GOOGLE.COM − se při navázání spojení představí takto:

Kód: [Vybrat]

$ telnet ASPMX.L.GOOGLE.COM. 25
Trying 2a00:1450:4001:c02::1a...
Connected to ASPMX.L.GOOGLE.COM..
Escape character is '^]'.
220 mx.google.com ESMTP gf1si5305905wib.47

…ale reverzní dotaz na IP adresu mailserveru vrátí namísto mx.google.com toto:

Kód: [Vybrat]

$ host 2a00:1450:4001:c02::1a
a.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.c.0.1.0.0.4.0.5.4.1.0.0.a.2.ip6.arpa domain name pointer fa-in-x1a.1e100.net.

Jediný, kdo by to mohl spravit, je Google, ale ten to opravovat jistě nebude. Na druhou stranu, stejný problém mají všichni, kteří používají Google apps, nebo i Gmail. Takže problém se spamem bych hledal někde zcela jinde.

549

Odkladiště / Re:Právní zodpovědnost za propagaci torrentů

« kdy: 16. 10. 2012, 16:03:30 »

Navadi snad google tim ze ukazuje vysledky meho hledani na nelegalni akce?

Jenže Google to nedělá úmyslně, což mimo jiné dokazuje promptním vyřizováním DMCA žádostí, nad čímž se zase pozastavuje například Jiří Peterka na iHned.cz.

Ještě bych dodal, že původního tazatele chápu, snaží se o klasický hackerský přístup k zákonu a právu, tedy přepsat zákon do programového kódu, najít v něm skulinu a tu pak zneužít. Jenže takhle to nefunguje. Zákon sice může za jistých okolností fungovat jako program, ale nikdy ho neinterpretuje stroj, ale lidé. A ti lidé mají i vlastní rozum a poznají, když se někdo o takovéto zneužití snaží.

Kdyby soudily stroje, pak by nejspíše lidem procházely i takovéto výmluvy. 
_{A ano, jsem si vědom, že odkazované video bylo pravděpodobně nahráno bez souhlasu držitelů autorských práv.}

550

Odkladiště / Re:Právní zodpovědnost za propagaci torrentů

« kdy: 16. 10. 2012, 15:36:31 »

Můj souborový systém na pevném disku je plný „jenom odkazů“ na i-nody. Já za to nemůžu, že zrovna tenhle i-nod obsahuje nelegální obsah.

SEEMS LEGIT

551

Odkladiště / Re:Právní zodpovědnost za propagaci torrentů

« kdy: 16. 10. 2012, 14:58:15 »

ja chcem len "ulahcit" nieco co uz tak ci tak funguje skoro vsade...

Pokud chceš lidem ulehčit život, co takhle se radši zaměřit na díry na trhu s legálním obsahem? Například v trafikách v ČR se prodávají legálně stovky titulů na DVD v papírovém obalu za cenu kolem 50Kč / 2 EUR. Přestože DVD nejsou nijak zabezpečena, stále dosud neexistuje služba, kde bych si mohl za obdobný poplatek jednorázově stáhnout legální ISO obraz disku, vypálit a sledovat. Pro lidi je tak často jednodušší shánět nelegální kopie na Internetu, než procházet trafiky.

552

Odkladiště / Re:Právní zodpovědnost za propagaci torrentů

« kdy: 16. 10. 2012, 12:51:23 »

Pokud je tvým úmyslem nabádat k nelegálnímu šíření obsahu, je to nelegální, bez ohledu na míru obfuskace. Takže je úplně jedno, jestli použiješ torrent soubor, magnet link, neklikací magnet link, hash, nebo třeba ten hash přepíšeš do morseovky a zveřejníš sadu teček a čárek.

Je to stejné jako s nelegálním číslem. Každou digitální informaci je možné zapsat jako jedno číslo. Takže  i šíření nějakého čísla může být nelegální. To ale neznamená, že když ti úplnou náhodou stejné číslo vyjde třeba při počítání domácího úkolu, nesmíš takový úkol odevzdat.

553

Odkladiště / Re:Nepriama propagacia torrentov - pravna zodpovednost

« kdy: 15. 10. 2012, 10:03:18 »

Vždycky se zkoumá úmysl. Pokud se prokáže, že úmyslem umístění odkazu bylo napomáhání trestné činnosti, pak nese jeho autor odpovědnost. A ano, stejnou odpovědnost nese i jakýkoli jiný způsob úmyslného napomáhání tr. č., včetně rozhovoru na ulici či kdekoli jinde.

554

Sítě / Re:Problém s prohlížečem nebo ISP?

« kdy: 04. 10. 2012, 10:57:16 »

Tohle vypadá na problém s MTU. Nejjednodušší workaround spočívá ve snížení hodnoty MTU na rozhraní, třeba na 1400.

555

Server / Re:Lokálny DNS server neforwarduje Gmail

« kdy: 29. 09. 2012, 16:56:01 »

Dumpy vypadají dobře. Ještě prosím, tenhle příkaz taky vytimeoutuje?

Kód: [Vybrat]

$ dig gmail.com a +cdflag @127.0.0.1

Pokud ne, pak je asi potřeba vypnout DNSSEC validaci, protože nadřazený server mrší DNS provoz.
Pokud jsi v takto uzamčeném prostředí a nemůžeš požádat někoho, aby ti otevřel firewall, fakt bude asi lepší udělat si generátor souboru /etc/hosts.

Nebo můžeš vyzkoušet unbound a jeho tunelování DNS provozu pomocí TCP a/nebo TLS. Pak by stačil volný přístup na port 80 nebo 443, i to ale může být problém