Příspěvky

106

Server / Re:Spam z domény s SPF ale bez MX záznamu

« kdy: 02. 03. 2021, 08:53:47 »

Asi to tak musí být, ale proč se teda hlídá existence domény ? Na odesílání přece stačí IP ;-)

Existenci domeny nemusis hlidat. To je tvoje (rozumna) volba.

PS Pokladas tragicke otazky.

107

Server / Re:Spam z domény s SPF ale bez MX záznamu

« kdy: 01. 03. 2021, 21:58:38 »

Ale pak je celý SPF na ..... když nekontroluje MX proti SPF.

MX zaznam se nema kontrolovat proti SPF. Proc by nekdo nemohl odesilat emaily odjinud, nez kde je prijima.

108

Sítě / Re:Terminátor Switch

« kdy: 27. 02. 2021, 14:07:55 »

Umi (WiFi)router 802.1Q na WAN portu (a mas to tak nastaveno)? Nebo mas do switche zapojen druhy kabel? (z LAN portu (WiFi)routeru? Nebo jak se tam dostane LAN segment?

109

Sítě / Re:verejny IP rozsah - je mozny prenos k inemu ISP ?

« kdy: 17. 02. 2021, 12:41:32 »

Ne. Musel bys mit PI address space a taky uz ted AS s potrebnou infrastrukturou.

110

Sítě / Re:Může si síťový prvek „najít cestu“ i bez DHCP?

« kdy: 10. 12. 2020, 11:49:19 »

U spousty switchu udajne staci preplnit tabulku mac adres a ze switche se stane hub.

111

Windows a jiné systémy / Re:Bezpečnost přístupu na SSH z Win10 přes WSL / PuTTY

« kdy: 29. 10. 2020, 06:15:11 »

Uz nejakou dobu sshd umoznuje nastavit prihlaseni pomoci klice A hesla. Ve smyslu, ze pro prihlaseni je treba zadat oboje, jinak se neprihlasite (ale samozrejme zaheslovany klic je lepsi, pokud se obavate kompromitace klice).
Treba v Centosu7 staci do konfiguraku pripsat:

AuthenticationMethods publickey,password
PubkeyAuthentication yes
PermitEmptyPasswords no

112

Software / Aplikace/System na sdileni souboru

« kdy: 25. 08. 2020, 17:40:28 »

Ahoj, pouzivate nekdo nejakou aplikaci/system na sdileni souboru napric platformami, organizacemi a jednotlivymi externisty, ktery by podepisoval stahovane soubory jmenem stahujiciho? Neco jako https://tresorit.com/ ale s tim podepisovanim? Pokud ano, co to je a jake s tim mate zkusenosti?

Dekuji

113

Sítě / Re:WhatsApp na WiFi a problem se slysitelnosti

« kdy: 10. 07. 2020, 18:29:04 »

Nezkoušeli jste, zda není problém s MTU?

MTU mame na obou stranach brany 1500 a vim, ze LTE ma MTU mensi. Ted jsem se pro jistotu dival a VLAN hlavicka zvetsuje link MTU a tudiz IP MTU nezmensuje. Na brane se da pingnout ven paketem 1472B (20B IPv4 header + 8B ICMPv4 header)

Kód: [Vybrat]

ping -M do -s 1472 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1472(1500) bytes of data.
1480 bytes from 1.1.1.1: icmp_seq=1 ttl=60 time=0.747 ms
...

Takze bych rekl, ze u sebe problem s MTU nemame.

ICMP provoz na brane omezen neni, takze by brana mela byt schopna poskladat pripadne fragmenty z druhe strany.

Nevim, myslite, ze ma smysl vnucovat pomoci DHCP WiFi klientum mensi MTU? Prijde mi to jako dost velky hazard - buh vi, jak to bude s akceptaci takove optiony napric platformami.

114

Sítě / WhatsApp na Wi-Fi slyší jen jedna strana

« kdy: 10. 07. 2020, 16:55:53 »

Zdravim. Mame na nasi WiFi siti divne problemy se slysitelnosti ve WhatsApp na iphonech. Udajne docela casto se stava, ze kdyz volany je na nasi WiFi, tak neslysi volajiciho. Kdyz se vypne WiFi, tak pres LTE to hned dalsim pokusem funguje. Nicmene problem se netyka zdaleka vsech, odhadem spise mensiny, vzdycky ipnone. Androidu je tu ale jen par (na tech se to nestava), takze vzhledem k zastoupeni to asi nebude "smeroplatne". Vsechno ostatni funguje dle ocekavani. Plus se to nedari poradne chytit, protoze kdykoli to zkousime, vsechno funguje, jak ma.

WiFi sit uz je ocesana do nejjednodussi mozne podoby - nekolik Ubiquiti UniFi UAP AC Pro (rizeni a klienti na ruznych vlanach), dnsmasq + bind + iptables paketovy filtr s NATem na linuxove brane (Centos7).

NAT je realizovan pomoci targetu MASQUERADE a filtr (po prekladu) propousti vsechno ven a jen ctstate RELATED,ESTABLISHED dovnitr (ctstate INVALID se DROPuje hned prvni pravidlem), coz myslim dava Symmetric NAT (dle klasifikace zde: https://en.wikipedia.org/wiki/Network_address_translation)

Pozadavky WhatsApp zde https://developers.facebook.com/docs/whatsapp/guides/network-requirements/ tudiz bohate splnujeme.

Nesetkal se s tim nekdo? Nema nejakou radu?

Dik moc

115

/dev/null / Re:Svátek památky obětem komunistického režimu

« kdy: 27. 06. 2020, 00:21:04 »

Osobně dobu nepamatuji, nic nepopírám, jen historické zdroje se kterými jsem se setkal nevyznívají přesvědčivě.

Jasna vec. Takovym jako ty se existence gulagu ozrejmi az teprve te tam zavrou. Ale klidek, mozna nebudes muset cekat dlouho. Kulturni revoluce je za humny.

116

Hardware / Re:BTRFS - chyby

« kdy: 09. 06. 2020, 02:11:02 »

Doporucovanou technikou je spise nechat fstab na pokoji a zapnout trimovani v klidnych dobach (protoze discard ve fstab zbytecne snizuje vykon disku) - neco jako "systemctl enable fstrim.timer" u centosu

117

Server / Re:Postfix: připojení domény k lokálním uživatelům

« kdy: 08. 06. 2020, 01:52:08 »

Je extremne dulezite neuvadet nikdy zadne verze, z nekolika nabidnutych moznosti vyzkouset jen jednu a hlavne nikdy, za zadnych okolnosti nedavat kompletni konfiguraky, ale jen dva, maximalne tri parametry. Cim mene udaju uvedete, tim rychleji a presneji lidi na foru uhodnou, o co jde. V pripade postfixu je obzvlast prisne zakazano davat vysledky utility postconf. A uvadet, jestli jste po zmene konfigurace vnutil postfixu novou konfiguraci je zarucene cestou k definitivnimu banu na foru.

118

Sítě / Re:VPN pro road warriory

« kdy: 19. 12. 2019, 21:40:40 »

Kdybych si vybíral pro firmu o 30 zaměstnancích, nechal bych u operátora zřídit APN a s žádnými VPN bych se nepatlal.

Jak tohle pomuze notebookarum na dovolene v Patagonii nebo uzivatelum WiFi iPadu?

Dik

119

Server / Re:Postfix - povolit doručování jen na konkrétní uživatele

« kdy: 10. 12. 2019, 20:53:47 »

Viz http://www.postfix.org/postconf.5.html#local_recipient_maps

120

Sítě / Re:Lokální adresy v síti ISP

« kdy: 05. 12. 2019, 20:24:44 »

messagebus: Vytrháváš z toho RFC jednu větu z kontextu. Podstatná je i ta hned předchozí. Nic to neříká o tom, že ISP na WAN port tvého CPE nemůže přidělit IPčko ze seznamu z RFC1918. Říká to jen, že IANA/RIPE/.. nepřidělí IP z těchto segmentů někomu k užívání.
Ano, bylo by lepší, aby ISP použil ty 100.64/10 dle RFC6598. Nicméně i toto RFC v čísti 3 uvádí, že ISP může pro CPE používat IP dle RFC1918 pokud ví, co dělá. :-)

Az na to, ze enterpise neni ISP  - je tam uvedena definice i priklady vetsich enterprise - letiste, banka...
A hlavne v te predchozi vete neni IANA, ale Internet Registry - seznam IR pro CZ: https://www.ripe.net/membership/indices/CZ.html Coz jsou prave ISPcka (tedy nejsou tam ti ruzni pokoutni s antenama z plechovek, co vsemu rozumi lepe nez IETF)

Nicméně původní tazatel se s tím už vyrovnal a nějak smířil. Může navrhnout ISPíkovi, aby přešel na to 100.64/10 nebo zkusit hledat připojneí u jiného.

Me na tom fascinuje, jak velky problem je proste rict "aha, sakra, to je dobra prilezitost to zacit delat lepe".