Příspěvky

1

Server / RCPT TO na různé domény stejného MX

« kdy: Dnes v 01:03:15 »

Z jakého důvodu dostanu tuto chybu při posílání na  MX server aspmx4.googlemail.com   / banner "mx.google.com" ), který obsluhuje, na  příjemců víc na odlišných (@hostovaná a @gmail):

Kód: [Vybrat]

RCPT TO: a@gmail.com
250 OK (prohozené pořadí příjemců nehraje roli)
RCPT TO b@hipsteri.cz
451-4.3.0 Multiple destination domains per transaction is unsupported.  Please
451 4.3.0 try again. z21-....368 - gsmtp

Jiné MX servery s tím nemají problém.

K tomu by mě zajímalo : (asi není potřeba odpovídat na všechny body, některé vyplývají z jiného)
0. Jak je to správně
1. Je toto někde definované v RFC?
2. Porušuje  Gmail standardy?
3. Je seznam  a jiní benevolentní v standardech když dovolí heterogenní RCPT
4. Jakým způsobem se mají chovat MTA .Mohou sdružit různé příjemce do jedné transakce?
5. Znamená, že když ty domény mají stejný MX, tak lze uvést oba příjemce  v jedné SMTP transakci?

2

Bazar / Re:Prodám Dell Lattitude E7440 na ND

« kdy: Dnes v 00:41:35 »

Může doopravdy jít o napájecí adaptér. Kdy paradoxně když je takový adaptér zapojen, tak právě to blbne.  A nějak to přepíše frekvence CPU na nějaké low-level-úrovni, že s tím ThrottleStop nic nezmůže. Maximálně nějakou posloupností vhodného pořadí zapojení adaptéru, uspání ,probuzení se podaří zapojit "neznačkový " adaptér ,aniž by se projevilo to "uzamčení". A nebo jinak, že nějaký event probuzení resetuje stav "uzamčení" LFM, takže když zapojíš adaptér ve spánku a probudíš tak asi se to podaří takhle přelstít

Ale jev PROCHOT signál jsem nikdy neměl tu čest potkat.

Ale předpokládám, že  ThrottleStop detailně a zkusil všechno možné. V případě zaškrtlé Disable Turbo jsou hodnoty. O jakou nejnižší frekvenci jde ?  800MHz ="1"="LFM", 2100Mhz ="0", 2700="2"

Rád bych se zeptal, po výměně desky mi to dělá nějaký divný chování větráku. Jako kdyby to používalo hloupé řízení větráku pouze v závislosti na " několika málo trip pointech" místo "prediktivního"/promyšlenějšího nebo s obrovskou hysterzí (času).  V idle je z ticha jak má být. Začne zátěž, nic se neděje. Větrák se zapne až když je teplý (ne horký, 15W je šidítko). Jenže pak po skončení zátěže běží větrák třeba půl hodiny když ochladit se zvládne za 5 minut.
Navíc větrák má pouze dva stavy: vypnuto a střední. (tedy že raketoplán to není, ale je slyšet a dlouhodobě to je nepříjmné)



Chtělo by to napsat rozlišení a typ displeje, páč IPS vs TN je dealbreaker


(ach jo, radši jsem si odpověď zkopíroval do schránky, ale stejně mě to po reloadu přesměrovalo do Založení nového témutu)

3

Software / Rozepsané statistiky při použití iptables match-set (ipset)

« kdy: Dnes v 00:22:12 »

Pokud si přidám do iptables nějaké pravidla  pro skupin IP adres,pak mi iptables -vL vrátí logicky jeden řádek týkající se té  sady.
Je možné  nějakým způsobem zjistit statistiky (to co je v první a druhém sloupci příkazu výše - počet matchnutých bajtů a paketů) pro každou IP nebo záznam (což je rozdíl) zvlášť , podobně  jako kdyby to byla série pravidel iptables s --source /--dest nějakým způsobem?

Něco jako cat /proc/net/xt_recent/identifikator

tedy něco takového

Kód: [Vybrat]

z
  134  7288 DROP       all  --  *      *       000000000/24       0.0.0.0/0      set: MATCH-SET ssh-grupa      /* ssh--množina */
na:
    1    40 DROP       all  --  *      *       176.111.173.0/24     0.0.0.0/0            /* ssh--l3 */
    0     0 DROP       all  --  *      *       94.20.154.0/24       0.0.0.0/0            /* ssh--l3 */
   40  2400 DROP       all  --  *      *       195.226.194.0/24     0.0.0.0/0            /* ssh--l3 */
   93  3848 DROP       all  --  *      *       62.233.50.0/24       0.0.0.0/0            /* ssh--l3 */
Pochopitelně to nemusí být v tomhle formátu

třeba ten xt_recent má
src=128.199.138.0 ttl: 52  last_seen: 4340684258 oldest_pkt: 25 4340450426,...
src=138.199.134.0 ttl: 126 last_seen: 4340684218 oldest_pkt: 25 4340450426,...


PS: man 8 ipset nemám

4

Sítě / Re:CONNMARK --restore musí být už v PREROUTING !

« kdy: 29. 03. 2023, 00:41:10 »

Tak vyřešeno sláva !
Přišel jsem na to.  pravidlo CONNMARK restore musí být taky v PREROUTING a nestačí v forward. Máte vysvětlení?


TZN

-A PREROUTING -i tun2 -m conntrack --ctstate NEW -j CONNMARK --set-mark 7 # označí vstupní pakety z internetu objevšivší se na tun
-A OUTPUT -j CONNMARK --restore-mark   # (pro lokální procesy)
-A PREROUTING -j CONNMARK --restore-mark # ( paradoxně pro forwardování)
# ip rule add fwmark 7 table vpn

Mám k tomu otázku, je toto výkonově  optimální? V tom smyslu, že --restore connmark se volá bez zúžení ? jako označování je zúžené volnou -i tun2 , tak bych si třeba představoval, že PREROUTING -restore-mark bude upřesněné ... čím? -s 192.168.1.8 nebo lepší tip? Nebo je to zbytečné


Druhá otázka pro fajšmekry: Myslel jsem, že by pravidlo pro označování paketů set-mark by mělo stačit až ve forwardu, ale takový
čím to je? (že)  modul conntrack potřebuje ke své práci prerouting a forward je moc pozdě? z obrázku mi to ale nepšilo





A jak koukám na ten obrázek, nedokážu pochopit, kolikrát probíhá routing decision v případě forwardování paketů? jednou nebo dvakrát?



reference, který jsem zkoumal, ale stejně jsem v nich řešení nenašel
https://www.linuxquestions.org/questions/linux-networking-3/policy-routing-problem-with-fwmark-4175492857-print/
https://gist.github.com/gpolitis/512193dd88c18aeb6900229187198899
https://serverfault.com/questions/1107846/how-to-route-a-reply-packet-to-the-device-it-coming-from#
https://superuser.com/questions/950031/routing-subnet-to-specific-routing-table-with-fwmark-direct-to-isp-and-vpn

5

Sítě / Re:NAT prerouting pravidlo iptables neotevře port ; přehlednější countery

« kdy: 28. 03. 2023, 21:44:09 »

A dále je zbytečné dávat na konec pravidlo, které něco dělá pro vše. K tomu slouží politika chainu – tou se řídí vše, co dojde až na konec. A také je jednodušší politiku změnit, než odebírat poslední pravidlo a přidávat místo něj jiné.

Mno, může to mít kosmetický efekt, ve výpisu iptables -nxvL jsou vidět countery  dle mého názoru přehledněji.  A jsou vidět statistiky, "co filtry pravidla nepokryly" .Samozřejmě musí jít o pravidlo bez -j co nic nedělá.
Ostatně mám pocit, že v nějaké verzi iptables byl bug, který ukazoval nuly v hlavičce  ("Chain ... (policy ..., 0 bytes, 0 packets)

6

Sítě / Pakety tečou neNATované do veřejného rozhraní

« kdy: 28. 03. 2023, 21:17:21 »

Zjistil jsem, že mi z nějakého důvodu na WAN rozhraní odchází  pakety, které neprojdou NATováním. tj odejdou 192.168.0.N -> domena.com . Ty paket jsou bezezměny forwardované z interní sítě (Jde o odpověď na SYN pakety přicházejícího z jiného rozhraní) Když už je packet filter nenasměruje do rozhraní odkud přišlo spojení, tak nechápu proč  jim není změněna src adresa pravidlem MASQUERADE

Mám podezření na pravidlo zvýrazněné tučně:


FORWARD -m conntrack --ctstate INVALID -j DROP
-A FORWARD -d 192.168.1.0/24 -i wan -o eth0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
[FORWARD -s 192.168.1.0/24 -i eth0 -o wan -j ACCEPT




Jsou v pořadí odshora dolů první. Nemělo by mít více parametrů --ctstate  který by omezily ACCEPT?

Přitom jde o (v případě policy forward drop) esenciální pravidlo, aby interní síť vůbec mohla iniciovat spojení do internetu.

Pomohlo by pravidlo  -tnat  POSTROUTING -i eth0 -o wan -s 192.168.1:6 -j REJECT ... Jenže REJECT nejde na -tnat

Ale klíčové je odhalit příčinu, proč paket odejde ne-z-MASQUERADEován?


přestože v iptables mám:
*nat
-A POSTROUTING -s 192.168.0.0/24 -o wan -j MASQUERADE



(ip rule s příbuzného dotazu jsem promazal a je ve výchozím stavu )

ip route:
default via 192.168.0.222 dev wlan0
10.0.0.2 dev tun8 proto kernel scope link src 10.0.0.1
192.168.0.222 dev wlan0 scope link
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100

7

Sítě / Re:Jak řešit routing z vnitřní sítě ,aby šel na TUN a ne na WAN

« kdy: 28. 03. 2023, 19:21:08 »

Hmm, tak mi to zase nenávratně ztratilo odpověď. Co se vyhodnocuje dřív? pravidla iptables nebo ip rule?
Narazil jsem totiž v tom linku na

For each inbound packet kernel checks "reverse path". Kernel swapps inbound packet's source and destination and check via what interface it will be routed in reverse direction by consulting routing table. In this check kernel doesn't respect packet's mark (fwmark).

Napadlo mě že nerespektování Clocka fwmarku může souviset i s vyhodnocováním pravidel v iptables.

mám tam: ... -o wlan0 -j REJECT a vyhoví a přitom   REJECTNUTÍ je předčasné na nějakém předčasném závěru, protože by měl být pomocí pravidla mu změněna routa na tun2

8

Sítě / Re:Jak řešit routing z vnitřní sítě ,aby šel na TUN a ne na WAN

« kdy: 28. 03. 2023, 18:59:31 »

Díky všem za rady, zkusím to projít všechnou, doufám že z toho vykřešu správné rozuzlení. Současný stav (po aplikaci mangle a rule fwmark) je, že příchozí pakety jsou značkované, ale odpověď stále má tendenci jít přes wan, Takže si myslím že problém bude v obsahu tabulky vpn (default via 10.0.0.2 dev tun2) inicované pravidlem  fwmark 1234 lookup vpn -- buď nějak vyhodnocování routy neskončí u tabulky vpn nebo  selže pravidlo all fwmark 1234...

Dokonce si myslím, že bych si vystačil i s pravidlem ip rule add iif tun2  -jMARK 1234 ; ip rule add fwmark 1234 oof tun2 (schématicky, hypoteticky) bez nutnosti iptables

nemůže tam být nějaký problém s prioritou tabulek a prioritou pravidel? Když rule určí podle jaké tabulky routovat, a nevyhoví žádná routa, postupuje se podle dalších tabulek? Žeby to probublalo až k main?

Musím napsat, co vlastně je cílem.  Nějak to z toho nevyplývá. Port forwarding z dostupného VPS do interní sítě. Tedy pro příchozí spojení z internetu na  počítače vevnitř. (což jsou ty záznamy na vps ip route -tnat PRE -dport 80 --to 192.168.0.N:8080,  8022 -> 192.168.0.1:22 ,etc)
Taky jsem nezmínil, že na tom VPSmám logicky ip route add 192.168.0.0 via 192.168.0.1 dev tun2. Ano, je to přes ssh -w. Bez žádných konfiguračních skripů, protože to právě se snažím zprovoznit.

Nemám ani 2 ISP ani nemám VPN na způsob "veškerý traffic přes VPN", ale ta "VPN" jen spojka mezi VPS a sítí za routerem, a to co chci zvenku dostupné řeším na tom VPS těmi DNATy
(To pak nějak mění koncepci použití toho značkování, že se vlaastně značkuje inverzně, nebo aby se to nezacyklilo nebo v případě 2 isp se značkuje "horizontálně")

Na nějaké odkazy na stack overflow jsem koukal. Ale 

Mezitím jsem si přidal pravidla do mangle: (jen odmazáno 0.0.0.0/0 aby se to vešlo na šírku)
PRE:  126  6812 CONNMARK   all  --  tun2   *       ctstate NEW CONNMARK set 0x4d2
FWD:  919 48108 MARK       all  --  *      *       connmark match  0x4d2 MARK set 0x10e1
OUT:  946 95784 MARK       all  --  *      *       connmark match  0x4d2 MARK set 0x10e1

Podíval jsem se to conntrack -L |grep -Pi 'mark=\d\d'


Vantomas: tenhle link jsem neviděl. Vyzkouším --save mark a restore-mark, ale iptables -j MARK vidím poprvé.

Tazatel přesměruje pakety z internetu ("klient.cz" mířící na "vps.cz") skrz tunel do lokální sítě která je "za-natem.cz". Zařízení v lokální síti dostane paket se zdrojovou adresou "klient.cz" a odpoví na něj - posláním odpovědi na "klient.cz". Výsledkem je, že klient.cz dostane paket

To je jen detail a důsledek, ale  dodám, že odpověď ke klientovi nedorazí, ze 5 důvodů:
- může být taky za NATem, pak ji zařízne jeho ISP
- 192.168 neprojde internetem
-odejde poj jinou src IP, tcp stack protistrany  si to nedá dohromady i kdyby neměl nat
-zablokuje ji můj ISP (protože přímo z mého WAN odchází src roszah mé interní sítě)
 ale hlavně ji zablokuje můj firewall ( -I FORWARD -s 192.168.0/24 -o wan -j  REJECT)   (v podstatě kontrola z předchozího řádku; jen na blíže-na mém perimetru)


Výpis:

Kód: [Vybrat]

0:      from all lookup local
32764:  from all fwmark 0x10e1 lookup vpn
32765:  from 10.2.0.0/24 lookup vpn
32766:  from all lookup main
32767:  from all lookup default
#ip r s t vpn (ať žijou zkratky)
default via 10.2.88.2 dev tun8
192.168.1.0/24 via 192.168.1.208 dev eth0



9

Sítě / Jak řešit routing z vnitřní sítě ,aby šel na TUN a ne na WAN

« kdy: 28. 03. 2023, 14:37:26 »

Zdravec, jak by se  na routeru vnitřní sítě správně řešil  routing  , aby  odchozí pakety nechodily na hlavní rozhraní do internetu ale, přes TUN?  Příchozí spojení pěkně dorazí do zařízení, ale odchozí má tendenci odcházet  špatným rozhraním.
Stručně: je to dím, že nemám v iptables žádné pravidlo FW/CONN/MARK nebo prohibit nebo supressprefix_length?
Obousměrně funkční spojení je funkční pouze  na ip adresu routeru (10.0.0.1) na rozhraní tun. Není funkční na ip rozsah vnitření sítě(ani routeru 192.168.0.222)
Potřebuji zachovat IP adresy remote hostů(takže nejde použít kombo  PREROUTING DNAT 80->192.168.1.9:8080 +  POSTROUTING SNAT  --to-source 10.0.0.2, takže router na vnitřní síti uvidí traffic z vpn rozsahu)
(Rozvedu, toto byl jen stručný úvod)

Na domácím routeru je TUN obsluhované ssh -w 1:2 Vzdálený bod je VPS (IP 1.2.3.4), kde jsou forwardované porty ( iptables -A PREROUTING -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.1.9:8080
)

/etc/iproute2/rt_tables : mám "10 vpn"
ip rule: 32765:  from 10.0.0.0/24 lookup vpn

ip route show table vpn
default via 10.0.0.2 dev tun8 (ip samotná je 10.0.0.1)
192.168.1.0/24 via 192.168.1.222 dev eth0

ip link:eth0  =lokální síť, tun =tunel, wan= rozhraní do internetu

Pozorování: Pakety  dovnitř krásně dojdou  (5.4.3.2 je nějaká remote host)

5.4.3.2:54321 -> 1.2.3.4:80 (in: vps-eth0)
5.4.3.2:54321 -> 192.168.1.9:8080 (vps forward out: tun-x, pravidlo -j DNAT)
----
tunel
----
5.4.3.2:54321 -> 192.168.1.9:8080 (router forward in: tun-y)
paket do zařízení v lokální síti
zařízení odpoví  192.168.1.9:8080 -> 5.4.3.2:54321
192.168.1.9:8080 -> 5.4.3.2:54321 (router forward in eth0)
192.168.1.9:8080 -> 5.4.3.2:54321 (router out : wan) - neaplikuje se ani  ip rule from 10.0.0.0/24

Jak routeru říct že tento paket má jít do tun-x a ne do wan  Logicky tam musí být nějaký conntrack, a poznamenat  si že flow z port 54321 přišel z  tun a ne z WAN. Samotné zařízení v síti pak nemá ponětí, že pakety pochazí z WAN

Nebo druhé řešení nějaký prapodivný nat že bych (na VPS) místo -jDNAT 192.168.1.6 dával  -j DNAT 10.99.0.6 a v routeru by se to pak muselo podruhé z natovat pravidlem  10.99.0.Q na  192.168.1.Q?


Co vychází lepe, ten extra-nat nebo nějaký MARK?



(Chci to právě zprovznit na holém tun, tedy ne wireguard).   -jMARK jsem nikdy nepoužíval...
četl jsem toto Policy-based routing v Linuxu: směrování provozu pod kontrolou



---ta funkce " Mezitím vypršelo sezení. Odešlete příspěvek znovu. Tento formulář jste již odeslali je  kvzteku. Už se to stalo zase stalo."  Reload zobrazí samou stránku bez dialogu prohlížeče odeslání POST Dat jelikož je přesměrován na  GET. Tlačítko zpět ho sice zobrazí ale zobrazí se pak čištá formulář

10

Server / Re:GSM tracker - noSQL databáze pro příjem dat, domácí podmínky

« kdy: 28. 03. 2023, 14:28:31 »

Hmm, takže hlavní je vyřešit  přijem dat nebo dostupnost .

Máte někdo zkušenost s https://gun.eco/ ?

----
fun fact: dal jsem reload, viděl jsem stále že jsem přihlášený, ale po 2sekundách kliknutí Odpověďět už jsem přihlášený nebyl

11

Server / Re:ssh -R -B -b výběr odchozí IP adresy pro forwarding portu

« kdy: 11. 03. 2023, 18:50:25 »

No ták vícenásobné poúžití -b bere jen poslední 
A -b se použije pro spojení na server(s IP z LAN se ani nespojí) tudíž je tento parametr zbytecné psát - ip adresu od ssh k sshd neřeším a beztak na wan mám jen jednu

Každopádně aspoň díky za ten socatový rovnák

12

Server / ssh -R -B -b výběr odchozí IP adresy pro forwarding portu

« kdy: 10. 03. 2023, 17:03:04 »

Řeším takový záludnější problém se ssh -R který jsem nenašel v man-u ( / -B(ind interface) -b(ind adress),
a sice jak určit ssh klientovy jakou IP použít pro připojení se na cíl tunelu (ne z jaké IP se připojit na sshd démona server, což podle mě dělá -b/-B)

Používám  úspěšně ssh -R  "*:443:192.168.1.20:443", ale chci změnit adresu , z jaké se ssh klient připojuje na   ten
 výstupní endpoint tunelu . 192.168.1.20:443.
pc s ssh klientem má více rozhraní (prvním se připojuje na internet a druhé je LAN) a více ip adres (kromě obvious každé adresy na každém rozhraní  myslím víc ip adres na LAN a tam právě chci provést selekci.).



Přepdpokládám, že zdvojené použití parametru -b nebude fungovat (jako třeba u ffmpeg, kde opakované volby patří ke každému inpu file):

(za předpokladu, že by ssh takto hypoteticky posuzovalo argumenty -b a že ip ssh klienta je 192.168.1.3 na lan a 41.23.22.11 na WAN):
ssh -b 192.168.1.88 -R  "*:443:192.168.1.20:443 -b 41.23.22.11 sshd.com   
(kde 41.23..22.11 je vlastně navíc, jelikož by se mělo vázat na rozhraní do netu a to já měnit nechci - to je stejně jedno)
ale chci změnit  ip adresu ze kterého ssh klient se připojuje na konec tunelu, místo z 192.168.1.3 na 192.168.1.88)

13

Sítě / Re:Zkušenosti s více IP na serveru

« kdy: 17. 02. 2023, 19:30:45 »

Pokud to spadne až na výchozí bránu, vybírá se brána podle pořadí, v jakém jsou zadané – buď první nebo poslední (nejlepší je si to vyzkoušet).

On může mít routovací záznam(cíl) mít víc bran než jednu? RTNETLINK answers: File exists (< ip route add ... )

14

/dev/null / Re:ChatGPT a tel. číslo

« kdy: 17. 02. 2023, 19:27:28 »

cowboys radši mlčí a hlídají si svá stáda, a když přicestuje nový sheriff který by chtěl přivést zákon, tak se všichni radši tváří že jako nic.

Kdo jsou cowboys a na čí straně?

15

Server / Existuje rekurzivní DNS přes šifrovaný kanál?

« kdy: 26. 01. 2023, 11:58:55 »

Je možné  provádět rekurzivní DNS resolvování přes šifrované DNS (over HTTP, TLS)? 
Pokud ano, je v tom nějaký zádrhel a dává to smysl? Představoval jsem si něco jako, že u root serverů změním port na 853 nebo 443...

Pokud ne, kde je problém, v jakém článku řetězu to nepůjde?