Blíží se prázdniny a než se rozutečete k moři, je na čase se opět sejít na Virtuální Bastlírně - pravidelném setkání elektroniků, ajťáků, bastlířů a obecně nadšenců do techniky. Co si pro vás strahovští bastlíři připravili tentokrát? Určitě proberou blížící se Linux Days i další události. U softwaru se chvíli zdrží a poví si kupříkladu o tom, jak se zbavit Bambu Cloudu, ale nepřijít o možnost ovládat tiskárnu na dálku. Řeč dojde i na AI,
… více »Vývojáři postmarketOS vydali verzi 26.06 tohoto operačního systému pro chytré telefony vycházejícího z optimalizovaného a nakonfigurovaného Alpine Linuxu s vlastními balíčky. Přehled novinek v příspěvku na blogu. Na výběr jsou 4 uživatelská rozhraní: GNOME, KDE Plasma Mobile, Phosh a Sxmo.
Byla vydána nová verze 2.55.0 distribuovaného systému správy verzí Git. Přispělo 100 vývojářů, z toho 33 nových. Přehled novinek v příspěvku na blogu GitHubu a v poznámkách k vydání.
Craig Loewen na blogu Microsoftu oznámil veřejnou preview verzi WSL kontejnerů, tj. linuxových kontejnerů ve Windows Subsystem for Linux (WSL). Spouští se příkazem wslc.exe.
Byla vydána (𝕏, Bluesky) nová verze 2026.2 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem 9 nových nástrojů v oficiálním oznámení na blogu.
Grafická aplikace Krokiet/Czkawka pro vyhledávání a odstraňovaní nepotřebných souborů (duplicitní soubory, prázdné složky, podobné obrázky, podobná videa, poškozené soubory a další) byla vydána ve verzi 12.0.0. Podrobný přehled novinek v příspěvku na Medium. Jedná se o poslední verzi frontendu Czkawka GTK nad Czkawka Core. Uživatelům se doporučuje migrovat na frontend Krokiet postavený nad frameworkem Slint. Představena byla aplikace Cedinia pro Android využívající Czkawka Core. Dostupná je jako APK pro ruční instalaci.
Po téměř třech letech od vydání verze 9 byla vydána nová verze 10 linuxové distribuce Mageia (Wikipedie). Přehled novinek v poznámkách k vydání.
Nourish (GitHub) je nový správce oken pro Linux. Tradiční plochy nahrazuje nekonečným plátnem a posouváním a přibližováním. Využívá vlastní kompozitor pro Wayland s názvem y5. Videoukázka.
Po 20 letech a 17 otevřených (open source) krátkých filmech Blender Studio oznámilo plán na svůj první celovečerní film. Cílem samozřejmě není jenom nový otevřený film, ale především vývoj a vylepšení otevřených nástrojů pro spolupráci napříč celým procesem a vytvoření otevřené příručky (playbook) pro filmovou produkci ve velkém měřítku s informacemi, které jsou obvykle dostupné pouze uvnitř komerčních studií, a pomoci tak nezávislým tvůrcům překonat technické a organizační bariéry.
Byla vydána nová verze 26.6.25 svobodného multiplatformního video editoru Shotcut (Wikipedie) postaveného nad multimediálním frameworkem MLT. Shotcut je vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Dobré odpoledne,
TLDR; Nedaří se mi směrovat packety s "odpovědí" zpět do wireguard tunelu.
O co jde
Mám
- VPS v cloudu s veřejnou IP adresou s nastavenou MASQUERADE na `wan0` pro odchozí komunikaci do internetu.
- server 10.11.13.21 v lokální síti (gw 10.11.13.1).
Cílem je:
- zpřístupnit služby na LAN serveru do internetu.
- aby služby na LAN serveru viděly _skutečnou src address_ klienta z internetu.
- aby komunikace počínající (state NEW) na LAN serveru byla směrována standardně přes CGNAT a nikoliv wg tunelem přes VPSku (omezená bandwith, cena).
Nestačí mi:
- Webová reverse proxy na VPSce.
- Protože ta neřeší přístup na ostatní služby (IMAP, SMTP, cokoliv nepoužívající HTTP...)
Vyzkoušel jsem, funguje to, ale nesplňuje to podmínky:
- WireGuard mezi VPS a LAN serverm s pomocí DNAT (směrování portů z veřejné IP na LAN server) a AllowedIPs=0.0.0.0/0: skript `wg-quick` automaticky změní default route a veškerá komunikace jde přes tunel.
- `rathole` mezi VPSkou a LAN serverem - službám se dotazy jeví jako od `localhost`.
Marně zkouším:
- Vypnout automatiku `wg-quick` ohledně směrování.
- Označit komunikaci přicházející na LAN server z `wg0` (tunelu).
- Stejně označit i odpovědi služeb v rámci související komunikace.
- Nastavit policy based routing, aby označené pakety použily jako default route ten tunel a tedy zbylá komunikace nešla přes tunel, ale CGNAT (lokální router a ISP).
Dotaz z internetu přes VPS dorazí na lokální server, ale odpověď se vratí přes lokální router a ISP, takže je nakonec "zahozen". Nicméně, ping mezi VPSkou a LAN serverem funguje.
Konkrétně:
/etc/wireguard/wg0.conf na LAN serveru:
[Interface]
Address = 10.0.37.2/24
... zkráceno ...
Table = off
PostUp = iptables -t mangle -A PREROUTING -i wg0 -j CONNMARK --set-mark 0x51872
PostUp = iptables -t mangle -A OUTPUT -m mark --mark 0x51872 -j CONNMARK --restore-mark
PostUp = ip route add default dev wg0 table 51872
PostUp = ip rule add fwmark 0x51872 table 51872
[Peer]
...
AllowedIPs = 10.0.37.1/32,0.0.0.0/0
Stav na LAN serveru:
# ip rule show all
0: from all lookup local
32765: from all fwmark 0x51872 lookup 51872
32766: from all lookup main
32767: from all lookup default
# ip route show table all
default dev wg0 table 51872 scope link
default via 10.11.13.1 dev br1 proto static
10.0.37.0/24 dev wg0 proto kernel scope link src 10.0.37.2
10.11.13.0/24 dev br1 proto kernel scope link src 10.11.13.21
172.17.0.0/24 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
... zkráceno ...
local 10.0.37.2 dev wg0 table local proto kernel scope host src 10.0.37.2
broadcast 10.0.37.255 dev wg0 table local proto kernel scope link src 10.0.37.2
Co dělám špatně. Případně: jak to vyřešit jinak?
Řešení dotazu:
Ještě k tomu doplním tcpdump na LAN serveru, když z jiného počítače mimo LAN zkouším `ssh -p22 user@moje.vps.net`.
# tcpdump -i wg0 port 22 14:45:39.649749 IP 37-188-184-76.red.o2.cz.46002 > 10.11.13.21.ssh: Flags [S], seq 1788730745, win 65535, options [mss 1420,sackOK,TS val 260893484 ecr0,nop,wscale 9], length 0
# tcpdump -i br1 port 22 | grep -i 'o2.cz' 14:45:39.649823 IP 10.11.13.21.ssh > 37-188-184-76.red.o2.cz.46002: Flags [S.], seq 1539991552, ack 1788730746, win 65160, options [mss 1460,sackOK,TS val 863901811 ecr 260893484,nop,wscale 7], length 0
kde `wg0` je tunel a `br1` je LAN. Dotaz jde tunelem, odpověď odchází do LAN...
Vyřešeno, hloupá chyba.
Bylo:
PostUp = iptables -t mangle -A OUTPUT -m mark --mark 0x51872 -j CONNMARK --restore-mark
Mělo být:
PostUp = iptables -t mangle -I OUTPUT -m connmark --mark 0x51872 -j CONNMARK --restore-mark
V chainu OUTPUT nejsou označeny pakety, pouze spojení. Takže filtr měl být na `connmark` a nikoliv `mark`.
Tiskni
Sdílej: