Americká společnost OpenAI, která stojí za chatovacím robotem ChatGPT, by měla zájem o webový prohlížeč Chrome, pokud by jeho současný majitel, společnost Google, byl donucen ho prodat. Při slyšení u antimonopolního soudu ve Washingtonu to řekl šéf produktové divize ChatGPT Nick Turley.
Po roce vývoje od vydání verze 1.26.0 byla vydána nová stabilní verze 1.28.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.28.
Byla vydána nová verze 10.0.0 otevřeného emulátoru procesorů a virtualizačního nástroje QEMU (Wikipedie). Přispělo 211 vývojářů. Provedeno bylo více než 2 800 commitů. Přehled úprav a nových vlastností v seznamu změn.
42 svobodných a otevřených projektů získalo finanční podporu od NLnet Foundation (Wikipedie).
Americký výrobce čipů Intel plánuje propustit více než 20 procent zaměstnanců. Cílem tohoto kroku je zjednodušit organizační strukturu ve firmě, která se potýká s problémy.
Byla vydána OpenMandriva Lx 6.0 s kódovým názvem Vanadium. Přehled novinek v poznámkách k vydání.
CSIRT.CZ, český národní CERT provozovaný na základě veřejnoprávní správní smlouvy společností CZ.NIC, shrnuje patnáct let svého fungování pod tímto sdružením: CSIRT.CZ – 15 let ve sdružení CZ.NIC.
Commodore OS Vision (Wikipedie) byl vydán v nové verzi 3.0. Jedná se o linuxovou distribuci určenou pro fanoušky značky Commodore. Předinstalována je na počítačích Commodore 64x.
Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 208. brněnský sraz, který proběhne v pátek 25. dubna 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.
Ve svém článku Getting Forked by Microsoft popisuje autor programu Spegel svoji nepříjemnou zkušenost s firmou Microsoft. Firma ho kontaktovala a zpočátku to vypadalo, že by mohlo jít o oboustranně prospěšnou spolupráci, autor tedy ochotně odpovídal na jejich otázky ohledně architektury programu a pomáhal jim ho zprovoznit. Následně komunikace ze strany Microsoftu utichla. Autor předpokládal, že zřejmě došlo ke změně priorit a firma
… více »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?
ip route add veřejná_ip_serveru/32 via stávající_brána
Dekuji 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?
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.
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
za předpokladu že eth0 je rozhraní směrující k poskytovateli
Chain POSTROUTING (policy ACCEPT)
MASQUERADE all -- * eth0 0.0.0.0/0 0.0.0.0/0
za předpokladu že eth0 je rozhraní směrující k poskytovatelibrea:/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 MASQUERADE
Ok, 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
$ 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: