Svobodná webová platforma pro sdílení a přehrávání videí PeerTube (Wikipedie) byla vydána v nové verzi 6.1. Přehled novinek i s náhledy v oficiálním oznámení a na GitHubu. Řešeny jsou také 2 bezpečnostní chyby.
Lennart Poettering na Mastodonu představil utilitu run0. Jedná se o alternativu k příkazu sudo založenou na systemd. Bude součástí systemd verze 256.
Hudební přehrávač Amarok byl vydán v nové major verzi 3.0 postavené na Qt5/KDE Frameworks 5. Předchozí verze 2.9.0 vyšla před 6 lety a byla postavená na Qt4. Portace Amaroku na Qt6/KDE Frameworks 6 by měla začít v následujících měsících.
Byla vydána nová verze 2.45.0 distribuovaného systému správy verzí Git. Přispělo 96 vývojářů, z toho 38 nových. Přehled novinek v příspěvku na blogu GitHubu a v poznámkách k vydání. Vypíchnout lze počáteční podporu repozitářů, ve kterých lze používat SHA-1 i SHA-256.
Před 25 lety, ve čtvrtek 29. dubna 1999, byla spuštěna služba "Úschovna".
Byla vydána nová verze 24.04.28 s kódovým názvem Time After Time svobodného multiplatformního video editoru Shotcut (Wikipedie) a nová verze 7.24.0 souvisejícího frameworku MLT Multimedia Framework. Nejnovější Shotcut je vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Byla vydána verze 5.30 dnes již open source operačního systému RISC OS (Wikipedie).
V aktuálním příspěvku na blogu počítačové hry Factorio (Wikipedie) se vývojář s přezývkou raiguard rozepsal o podpoře Linuxu. Rozebírá problémy a výzvy jako přechod linuxových distribucí z X11 na Wayland, dekorace oken na straně klienta a GNOME, změna velikosti okna ve správci oken Sway, …
Rakudo (Wikipedie), tj. překladač programovacího jazyka Raku (Wikipedie), byl vydán ve verzi #171 (2024.04). Programovací jazyk Raku byl dříve znám pod názvem Perl 6.
Dobry den, zprovoznil jsem si na serveru vpn, po pripojeni se mi vytvori zarizeni tap0 a dostanu na nej IP adresu. Jedine, co mi zbyva, je naroutovat vsechen provoz z meho pocitace na dany server. Tyto pokusy vsak selhavaji:
$ sudo route add -net 0.0.0.0 gw ip_serveru dev tap0 SIOCADDRT: No such process $ sudo ip route add 0.0.0.0/1 via ip_serveru dev tap0 RTNETLINK answers: No such process
Cim to muze byt zpusobeno?
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
24.9.2009 18:27
ip route add veřejná_ip_serveru/32 via stávající_bránaDekuji za podrobny popis, bohuzel me znalosti siti nejsou zas tak vysoke, mozna kdybyste mi to vysvetlil primo na me konfiguraci.
Jeste nez se pripojim na vpn tak to vypada takto:
$ ifconfig wlan0
wlan0 Link encap:Ethernet HWaddr 00:13:E7:5F:19:1A
inet addr:192.168.0.5 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::213:e8ff:fe5f:181f/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:26656 errors:0 dropped:0 overruns:0 frame:0
TX packets:19541 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:19848505 (18.9 Mb) TX bytes:4006347 (3.8 Mb)
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 wlan0
Po pripojeni na vpn se objevi interface tap0:
$ ifconfig tap0
tap0 Link encap:Ethernet HWaddr 36:F8:AF:73:D8:56
inet addr:10.0.1.1 Bcast:10.0.1.255 Mask:255.255.255.0
inet6 addr: fe80::34f8:afff:fe73:d856/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:238 (238.0 b)
a routovaci tabulka vypada takto:
$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.1.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 wlan0
Verejna IP adresa vpn serveru je pro zjednoduseni 1.2.3.4 a jeho adresa ve VPN siti je 10.0.1.100. Maska ve VPN siti je 255.255.255.0. ping 10.0.1.100 funguje. Co mam tedy udelat ted?
Po teto akci vypada routing table takto:
$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 158.194.136.86 192.168.0.1 255.255.255.255 UGH 0 0 0 wlan0 10.0.1.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0 0.0.0.0 10.0.1.100 0.0.0.0 UG 0 0 0 tap0 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 wlan0
10.0.1.100 pingovat mohu, ale do internetu nemohu (ping google.com nefunguje)
Tak jsem zkousel ruzne kombinace az jsem v tom docista zamotal. Kazdopadne co potrebuji je, kdyz zadam u sebe "ping google.com", pak aby ten paket letel napred na vpn server a az pak do sveta. Je toto zalezitost nastaveni routovani u klienta nebo musim provest i nejake zasahy do routovaci tabuly serveru?
25.9.2009 18:39
echo "1" > /proc/sys/net/ipv4/ip_forward
Ok, forwarding jsem zapnul.
Routing table vypada takto:
$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 158.194.136.86 192.168.0.1 255.255.255.255 UGH 0 0 0 wlan0 10.0.1.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0 0.0.0.0 10.0.1.100 0.0.0.0 UG 0 0 0 tap0
a traceroute na google takto:
$ traceroute google.com traceroute to google.com (74.125.45.100), 30 hops max, 40 byte packets 1 10.0.1.100 (10.0.1.100) 28.969 ms 41.833 ms 29.416 ms 2 * *
To znamena, ze na vpn server do dojde, ale co se stane pak? Proc to nefunguje?
Na ten vpn server to vypadá že dojde... teď bude problém na něm. (nat, routing, policy, filtry...).
Podle toho co vidím hádám, že jste ještě nezměnil dns směrem k dns serveru, který slouží u toho vpn serveru... při provozu se mohou objevit některé problémy s nečekanou odpovědí na dns dostaz (hlavně pokud bude server v lokální síti vašeho poskytovatele připojení, nebo naopak v síti u vpn serveru). Dále můžete podle konfigurace pravděpodobně očekávat problémy s velkými rámci... no ale myslím, že teď Vám jde hlavně o ten ping, takže vše na serveru zkontrolovat, jestli je tak jak potřebujete.
25.9.2009 20:24
DjAARA | skóre: 32
| Praha|Náklo|Olomouc
traceroute, například traceroute 74.125.67.100, aby jsme viděli, kudy se snaží s danou ip adresou spojit. Pokud bude jako první skok VPN server na druhé straně, tak pak bude chyba na něm (možná nepovolený ip_forward, firewall, překlad adres?).
Ok, takze viz muj prispevek vyse, traceroute ukazal ze ping leti na VPN server. Na serveru je zapnuty ip_forward. Jak nyni zjistim blize cim to muze byt?
Tak jsem tento radek zapsal do konfigurace serveru a restartoval ho, ale stale to same...
Pokud mam routing tabe takto:
$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 158.194.136.86 192.168.0.1 255.255.255.255 UGH 0 0 0 wlan0 10.0.1.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0 0.0.0.0 10.0.1.100 0.0.0.0 UG 0 0 0 tap0 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 wlan0
tak mohu pingovat vnitrni IP serveru (10.0.1.100), ale nemohu pingovat google. Navic traceroute google.com ukazuj toto:
traceroute google.com traceroute: Warning: google.com has multiple addresses; using 74.125.67.100 traceroute to google.com (74.125.67.100), 30 hops max, 40 byte packets 1 * * * 2 * *
neukazuje zadny skok, takze ani nevim kam ten ICMP paket leti. Zkusil jsem tedy odstranit default gw 192.168.0.1, potom routovaci tabulka vypada takto:
$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 158.194.136.86 192.168.0.1 255.255.255.255 UGH 0 0 0 wlan0 10.0.1.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0 0.0.0.0 10.0.1.100 0.0.0.0 UG 0 0 0 tap0
Stale mohu pingovat 10.0.1.100, google.com nemuzu. Traceroute vsak uz ukazuje toto:
$ traceroute g traceroute to www.google.com (74.125.45.100), 30 hops max, 40 byte packets 1 10.0.1.100 (10.0.1.100) 29.738 ms 34.632 ms 28.715 ms 2 * * *
Takze pingovaci paket dorazi alespon na VPN server. Jinak ze serveru (10.0.1.100) muzu sebe pingovat (10.0.1.1). Nejake navrhy co zkusit nyni?
Chain FORWARD (policy DROP)
ACCEPT all -- tap0 eth0 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- eth0 tap0 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
Chain POSTROUTING (policy ACCEPT)
MASQUERADE all -- * eth0 0.0.0.0/0 0.0.0.0/0
brea:/home/user# cat /proc/sys/net/ipv4/ip_forward 1 brea:/home/user# /etc/init.d/iptables status bash: /etc/init.d/iptables: No such file or directory brea:/home/user# iptables -t filter -vnL WARNING: All config files need .conf: /etc/modprobe.d/nvidia-kernel-nkc, it will be ignored in a future release. Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination brea:/home/user# iptables -t nat -vnL Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination brea:/home/user#
iptables -t nat -A POSTROUTING -o eth0 -s 10.0.1.0/24 -j MASQUERADEOk, udelal jsem to presne podle toho navodu. Pri sudo tshark -i tap0 jsem videl toto:
69.272133 10.0.1.1 -> 74.125.45.100 ICMP Echo (ping) request
Takze to je presne jak jste psal, ale pri tshark -i eth1 vidim take toto:
0.504699 10.0.1.1 -> 74.125.45.100 ICMP Echo (ping) request
Takze zdrojova adresa se na verejnou IP adresu serveru neprepsala... proc?
Jinak distribuce bezici na serveru je debian.
Btw, maska te vnitri site (10.0.1.*) je 255.255.255.0 - coz neodpovida tomu /24 z toho iptables pravidla co jste psal - muze toto zpusobovat problemy?
Chain POSTROUTING (policy ACCEPT 6210 packets, 487K bytes)
pkts bytes target prot opt in out source destination
0 0 MASQUERADE all -- * eth0 10.0.1.0/24 0.0.0.0/0
Co tedy ta maska 10.0.1.0/24 - viz muj prispevek nad vasim, muze prave ta maska byt kriteriem co se nesplni?. Distribuce je debian, soubor /etc/init.d/iptables ale neexistuje. V systemu jsou tyto prikazy:
$ sudo iptables iptables iptables-apply iptables-restore iptables-save iptables-xml
28.9.2009 10:23
DjAARA | skóre: 32
| Praha|Náklo|Olomouc
$ ipcalc 10.0.1.0/24 Address: 10.0.1.0 00001010.00000000.00000001. 00000000 Netmask: 255.255.255.0 = 24 11111111.11111111.11111111. 00000000 Wildcard: 0.0.0.255 00000000.00000000.00000000. 11111111 => Network: 10.0.1.0/24 00001010.00000000.00000001. 00000000 HostMin: 10.0.1.1 00001010.00000000.00000001. 00000001 HostMax: 10.0.1.254 00001010.00000000.00000001. 11111110 Broadcast: 10.0.1.255 00001010.00000000.00000001. 11111111 Hosts/Net: 254 Class A, Private Internet
Pro jistotu bych se zeptal na dve otazky:
1) Ten vypis iptables je proveden na serveru?
2) eth0 - je rozhrani mirici do Internetu? Protoze o kousek vyse bylo pro sledovani provozu tsharkem na internetovem rozhrani dosazovano "-i eth1"
Tomas
1) ano
2) eth1 je rozhrani mirici do internetu, eth0 na danem pocitaci (serveru) je disabled.
Tak v tom pripade je jasne, ze to co ve vypisu
iptables -t nat -A POSTROUTING -o eth0 -s 10.0.1.0/24 -j MASQUERADE
nesedi je parametr -o eth0. Jak je uz ostatne napsano i v dalsich prispevcich.
Tomas
iptables -t nat -F POSTROUTING
iptables -t nat -A POSTROUTING -o eth1 -s 10.0.1.0/24 -j MASQUERADE
Ano, dekuji, spletl jsem to, pouzil jsem eth0 misto eth1, ted uz mohu pingovat do internetu.
Mam vsak jeste jeden dotaz. Proc nefunguje traceroute (treba google.com) - vystupem jsou jen hvezdicky a nevidim zadne hopy i kdyz je jasne ze ten pozadavek projde tam i zpet.
Pingovani domenovych jmen i IP adres funguje. Co nefunguje je traceroute.
iptables -L a
iptables -t nat -L
na serveru?
brea:/home/user# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination brea:/home/user# iptables -t nat -L Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination brea:/home/user#
Tiskni
Sdílej:
