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 - Filip Jirsák

Stran: 1 ... 44 45 [46] 47 48 ... 375
676
Sítě / Re:Přesměrování portu 8080 na port 80 v nftables
« kdy: 25. 02. 2022, 08:55:32 »
Už se motáme v kruhu, to je blbě, to je blbě, to je blbě, klidně si nechám poradit, jak to mám udělat.
To už jsem vám napsal. Pokud nemá být port 80 z venku dostupný, musí aplikace naslouchat jen na localhostu a paket se musí přesměrovávat na localhost. Nebo tu komunikaci z venku můžete zakázat i na firewallu, ale primární by mělo být správné nastavení aplikace, firewall je až pojistka.

A nebo ještě daleko jednodušší řešení – prostě té aplikaci nastavte, ať rovnou naslouchá na portu 8080. Přesměrování 80→8080 se dělá proto, aby aplikace nemusela mít práva roota, když někdo nechce řešit capabilities. Pro přesměrování 8080→80 není žádný důvod, na portu 8080 může aplikace naslouchat kdykoli.

pokud mi nevěříte, že je v tu chvíli 80 filtrovaná (není otevřená), tak s tím nic neudělám.
Ta pravidla, která jste ukazoval, nemohou zajistit, aby byl port 80 filtrovaný. Může to filtrovat třeba nějaký dřívější firewall – nenapsal jste, jak to zkoušíte. Já jsem vás jenom upozorňoval na to, že Netfilter v Linuxu funguje jinak, než si myslíte. Pokud si dál trváte na té konfiguraci, která nedává smysl a dělá něco  jiného, než si myslíte, je to váš problém, ne můj.

To křížové NATování portu v iptables mi taky funguje asi 5 let, i když tvrdíte, že nemůže.
Já jsem netvrdil, že to fungovat nemůže. Divil jsem se, že to fungovalo, a psal jsem, že sám bych tohle asi nikdy nezkoušel, protože bych si myslel, že to druhé pravidlo přepíše port zase zpátky. A upřímně, po vašich dalších komentářích, kdy se ukázalo, že vůbec nevíte, jak Netfilter funguje, si vůbec nejsem jistý, že vám tohle opravdu funguje. Možná to ve výsledku dělá, co chcete, ale vůbec na tom nemusí mít zásluhu tahle pravidla.

677
Sítě / Re:Přesměrování portu 8080 na port 80 v nftables
« kdy: 24. 02. 2022, 21:55:15 »
NAT dám nahoru a potom budu řešit porty.
Ještě k tomuhle – je jedno, jestli v konfiguračním souboru bude NAT nahoře nebo dole, pořadí sekcí nemá na nic vliv. Třeba tady je schéma toho, jak packet putuje síťovým stackem linuxu: Nftables - Packet flow and Netfilter hooks in detail. Pořadí pravidel má význam jenom v jednom konkrétním řetězci, kde se testuje jedno pravidlo za druhým. Putování paketu mezi jednotlivými řetězci je ale pevně dané, vizte ten obrázek.

678
Sítě / Re:Přesměrování portu 8080 na port 80 v nftables
« kdy: 24. 02. 2022, 21:38:07 »
Klidně bych to udělal jinak, ale takhle mi to funguje. Když 80 prvně nepovolím, tak 8080 otevřený není, ale když 80 prvně povolím, 8080 přesměruji a poté 80 zakáži, tak mám 8080 otevřený a 80 filtrovaný.
O finální podobě jsem už psal, NAT dám nahoru a potom budu řešit porty.
Ne, port 80 nezakážete a filtrovaný není.

679
Sítě / Re:Přesměrování portu 8080 na port 80 v nftables
« kdy: 24. 02. 2022, 20:54:59 »
port 80 zakázaný
Nemůžete mít port zároveň povolený i zakázaný. Linuxový firewall funguje na základě pravidel – ta se postupně procházejí, vyhodnotí se, zda paket pravidlu vyhovuje, a pokud ano, uplatní se akce, která je u pravidla nastavená. Pokud je akce ACCEPT, REJECT nebo DROP, je to už rozhodnutí, co se má s paketem udělat, a další pravidla se už neprochází. Takže vy řádkem
Kód: [Vybrat]
tcp dport 80 accept
říkáte, že příchozí pakety protokolu TCP/IP s cílovým portem 80 se mají pustit do počítače. Tím zpracování paketu firewallem končí, protože už je rozhodnuto, co s paketem. Na pravidlo
Kód: [Vybrat]
tcp dport 80 drop
tudíž nikdy nemůže dojít.

