Byl vydán Mozilla Firefox 143.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Nově se Firefox při ukončování anonymního režimu zeptá, zda chcete smazat stažené soubory. Dialog pro povolení přístupu ke kameře zobrazuje náhled. Obzvláště užitečné při přepínání mezi více kamerami. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 143 bude brzy k dispozici také na Flathubu a Snapcraftu.
Byla vydána betaverze Fedora Linuxu 43 (ChangeSet), tj. poslední zastávka před vydáním finální verze, která je naplánována na úterý 21. října.
Multiplatformní emulátor terminálu Ghostty byl vydán ve verzi 1.2 (𝕏, Mastodon). Přehled novinek, vylepšení a nových efektů v poznámkách k vydání.
Byla vydána nová verze 4.5 (𝕏, Bluesky, Mastodon) multiplatformního open source herního enginu Godot (Wikipedie, GitHub). Přehled novinek i s náhledy v příspěvku na blogu.
Byla vydána verze 3.0 (Mastodon) nástroje pro záznam a sdílení terminálových sezení asciinema (GitHub). S novou verzí formátu záznamu asciicast v3, podporou live streamingu a především kompletním přepisem z Pythonu do Rustu.
Canonical oznámil, že bude podporovat a distribuovat toolkit NVIDIA CUDA (Wikipedie) v Ubuntu.
Tržní hodnota americké společnosti Alphabet, která je majitelem internetového vyhledávače Google, dnes poprvé překonala hranici tří bilionů dolarů (62,1 bilionu Kč). Alphabet se připojil k malé skupině společností, které tuto hranici pokořily. Jsou mezi nimi zatím americké firmy Nvidia, Microsoft a Apple.
Spojené státy a Čína dosáhly dohody ohledně pokračování populární čínské platformy pro sdílení krátkých videí TikTok v USA. V příspěvku na síti Truth Social to dnes naznačil americký prezident Donald Trump. Dosažení rámcové dohody o TikToku vzápětí oznámil americký ministr financí Scott Bessent, který v Madridu jedná s čínskými představiteli o vzájemných obchodních vztazích mezi USA a Čínou. Bessentova slova později potvrdila také čínská strana.
MKVToolNix, tj. sada nástrojů pro práci s formátem (medialnym kontajnerom) Matroska, byl vydán ve verzi 95.0. Podpora přehrávání formátu Matroska míří do Firefoxu [Bug 1422891, Technický popis]. Přehrávání lze již testovat ve Firefoxu Nightly.
Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 211. sraz, který proběhne v pátek 19. září od 18:00 ve Studentském klubu U Kachničky na Fakultě informačních technologií Vysokého učení technického na adrese Božetěchova 2/1. Na srazu proběhne přednáška Jiřího Eischmanna o nové verzi prostředí GNOME 49. Nemáte-li možnost se zúčastnit osobně, přednáškový blok bude opět streamován živě na server VHSky.cz a následně i zpřístupněn záznam.
iptables -t nat -A PREROUTING -p tcp -i eth0 -d s1 --dport 80 --sport 80 -j DNAT --to m1:80
iptables -t nat -A PREROUTING -d s1 -p tcp --dport 80 -j DNAT --to m1:80
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to m1:80
Na cílovém stroji je port 80 povolen, takže chyba je někde v pravidlech.
Jen ještě dodám, že s1 i m1 jsou externí ip adresy.
Napadá Vás prosím něco?
Předem dík.
Řešení dotazu:
s1
není router pro m1
, nebo pokud chcete, aby přesměrování fungovalo i v rámci případné společné sítě s1
a m1
, je potřeba přidat na s1
do POSTROUTING
ještě pravidlo pro SNAT
, které zdrojovou adresu nastaví na adresu stroje s1
. m1
se tak nebude pokoušet odpovědět přímo klientovi, ale pošle paket zpět na s1
, který paket s odpovědí „odNATuje“ a pošle klientovi.
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to m1:80
iptables -t nat -A POSTROUTING -s m1 -p tcp --dport 80 -j SNAT --to s1:80
ale stejně stálý výsledek..
-s m1
– ten SNAT se má aplikovat na všechny pakety, které přišly „zvenku“ a jsou přesměrovány na m1
. Takže spíš
iptables -t nat -A POSTROUTING -d m1 -p tcp --dport 80 -j SNAT --to s1:80Pravidla NATu se píšou pro pakety, které spojení navazují – ostatní pakety ve spojení už pak jádro upraví automaticky po vzoru toho prvního podle toho, kterým směrem paket prochází.
"-j SNAT --to s1:80" je blbost. Urcite nechcete nahrazovat port. Spravne je "-j SNAT --to-source s1"Zřejmě je
--to
nedokumentovaná alternativa k --to-source
– jinak by iptables
při volání s neznámým parametrem ohlásily chybu, což by nám snad tazatel prozradil.
Uvést vedle IP adresy i port není na škodu, i když se port nemění – webový provoz se často přesměrovává na neprivilegovaný port 8080, s explicitním uvedením portu je to pak konzistentní v různých konfiguracích.
2) Zkontrolujte si, jestli mate na serveru zapnuty ip_forward. Prikaz "cat /proc/sys/net/ipv4/ip_forward" musi vratit "1"Tohle nastavení má vliv i na NAT? Vždycky jsem měl za to, že se to týká jen routování a NAT tohle nastavení obchází.
Bacha, tady jsme v postroutingu a nahrazujeme zdroj.No jo, jasně, nějak jsem to přehlédl.
tcpdump
u nastaven tak, aby zachytil pakety v obou směrech? Např. u HTTP spojení mají pakety s odpovědí (ze serevru ke klientovi) zdrojový port 80 (ne cílový).
tcpdump port 80 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 21:50:25.279631 IP mujPC.23450 > s1.http: Flags [S], seq 2794593060, win 8192, options [mss 1452,nop,nop,sackOK], length 0 21:50:25.279643 IP s1.23450 > m1.http: Flags [S], seq 2794593060, win 8192, options [mss 1452,nop,nop,sackOK], length 0 21:50:25.280381 IP m1.http > s1.23450: Flags [S.], seq 1803668736, ack 2794593061, win 4380, options [mss 1460,nop,nop,sackOK], length 0 21:50:25.280395 IP s1.http > mujPC.23450: Flags [S.], seq 1803668736, ack 2794593061, win 4380, options [mss 1460,nop,nop,sackOK], length 0 21:50:25.296125 IP mujPC.23450 > s1.http: Flags [.], ack 1, win 64665, length 0 21:50:25.296131 IP s1.23450 > m1.http: Flags [.], ack 1, win 64665, length 0 21:50:25.306620 IP mujPC.23450 > s1.http: Flags [P.], seq 1:370, ack 1, win 64665, length 369 21:50:25.306624 IP s1.23450 > m1.http: Flags [P.], seq 1:370, ack 1, win 64665, length 369 21:50:25.306870 IP m1.http > s1.23450: Flags [.], ack 370, win 5360, length 0 21:50:25.306875 IP s1.http > mujPC.23450: Flags [.], ack 370, win 5360, length 0 21:50:25.308119 IP m1.http > s1.23450: Flags [P.], seq 1:279, ack 370, win 5360, length 278 21:50:25.308123 IP s1.http > mujPC.23450: Flags [P.], seq 1:279, ack 370, win 5360, length 278 21:50:25.522509 IP mujPC.23450 > s1.http: Flags [.], ack 279, win 64387, length 0 21:50:25.522514 IP s1.23450 > m1.http: Flags [.], ack 279, win 64387, length 0 21:50:40.324203 IP m1.http > s1.23450: Flags [F.], seq 279, ack 370, win 5360, length 0 21:50:40.324214 IP s1.http > mujPC.23450: Flags [F.], seq 279, ack 370, win 5360, length 0 21:50:40.337945 IP mujPC.23450 > s1.http: Flags [.], ack 280, win 64387, length 0 21:50:40.337950 IP s1.23450 > m1.http: Flags [.], ack 280, win 64387, length 0 21:50:47.867839 IP mujPC.23450 > s1.http: Flags [F.], seq 370, ack 280, win 64387, length 0 21:50:47.867845 IP s1.23450 > m1.http: Flags [F.], seq 370, ack 280, win 64387, length 0 21:50:47.868090 IP m1.http > s1.23450: Flags [.], ack 371, win 5360, length 0 21:50:47.868101 IP s1.http > mujPC.23450: Flags [.], ack 371, win 5360, length 0 21:51:55.128450 IP whl0051.whservidor.com.http > s1.43677: Flags [S.], seq 1100246647, ack 674711610, win 16384, options [mss 1460], length 0 21:51:55.128464 IP s1.43677 > whl0051.whservidor.com.http: Flags [R], seq 674711610, win 0, length 0 21:55:57.216162 IP whl0051.whservidor.com.http > s1.53157: Flags [S.], seq 1661978047, ack 674711610, win 16384, options [mss 1460], length 0 21:55:57.216191 IP s1.53157 > whl0051.whservidor.com.http: Flags [R], seq 674711610, win 0, length 0Jinak mockrát děkuji za ochotu, asi to vypadá zvláštně... Rozhodně to není tak, že bych o to neměl zájem, jak tu psal kolega - spíše mě tlačí čas a s mými zkušenostmi mi to nešlo...
tcpdump
sledovat, kam až pakety dorazí a kde se ztratí.
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to m1:80 iptables -t nat -A POSTROUTING -d m1 -p tcp --dport 80 -j SNAT --to-source s1A ano s1 má skutečně jen rozhraní eth0.
s1:eth0
, udělá se DNAT a SNAT, paket přes s1:eth0
odejde, a na m1
už nepřijde? To by vypadalo spíš na problém s routováním nebo mezilehlým firewallem.
Jestli to pomůže, tak iptables-save
# Generated by iptables-save v1.4.12 on Wed Nov 30 17:42:20 2011 *filter :INPUT ACCEPT [367:29521] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [316:48602] COMMIT # Completed on Wed Nov 30 17:42:20 2011 # Generated by iptables-save v1.4.12 on Wed Nov 30 17:42:20 2011 *mangle :PREROUTING ACCEPT [385:30385] :INPUT ACCEPT [367:29521] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [320:49114] :POSTROUTING ACCEPT [320:49114] COMMIT # Completed on Wed Nov 30 17:42:20 2011 # Generated by iptables-save v1.4.12 on Wed Nov 30 17:42:20 2011 *nat :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] -A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j DNAT --to-destination m1:80 -A OUTPUT -p tcp -m tcp --dport 80 -j DNAT --to-destination m1:80 -A POSTROUTING -o eth0 -j MASQUERADE COMMIT # Completed on Wed Nov 30 17:42:20 2011
iptables -t nat -A POSTROUTING -d m1 -p tcp --dport 80 -j SNAT --to-source s1(vsimnete si, ze na konci radky za s1 neni port) Opravdu provoz prichazi i odchazi stejnym rozhranim? Jinak vzhledem k faktu, ze nemate problem sem dat neco, co evidentne prozrazuje vas nezajem se tomu aspon trochu venovat, bude lepsi si najit nekoho znaleho.
echo "1" > /proc/sys/net/ipv4/ip_forward /sbin/iptables -P INPUT DROP /sbin/iptables -P FORWARD DROP /sbin/iptables -P OUTPUT ACCEPT /sbin/iptables -t nat -A POSTROUTING -o <externi rozhrani> -j MASQUERADE /sbin/iptables -A FORWARD -i <interni rozhrani> -o <externi rozhrani> -j ACCEPT /sbin/iptables -A FORWARD -i <externi rozhrani> -o <interni rozhrani> -m state --state ESTABLISHED,RELATED -j ACCEPT /sbin/iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT /sbin/iptables -A INPUT -i lo -j ACCEPT /sbin/iptables -t nat -A PREROUTING -p tcp -i <externi rozhrani> -d <externi IP> --dport 80 -j DNAT --to <interni ip>:80 /sbin/iptables -A FORWARD -p tcp -i <externi rozhrani> -d <interni IP> --dport 80 -j ACCEPT
ip route
.
Pro ten váš dotaz by bylo potřeba vidět výpis aktuálních pravidel firrewallu a NATu, bez toho se těžko odhaduje, která pravidla dostanou přednost. Taky je lepší na to založit nový dotaz, s tímto to moc nesouvisí – a stejně tam výpis současných pravidel uvedete, to je dostatečný kontext.
eth0
je vnější rozhraní routeru) a problém bude v něčem jiném. Zjistěte, co přesně vám nefunguje – překlad DNS, pakety přes router neprojdou ven, nevrátí se odpověď? Spusťte si tcpdump
na vnitřním i vnějším rozhraní a sledujte, jaké pakety procházejí a které se kde ztratí.
Tiskni
Sdílej: