1. Fórum Root.cz
  2. Profil StarLink
  3. Zobrazit příspěvky
  4. Příspěvky

Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - StarLink

Stran: [1]
1
Server / Re:Spam z Celní správy
« kdy: 07. 09. 2026, 15:20:50 »
Citace: McFly  07. 09. 2026, 10:49:58
SPF ověřuje oprávnění odesílajícího serveru vůči doméně uvedené v obálkové adrese zprávy; sám o sobě neověřuje obsah zprávy ani viditelnou adresu v hlavičce From:.

Envelope-from - jm@jmmcc.com
From - servis@celnisprava.gov.cz

Ano tohle je ono - SPF Alignment:
https://mxtoolbox.com/dmarc/spf/spf-alignment

Kontroluje to ale antispam, v mém případě za to dostal ten e-mail 10.50 bodů:

Kód: [Vybrat]
DMARC_POLICY_QUARANTINE(10.50){celnisprava.gov.cz : SPF not aligned (relaxed)
Zvýším za tuto kontrolu body, aby se tyto e-maily rovnou zahazovaly.

Děkuji všem za pomoc.

2
Server / Spam z Celní správy
« kdy: 07. 09. 2026, 10:12:31 »
Ahoj,
prosím o pomoc s rozborem spamu, který se tváří že přišel z e-mailu servis@celnisprava.gov.cz. V e-mailovém klientu je v Od tato adresa, také se tato adresa vyplní jako příjemce pokud dám odpovědět (viz příloha). Není mi jasné, proč není e-mail odmítnutý na základě SPF. Doména celnisprava.gov.cz má vyplněný SPF záznam, můj smtp server hodnotí SPF záznamy u přijatých e-mailů.
V hlavičce e-mailu je vidět, že e-mail byl ve skutečnosti odeslán z adresy jm@jmmcc.com. Tato doména má také SPF záznam (softfail).

Hlavičky e-mailu:

Kód: [Vybrat]
Return-Path: <jm@jmmcc.com>
Received: from www.mujsmtpserver.cz
by elf with LMTP
id RX4BIvwjnmqwriEApa2lLQ
(envelope-from <jm@jmmcc.com>); Mon, 07 Sep 2026 04:39:56 +0200
Received: from vps.greenmediatechnology.com (vps.greenmedialead.in [103.154.184.159])
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by www.mujsmtpserver.cz (Postfix) with ESMTPS id 31E0BB8065628
for <obchod@mojedomena.cz>; Mon,  7 Sep 2026 04:39:47 +0200 (CEST)
Received: from vps.greenmedialead.in (unknown [91.188.254.229])
(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by vps.greenmediatechnology.com (Postfix) with ESMTPSA id BE712873DD35
for <obchod@mojedomena.cz>; Mon,  7 Sep 2026 06:57:23 +0530 (IST)
From: servis@celnisprava.gov.cz
To: obchod@mojedomena.cz
Subject: =?UTF-8?B?Q2VsbsOtIHNwcsOhdmE=?=
Date: 06 Sep 2026 18:27:23 -0700
Message-ID: <20260906182723.71085F61EC4CF9C6@celnisprava.gov.cz>
MIME-Version: 1.0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Spam: Yes
Log z RSPAM:

Kód: [Vybrat]
2026-09-07 04:39:56 #1469823(rspamd_proxy) <65ca8c>; proxy; rspamd_task_write_log: id: <20260906182723.71085F61EC4CF9C6@celnisprava.gov.cz>, qid: <31E0BB8065628>, ip: 103.154.184.159, from: <jm@jmmcc.com>, (default: T (add header): [12.30/15.00] [DMARC_POLICY_QUARANTINE(10.50){celnisprava.gov.cz : SPF not aligned (relaxed), No valid DKIM;quarantine;},HFILTER_HELO_IP_A(1.00){vps.greenmediatechnology.com;},FORGED_SENDER(0.30){servis@celnisprava.gov.cz;jm@jmmcc.com;},HFILTER_HELO_NORES_A_OR_MX(0.30){vps.greenmediatechnology.com;},MIME_HTML_ONLY(0.20){},ONCE_RECEIVED(0.20){},R_SPF_ALLOW(-0.20){+a:c;},ARC_NA(0.00){},ASN(0.00){asn:141004, ipnet:103.154.184.0/23, country:IN;},FROM_NEQ_ENVFROM(0.00){servis@celnisprava.gov.cz;jm@jmmcc.com;},FROM_NO_DN(0.00){},MID_RHS_MATCH_FROM(0.00){},MIME_TRACE(0.00){0:~;},MISSING_XM_UA(0.00){},NEURAL_HAM(0.00){-0.909;},PREVIOUSLY_DELIVERED(0.00){obchod@mojedomena.cz;},RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00){103.154.184.159:from;},RCPT_COUNT_ONE(0.00){1;},RCVD_COUNT_ONE(0.00){1;},RCVD_TLS_ALL(0.00){},RCVD_VIA_SMTP_AUTH(0.00){},RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00){91.188.254.229:received;},R_DKIM_NA(0.00){},SURBL_MULTI_FAIL(0.00){vps.greenmediatechnology.com:server fail;},TO_DN_NONE(0.00){},TO_MATCH_ENVRCPT_ALL(0.00){},BAYES_SPAM(0.00){11.47%;},DBL_BLOCKED_OPENRESOLVER(0.00){dundle.com:url;jmmcc.com:from_smtp;vps.greenmedialead.in:rdns;celnisprava.gov.cz:from_mime;celnisprava.gov.cz:mid;}]), len: 6848, time: 4090.816ms, dns req: 40, digest: <80e0a890a0da543daa400bab50d39caf>, rcpts: <obchod@mojedomena.cz>, mime_rcpts: <obchod@mojedomena.cz>
Děkuji

3
Sítě / Re:Připojení k VPN z Bali, Egypta a Dubaje
« kdy: 13. 03. 2024, 10:23:12 »
Mě zafungoval Websocket:

https://forum.root.cz/index.php?topic=28528.0

4
Sítě / Re:VPN ze zahraničí
« kdy: 04. 02. 2024, 15:15:44 »
Děkuji za nasměrování. Článek o WebSocket je to, co jsem hledal. Snad to bude fungovat.

5
Sítě / VPN ze zahraničí
« kdy: 02. 02. 2024, 15:39:43 »
Zdravím,
připojení VPN k firemnímu routeru ne vždy funguje ze zahraničí. Notebook s klientem VPN se v ČR normálně připojuje. V zahraničí je to ale problém, nefunguje to např. s nějakou hotelovou WiFi (tam můžou být povolené jen určité porty) ani s místní SIM kartou. Zkoušel jsem Wireguard (udp) ale i OpenVPN s tcp na portu 443. Tyto problémy se vyskytovaly např. v Egyptě nebo na Maledivách.
Napadlo mě zkusit nějakou komerční VPN a v ní spustit připojení k firemnímu routeru.
Máte s tím někdo nějaké zkušenosti, nějaká doporučení?

6
Sítě / Re:Wireguard a switche TP-link
« kdy: 16. 09. 2022, 08:28:21 »
Zkusil jsem na oba routery přidat pravidlo:
Kód: [Vybrat]
--append FORWARD --protocol tcp --tcp-flags SYN,RST SYN --jump TCPMSS --clamp-mss-to-pmtuale bez úspěchu.

Pomohlo mi nastavit MTU = 1500 na obou routerech a webové rozhraní TP-link už funguje.

7
Sítě / Wireguard a switche TP-link
« kdy: 15. 09. 2022, 16:31:06 »
Zdravím,
mám dvě lokality (A a B) spojené Wireguard tunelem. Všechno funguje správně, až na webové rozhraní malých switchů TP-Link (např. model TL-SG108E). Pokud otevřu v prohlížeči ze sítě A adresu switche v síti B, stránka se mi do prohlížeče nenačte. Ping z A na switch do sítě B funguje. S ostatním provozem také není problém (tiskárny, rdp, smb,...). Pomocí wiresharku jsem si odchytil komunikaci, vymění si 9 packetů a pak už nic.
Předtím jsem používal spojení přes OpenVPN a tam to fungovalo bez problémů.
Kde by mohla být zrada - MTU, fragmentace...?

Kód: [Vybrat]
No.     Time               Source                Destination           Protocol Length Info
      1 13:33:55.588414    IP_PC        IP_TP_LINK        TCP      78     58003 → 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 TSval=1017895603 TSecr=0 SACK_PERM=1

Frame 1: 78 bytes on wire (624 bits), 78 bytes captured (624 bits) on interface en0, id 0
Ethernet II, Src: MAC_PC (MAC_PC), Dst: MAC_TP_LINK (MAC_TP_LINK)
Internet Protocol Version 4, Src: IP_PC, Dst: IP_TP_LINK
Transmission Control Protocol, Src Port: 58003, Dst Port: 80, Seq: 0, Len: 0

No.     Time               Source                Destination           Protocol Length Info
      2 13:33:55.609355    IP_TP_LINK        IP_PC        TCP      60     80 → 58003 [SYN, ACK] Seq=0 Ack=1 Win=1460 Len=0 MSS=1460

Frame 2: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface en0, id 0
Ethernet II, Src: MAC_TP_LINK (MAC_TP_LINK), Dst: MAC_PC (MAC_PC)
Internet Protocol Version 4, Src: IP_TP_LINK, Dst: IP_PC
Transmission Control Protocol, Src Port: 80, Dst Port: 58003, Seq: 0, Ack: 1, Len: 0

No.     Time               Source                Destination           Protocol Length Info
      3 13:33:55.609499    IP_PC        IP_TP_LINK        TCP      54     58003 → 80 [ACK] Seq=1 Ack=1 Win=65535 Len=0

Frame 3: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) on interface en0, id 0
Ethernet II, Src: MAC_PC (MAC_PC), Dst: MAC_TP_LINK (MAC_TP_LINK)
Internet Protocol Version 4, Src: IP_PC, Dst: IP_TP_LINK
Transmission Control Protocol, Src Port: 58003, Dst Port: 80, Seq: 1, Ack: 1, Len: 0

No.     Time               Source                Destination           Protocol Length Info
      4 13:33:55.692900    IP_PC        IP_TP_LINK        HTTP     408    GET / HTTP/1.1

Frame 4: 408 bytes on wire (3264 bits), 408 bytes captured (3264 bits) on interface en0, id 0
Ethernet II, Src: MAC_PC (MAC_PC), Dst: MAC_TP_LINK (MAC_TP_LINK)
Internet Protocol Version 4, Src: IP_PC, Dst: IP_TP_LINK
Transmission Control Protocol, Src Port: 58003, Dst Port: 80, Seq: 1, Ack: 1, Len: 354
Hypertext Transfer Protocol

No.     Time               Source                Destination           Protocol Length Info
      5 13:33:55.712982    IP_TP_LINK        IP_PC        TCP      60     80 → 58003 [ACK] Seq=1 Ack=355 Win=1460 Len=0

Frame 5: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface en0, id 0
Ethernet II, Src: MAC_TP_LINK (MAC_TP_LINK), Dst: MAC_PC (MAC_PC)
Internet Protocol Version 4, Src: IP_TP_LINK, Dst: IP_PC
Transmission Control Protocol, Src Port: 80, Dst Port: 58003, Seq: 1, Ack: 355, Len: 0

No.     Time               Source                Destination           Protocol Length Info
      6 13:33:55.876542    IP_TP_LINK        IP_PC        TCP      889    [TCP Previous segment not captured] 80 → 58003 [ACK] Seq=10221 Ack=355 Win=1460 Len=835 [TCP segment of a reassembled PDU]

Frame 6: 889 bytes on wire (7112 bits), 889 bytes captured (7112 bits) on interface en0, id 0
Ethernet II, Src: MAC_TP_LINK (MAC_TP_LINK), Dst: MAC_PC (MAC_PC)
Internet Protocol Version 4, Src: IP_TP_LINK, Dst: IP_PC
Transmission Control Protocol, Src Port: 80, Dst Port: 58003, Seq: 10221, Ack: 355, Len: 835

No.     Time               Source                Destination           Protocol Length Info
      7 13:33:55.876547    IP_TP_LINK        IP_PC        TCP      60     80 → 58003 [FIN, ACK] Seq=11056 Ack=355 Win=1460 Len=0

Frame 7: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface en0, id 0
Ethernet II, Src: MAC_TP_LINK (MAC_TP_LINK), Dst: MAC_PC (MAC_PC)
Internet Protocol Version 4, Src: IP_TP_LINK, Dst: IP_PC
Transmission Control Protocol, Src Port: 80, Dst Port: 58003, Seq: 11056, Ack: 355, Len: 0

No.     Time               Source                Destination           Protocol Length Info
      8 13:33:55.876623    IP_PC        IP_TP_LINK        TCP      54     [TCP Dup ACK 3#1] 58003 → 80 [ACK] Seq=355 Ack=1 Win=65535 Len=0

Frame 8: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) on interface en0, id 0
Ethernet II, Src: MAC_PC (MAC_PC), Dst: MAC_TP_LINK (MAC_TP_LINK)
Internet Protocol Version 4, Src: IP_PC, Dst: IP_TP_LINK
Transmission Control Protocol, Src Port: 58003, Dst Port: 80, Seq: 355, Ack: 1, Len: 0

No.     Time               Source                Destination           Protocol Length Info
      9 13:33:55.876623    IP_PC        IP_TP_LINK        TCP      54     [TCP Dup ACK 3#2] 58003 → 80 [ACK] Seq=355 Ack=1 Win=65535 Len=0

Frame 9: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) on interface en0, id 0
Ethernet II, Src: MAC_PC (MAC_PC), Dst: MAC_TP_LINK (MAC_TP_LINK)
Internet Protocol Version 4, Src: IP_PC, Dst: IP_TP_LINK
Transmission Control Protocol, Src Port: 58003, Dst Port: 80, Seq: 355, Ack: 1, Len: 0

8
Sítě / Re:Wireguard - padá připojení
« kdy: 23. 02. 2022, 14:45:42 »
Zatím to vypadá, že problém je vyřešen po upgrade RouterOS na verzi 7.1.2.

9
Sítě / Re:Wireguard - padá připojení
« kdy: 18. 02. 2022, 21:25:26 »
Tento klient se odpojuje:

Kód: [Vybrat]
Interface]
PrivateKey = PRIVKLIC-1
Address = 192.168.65.3/24
DNS = 192.168.80.31