680
Sítě / Re:Přesměrování portu 8080 na port 80 v nftables
« kdy: 24. 02. 2022, 19:45:56 »
Mě by spíše pomohlo a nakoplo, jak změnit konfiguraci z prvního příspěvku, aby byl port 8080 otevřený.
Já bych tam zkusil odkomentovat ten řádek, který povoluje komunikaci na portu 80:

Kód: [Vybrat]
#!/sbin/nft -f

### vymazani
flush ruleset

table ip filter {
        chain input {
        type filter hook input priority 0; policy drop;

### interfacy
        iifname eno1 ct state invalid counter drop
        iifname eno1 ct state established,related counter accept

        iifname enp3s0 accept
        iifname wlp2s0 accept
        iifname docker0 accept

### loopback
        iifname lo accept

### lokalni adresy
        ip saddr 172.16.0.0/12 accept

### icmp
        ip protocol icmp accept

### porty
        tcp dport 22 accept
        tcp dport 8080 accept
################# následující řádek jsem odkomentoval ##########################
        tcp dport 80 accept
        #tcp dport 443 accept
    }

        chain forward {
        type filter hook forward priority 0; policy accept;
        #tcp dport 8080 accept
    }

        chain output {
        type filter hook output priority 0; policy accept;
        #tcp dport 8080 accept
    }
}

table ip nat {
        chain postrouting {
        type nat hook postrouting priority 100;
        ip saddr 172.16.0.0/12 oifname eno1 masquerade
    }
        chain prerouting {
        type nat hook prerouting priority 100; policy accept;
        tcp dport 8080 redirect to :80
    }
}

Samozřejmě pak na tom portu 80 na příslušné IP adrese musí poslouchat nějaká aplikace.

681
Sítě / Re:Přesměrování portu 8080 na port 80 v nftables
« kdy: 24. 02. 2022, 17:37:33 »
Kód: [Vybrat]
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
DNAT       tcp  --  0.0.0.0/0            192.168.1.22          tcp dpt:8080 to:192.168.1.22:80
DNAT       tcp  --  0.0.0.0/0            192.168.1.22          tcp dpt:80 to:192.168.1.22:8080
Tohle vám fungovalo? Bál bych se, že se v případě uplatnění prvního pravidla uplatní i to druhé a vrátí to zase zpátky.

ve firewallu byl povolený port 8080, který byl otevřený, ale to jsem v nftables taky zkusil
Povolený musíte mít ten port, na který se DNATuje. Paketu se nejprve v PREROUTING změní port a teprve následně se uplatňují firewallová pravidla v INPUT nebo FORWARD. Takže pravidla musí odpovídat už tomu cílovému portu. (U SNATu je to opačně, ten se aplikuje až v POSTROUTING, takže firewall vidí ještě neupravené pakety.)

Každopádně když máte problém s NATem, je rozumné firewall nejprve úplně vypnout, nakonfigurovat správně NAT, a teprve pak začít konfigurovat firewall. Když řešíte obojí najednou, nevíte, kde dřív hledat chyby – jestli v NATu, nebo ve firewallu, nebo dokonce v aplikaci.

682
Sítě / Re:Přesměrování portu 8080 na port 80 v nftables
« kdy: 24. 02. 2022, 16:12:24 »
Když povolím port 80, tak jsou otevřené oba porty 80 i 8080.
To je v pořádku. Přesměrování portu neřeší žádné „otevření“ či zavření“ portu. Přesměrování portu dělá jenom to, že v příchozím paketu přepíše číslo portu a v odchozím paketu to udělá opačně.

Podle mne ten váš zápis v nftables dělá to, že u paketů, které mají cílový port nastaven na 8080, změní cílový port na 80, IP adresu zachová. Na firewallu pak ale nemáte port 80 povolený, takže se paket zahodí.

Pokud nechcete, aby port 80 byl dostupný „z venku“, musíte zařídit, aby aplikace naslouchala jen na localhostu, v NATu paketům neměnit jen port, ale také je přesměrovat na localhost. A když komunikaci na firewallu zakazujete, musíte pak ten lokální port 80 povolit.

Princip je stejný, jako u iptables – tam byl také NAT nezávislý na firewallu a to, že jste NATem někam paket přesměroval ještě neznamenalo, že projde i firewallem.

683
Server / Re:Záloha desítek GB u kamaráda
« kdy: 23. 02. 2022, 09:49:44 »
Já asi nedokážu napsat „skript pro obnovy“, protože ty požadavky jsou typu „před pár dny jsem omylem smazal adresář ve svém webu a potřebuju ho obnovit“ - a pak se musím podívat do /mnt/backup/snapshot/různá_čísla/home/uživatel/public_html/XYZ a ručně zjistit který den tam ty soubory ještě jsou, a typicky mu je radši vykopíruju bokem, ne zpátky tam kde tehdy byly. To readonly je ale dobrý nápad, koukám že to jde na btrfs snapshotům nějak nastavit, tak bych to mohl udělat.
Já jsem myslel kompletní obnovu při havárii disku. Tahle obnova jednoho souboru je něco jiného – ale to pak ručně hledáte konkrétní soubor a nejspíš ho ručně zkopírujete, takže asi nehrozí, že kvůli špatnému parametru přepíšete celou zálohu. Nicméně při ručním kopírování se o to víc hodí readonly režim. Když máte v mc na jedné straně zálohu, na druhé straně aktuální stav, je adresářová struktura velmi podobná – kdo ještě nikdy v takové situaci nepřepsal správnou verzi souboru tou špatnou, ať jako první hodí kamenem…

684
Server / Re:Záloha desítek GB u kamaráda
« kdy: 23. 02. 2022, 08:56:06 »
Obnova se provádí prohozením source a destination parametru rsyncu
Celý popis vypadal docela dobře – a pak najednou tohle, nejlepší způsob, jak o zálohu přijít. Stačí zapomenout prohodit parametry, nebo je prohodit dvakrát. Přimlouval bych se za to, aby skript pro obnovy a celý postup obnovy byl napsaný už v okamžiku startu zálohování – aby nikdo nemusel ve stresu při obnově řešit nějaké prohazování parametrů. Dále je dobré, když se po dokončení jednoho kola zálohy ta záloha uzamkne pro zápis.

685
Server / Re:Zaloha desitek GB u kamarada
« kdy: 22. 02. 2022, 20:25:03 »
Takto vytvorene zalohy se zasifrovaly a zazipovaly mym sw.
Je nesmysl komprimovat zašifrovaná data. Pokud to chcete komprimovat, pak nejprve komprimujte a teprve pak šifrujte. Výstup šifrování by se měl co nejvíce blížit náhodnému šumu – a náhodný šum nejde komprimovat.
Hezky !
A jpeg fotky taky ne.
Těch formátů, které jsou interně komprimované (typicky stejným algoritmem, jako používá ZIP), je daleko víc – javovské JAR, všechny moderní koncelářské formáty (jak Microsoftu tak OpenOffice.org), obvykle PDF, PNG… Řešit u každého souboru, zda se má nebo nemá komprimovat, by asi bylo zbytečně komplikované. Ale když se komprimuje a šifruje a je to pouze otázka správného pořadí kroků, je nesmysl dělat to systematicky špatně.

686
Server / Re:Zaloha desitek GB u kamarada
« kdy: 22. 02. 2022, 10:55:25 »
Takto vytvorene zalohy se zasifrovaly a zazipovaly mym sw.
Je nesmysl komprimovat zašifrovaná data. Pokud to chcete komprimovat, pak nejprve komprimujte a teprve pak šifrujte. Výstup šifrování by se měl co nejvíce blížit náhodnému šumu – a náhodný šum nejde komprimovat.

687
Software / Re:Rsync celého disku
« kdy: 21. 02. 2022, 12:48:09 »
Ještě mě napadá elegantní synchronizace, kdyby tam nebylo NTFS, ale Btrfs: přes btrfs send/receive. Ideálně v kombinaci se snapshotem: Uděláš read-only snapshot (aby se syncoval jakž takž konzistentní stav), na zdrojovém disku rsync send, na cílovém rsync receive, přenesou se jen změny od posledního syncu, smažeš snapshot.

Ale jak říkají už předešlí, je to blbost to dělat, když přesně na to tu máme RAID1.
Ano, kdyby se ta data měla synchronizovat „jednou za čas“ (ne přes RAID 1), je podle mne btrfs a send/recive ideální řešení – pokud v tom NASu může btrfs použít.

Jinak pokud budou oba disky v NASu neustále, je podle mne RAID1 nejlepší řešení. Postará se o to přímo NAS, nehrozí, že nějaké vaše skripty selžou. Stejně byste tou občasnou synchronizací nic neušetřil – stejně NAS nastartuje oba disky.

Pokud je ten záložní disk externí a chcete ho připojovat jenom občas (abyste minimalizoval riziko, že třeba nějaký elektrický výboj odpálí oba disky najednou), pak dává smysl použít tu synchronizaci. A pak bych volil to btrfs send/receive, pokud je to možné – tím se přenesou opravdu jenom ty bloky, které byly změněné. Takže se třeba nebudou kopírovat ani přejmenované soubory (jen se změní jejich název) nebo části souborů, které se nezměnily.

Obecně rsync je vhodný hlavně na přenos dat po síti (když je síť výrazně pomalejší, než disky). Při lokálním přenosu toho rsync nedokáže ušetřit zdaleka tolik, protože stejně musí zjistit, co se vlastně změnilo, a to nezjistí bez přečtení alespoň metadat.

688
Server / Re:Naplánované odeslání e-mailu v SMTP
« kdy: 21. 02. 2022, 11:52:28 »
No tak přijímací strana, natož MDA už tohle vůbec nemá v kompentenci
To také nikdo nepsal.

MUA přeci z definice nemůže být na serveru
Samozřejmě, že může – třeba všechny webmaily.

Musí tam být nějaké rozhraní, by to bylo na MUA nezávislé. (Nebo tak bych to aspoň chtěl)
Takové rozhraní obecně neexistuje. Jakmile MUA předá e-mail MSA nebo MTA, je ten e-mail připraven k odeslání a může být odeslán kdykoli, kdy MTA uzná za vhodné.

Já právě hledám funkci na serveru, že"odešlu" mail, ukončím TheBat, zaklapnu víko, a  teď as se stará server
Na to potřebujete na serveru aplikaci, která ve správný okamžik předá e-mail MSA nebo MTA. Může to být přímo MUA, případně něco, s čím bude váš MUA umět komunikovat a předat mu tu informaci, kdy se má e-mail odeslat. Může to být třeba IMAP server – IMAP podporuje i odeslání e-mailu a pomocí rozšíření by se asi dala připojit informace o plánovaném čase odeslání.

689
Server / Re:Naplánované odeslání e-mailu v SMTP
« kdy: 21. 02. 2022, 09:30:32 »
Řeší to MUA. MUA může mít svou část i na serveru – mohou tam být uložené schránky a složky, typicky pak nějaká složka budou „e-maily k odeslání“, kde může MUA implementovat tu funkcionalitu odložení odeslání.

Obecně to nejde řešit pomocí fronty MTA, protože to je interní věc MTA a MTA do ní nevidí. A běžnou funkcionalitou toho odloženého odeslání e-mailu je to, že e-maily naplánované k odeslání vidíte a můžete odeslání zrušit.

Což samozřejmě neznamená, že to proprietární řešení nemohou mít jinak – zejména když to je třeba jeden software a hranice mezi MUA, MSA, MTA a MDA tam nejsou pevně dané.

690
Server / Re:Aplikace patche přes FTP
« kdy: 19. 02. 2022, 16:18:38 »
Ne. Musíte stáhnout soubor, aplikovat patch lokálně a pak upravený soubor zase nahrát.

Stran: 1 ... 44 45 [46] 47 48 ... 375