[Peer]
PublicKey = VEREJNYKLIC-MT
PresharedKey = PREDSDILENYKLIC1
AllowedIPs = 192.168.80.0/24, 192.168.82.0/24, 192.168.83.0/24, 192.168.65.1/32
Endpoint = IP-MT:13232
PersistentKeepalive = 25

Tento klient běží ok:

Kód: [Vybrat]
[Interface]
PrivateKey = PRIVKLIC-2
Address = 192.168.65.4/24
DNS = 192.168.80.31

[Peer]
PublicKey = VEREJNYKLIC-MT
PresharedKey = PREDSDILENYKLIC2
AllowedIPs = 192.168.80.0/24, 192.168.82.0/24, 192.168.83.0/24, 192.168.65.1/32
Endpoint = IP-MT:13232

IP adresu 192.168.65.1 má interface wireguard na MT. Adresy 192.168.65.3 a 192.168.65.4 jsou v Allowed adresses na MT.

10
Sítě / Re:Wireguard - padá připojení
« kdy: 18. 02. 2022, 20:47:41 »
PersistentKeepalive jsem také zkoušel, ale tunel se rozpojí i při kontinuálním pingu.

11
Sítě / Wireguard - padá připojení
« kdy: 18. 02. 2022, 20:17:56 »
Zdravím,
mám na Mikrotiku Wireguard, ke kterému se připojují klienti, z Windows. U některých klientů nastává rozpojení připojení asi každou minutu. V logu Wireguard na Windows se při rozpojení objevuje tato hláška:

Kód: [Vybrat]
[TUN] [KlientID] Retrying handshake with peer 1 (IPADRESA_MT:13232) because we stopped hearing back after 15 seconds

Spojení se za několik sekund obnoví, ale mezi tím popadají aplikace připojené přes tunel. Zvláštní je, že to dělají jen někteří klienti, u ostatních se Wireguard nerozpojuje. Konfigurace mají stejné, liší se samozřejmě příslušné klíče. Vyzkoušeno na jednom PC, takže odpadá možnost v různém nastavení OS. Wireguard na MT i Windows jsou poslední dostupné verze.

12
Sítě / Re:Mikrotik - Hurricane electric ipv6
« kdy: 11. 12. 2021, 09:03:09 »
Děkuji pěkně, to je ono, už to běží  :)

13
Sítě / MikroTik: nefunguje IPv6 tunel od Hurricane Electric
« kdy: 11. 12. 2021, 00:15:04 »
Zdravím,
pokouším se zprovoznit ipv6 tunel HE. Postupoval jsem podle příkladu uvedeného na HE i podle dokumentace Mikrotiku. Samotný tunel funguje, na stanicích v LAN funguje ping6 i dns. Ale to je vše. Neotevřu žádnou webovou stránku přes ipv6.
Mikrotik je model 750GL. Je připojený přes vdsl modem v bridgi, poskytovatel je Vodafone. Zkoušel jsem to na routeros 6 a teď i na 7.1.

Věděl byste někdo co s tím?

Díky

Stran: [1]