Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »Mnoho lidí nevidí žádný významový rozdíl mezi pojmy web a internet. Kromě bezpečnosti je možná z tohoto důvodu internetová konektivita v mnoha firemních a jiných sítích omezena jen na protokol HTTP[S], a to ještě pouze přes proxy server. V prostředí s omezenou konektivitou si tak mnohé nadějné protokoly a aplikace najdou své uživatele bohužel jen těžko. Tři studenti z Technologického institutu v Atlantě - Moshe Jacobson, Ola Nordström a Russel J. Clark - se s tím nechtěli smířit, a proto navrhli a implementovali program HTun, který umožňuje protáhnout IP tunel přes HTTP proxy server.
Pro začátek předpokládejme následující modelovou situaci: Máme lokální síť, která není směrovatelná do internetu a používá privátní IP adresy (tedy běžná situace). Uvnitř této sítě běží počítač (říkejme mu pro lepší orientaci např. Kryton), který má jediné spojení do internetu přes HTTP proxy server (např. Queeg). Ten povoluje spojení většinou pouze na porty 80, 8080 a 443. A nyní přichází na řadu HTun. Tato služba se skládá ze dvou částí: z klienta, který běží na počítači uvnitř omezené sítě, a ze serveru bežícího mimo - někde na internetu. Tento server (pojmenujeme si ho Holly) umožňuje klientovi připojit se na jeho porty 80, 8080 nebo 443 a pro proxy se tváří jako obyčejný webový server.
Veškerá spojení do internetu na Krytonovi přesměrujeme na virtuální síťové rozhraní, kde poslouchá HTun klient, program, jenž balí pakety do HTTP požadavků typu POST a odesílá je přes Queega Hollymu. Ten požadavky rozbalí a jako pakety je směruje do internetu. Co ale, když server bude mít příchozí pakety pro klienta? Podle protokolu HTTP se server přeci nemůže připojit sám ke klientovi. Na tento důležitý problém vývojáři také narazili a vypracovali postupně dvě řešení ve dvou verzích protokolu.
První, tzv. Half Duplex verze, využívá metody zvané polling -
klient se po určité době nečinnosti pravidelně "vyptává" serveru, zda-li
nemá pro něj nějaký paket ve frontě. Pokud bychom ale pro každý paket
vytvářeli nový HTTP požadavek a tudíž nové síťové spojení, bylo by to
velice neefektivní. Z toho důvodu se využívá trvalých (persistentních)
spojení pomocí HTTP hlavičky: Proxy-Connection: Keep-Alive
.
Tím pádem lze do jednoho HTTP požadavku vložit neomezený počet tunelovaných
paketů, aby se tak lépe využila kapacita paketů fyzických.
Pokud jde o výkonnost tohoto protokolu, vývojáři prováděli mnoho testů, z nichž vyplývá, že průchodnost tunelu může být důsledkem nákladů na přenos (HTTP hlavičky, rozdělení do více paketů čekání při dalším zpracování, apod.) nižší až o 30-40% vůči přímému spojení po stejné trase. Zároveň zjistili, že čas potřebný k "pingnutí" se na druhý konec tunelu (neboli odezva) velice kolísá a u takového SSH provozu je to už celkem znát. Bylo nutné vymyslet jiný mechanismus.
Hlavní inovací ve druhé verzi protokolu HTun je rozdělení provozu do 2 oddělených kanálů - jeden pro odesílání dat a druhý pro příjem. Kromě portu 80 se zde pro další kanál využívá i port 8080. Toto rozdělení do 2 kanálů citelně stabilizuje odezvu a trochu i zlepšuje propustnost. Do této verze protokolu měla být původně zařazena i podpora tzv. Chunked Transfer-Encoding, přenosu mnoha oddělených bloků dat, u nichž neznáme dopředu jejich velikost, v rámci jednoho HTTP požadavku. Tuto vymoženost protokolu HTTP verze 1.1, jež by o trochu snížila náklady na přenos, ale zatím bohužel podporuje pouze málo rozšířený proxy server Jigsaw od W3C - a stejně pro HTun nevhodným způsobem. Tak snad někdy v budoucnu.
Co se bude dít v případě nějaké poruchy? Je-li chyba na straně klienta nebo kvůli síťovému výpadku, klient se jednoduše znovu připojí. A pokud nebyl výpadek příliš dlouhý, naváže se na původní paketovou frontu a spojení může nerušeně běžet dál. Pokud ovšem spadne proxy nebo HTun server, na původní frontu dat se nelze navázat, a tak se spojení musí navázat úplně od začátku.
Protokol HTun je koncipován tak, aby umožnil připojit se k HTun serveru
více klientům zároveň. To znamená zajistit identifikaci jednotlivých
požadavků - zatím podle MAC adresy síťové karty - a za druhé vytvořit pro
každého klienta vlastní virtuální privátní síťové rozhraní. Automaticky se
proto vybere jeden pár volných IP adres z privátních rozsahů k tomu
určených: 10.*.*.*
a 192.168.*.*
tak, aby
vyhovoval oběma stranám. Pokud by se totiž vybrala adresa, kterou už
používá nějaký počítač na naší síti, nastal by konflikt a nešlo by se
připojit ani na jedno místo. Přijatelné rozsahy tak lze nastavit v
konfiguračním souboru.
Má-li běžet na stejné adrese a portu jako HTun server i webový server, není to pro HTun žádný problém. Všechny požadavky, jimž nerozumí, může přeposílat na předem nastavený webový server. Sice to bude znamenat určité snížení výkonu pro tuto webovou službu, ale při menším provozu to zas tak vadit nebude.
Za zmínku stojí i snaha vývojářů o co největší kompatibilitu, aby HTTP požadavky prošly přes co největší počet různých proxy serverů - bez jakýchkoliv změn v jejich konfiguraci.
Pro svá virtuální síťová zařízení vyžívá HTun služeb univerzálního
ovladače TUN/TAP, který je
součástí linuxového jádra. Jelikož v Linuxu se snad cokoliv může tvářit
jako soubor, spravuje si tento modul soubor /dev/net/tun
.
Kdykoliv nějaký program tento soubor otevře, vytvoří se nové síťové
zařízení, např. tun0
. Všechna data zapsaná do tohoto souboru
se objeví na zařízení tun0
- jakoby přišla ze sítě. Stejně tak
všechny pakety poslané na tun0
lze přečíst z onoho souboru.
Jednotlivé instance se určují podle tzv. file descriptoru. Kromě zařízení
tun
existují i zařízení tap
. Rozdíl mezi nimi je,
že tun
je pro IP rámce (v praxi pro spojení mezi dvěma
adresami), kdežto tap
je pro ethernetové rámce (nižší vrstva,
pro více protokolů - např. TCP/IP, IPX). Uživatelské rozhraní k ovladači
TUN/TAP poskytuje například program VTun.
Budeme předpokládat modelovou situaci zmíněnou v úvodní části článku. Máme místní síť s konektivitou omezenou čistě na proxy server a máme HTun server někde na internetu:
10.0.0.1 Queeg - proxy server
|
Naším cílem je vytvořit tunel z Krytona na Hollyho a všechen síťový provoz, který nebude do místní sítě, nasměrovat do tunelu:
192.168.0.1 Holly
|
Stáhneme si
nejnovější verzi HTunu a rozbalíme, zkompilujeme, nainstalujeme... Pokud
chceme podporu pro ladění, místo make all
dáme
make debug
a htund
po nastavení spustíme s
parametrem -d
.
# cd /usr/local/src
|
Nyní zjistíme, zda-li máme jaderný modul tun.o
pro TUN/TAP.
Např.:
ls /lib/modules/`uname -r`/kernel/drivers/net/tun.o
|
Pokud ne, je nutné si jádro překompilovat s podporou TUN/TAP. V
konfiguraci jádra zašrktneme Network device support --> Universal
TUN/TAP device driver support
jako
modul nebo v konfiguračním souboru jádra (.config
) zadáme
CONFIG_TUN=m
.
Přesvědčíme se rovněž o přítomnosti souboru /dev/net/tun
.
Používá-li naše distribuce devfs, udev, skript MAKEDEV nebo jiný prostředek
k automatickému vytváření /dev souborů, je pravděpodobné, že bude vše v
pořádku. Jinak si tento soubor vytvoříme sami:
# mknod /dev/net/tun c 10 200
|
To znamená vytvořit znakové zařízení ("c") s čísly: major 10 a minor
200. Aby se modul tun.o
natáhl, kdy ho potřebujeme, přidáme do
/etc/modules.conf
nebo jiného konfiguračního souboru pro
moduly řádku:
alias char-major-10-200 tun
|
Nakonec na to pro urovnání závislostí pustíme
depmod -a
.
Celé nastavení programu HTun se provádí v souboru
/etc/htund.conf
, který nastavíme přibližně následovně (tak
nějak to píšou v README). Jednotlivé volby jsou detailně popsány v dokumentaci.
# htund.conf na serveru Holly options { daemonize no logfile /var/log/htund.log tunfile /dev/net/tun } server { iprange 192.168.0.0/24 # prijatelny IP rozsah server_port 80 secondary_port 8080 max_clients 10 max_pending 40 idle_disconnect 1800 clidata_timeout 20 min_nack_delay 150 packet_count_threshold 10 packet_max_interval 10 max_response_delay 200 } |
# htund.conf na klientu Kryton options { daemonize no logfile /var/log/htund.log tunfile /dev/net/tun } client { do_routing no protocol 2 # Protokol v2 - Full Duplex proxy_ip 10.0.0.1 # Queeg proxy_port 3128 # vychozi port pro Squid # odkomentovat, pouze je-li proxy pod heslem # proxy_user jenicek # proxy_pass m4R3nk4 server_ip 1.2.3.4 # Holly server_port 80 # odesilaci kanal secondary_server_port 8080 # prijimaci kanal if_name eth0 # sitovka pro MAC adresu - identifikace iprange 192.168.0.0/24 connect_tries 2 reconnect_tries 4 reconnect_sleep_sec 30 channel_2_idle_allow 30 min_poll_interval_msec 200 max_poll_interval 30 poll_backoff_rate 3 ack_wait 10 } |
Pak stačí spustit (nejdřív server, pak klient) příkazem:
# htund
|
Podíváme se ještě, zda-li bylo zařízení úspěšně vytvořeno a linka nahozena.
holly# ifconfig tun0 tun0 Link encap:Point-to-Point Protocol inet addr:192.168.0.1 P-t-P:192.168.0.2 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:21 errors:0 dropped:0 overruns:0 frame:0 TX packets:21 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:10 RX bytes:1764 (1.7 KiB) TX bytes:1764 (1.7 KiB) |
Nakonec si ještě na Krytonovi manuálně nastavíme směrování (prý to jde i nějak automaticky):
kryton# route add default gw 192.168.0.1
|
Zkusíme, jestli vše funguje:
kryton# netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 tun0 kryton# ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1): 56 data bytes 64 bytes from 192.168.0.1: icmp_seq=0 ttl=128 time=81 ms holly# ping 192.168.0.2 PING 192.168.0.2 (192.168.0.2): 56 data bytes 64 bytes from 192.168.0.2: icmp_seq=0 ttl=128 time=79 ms |
Program HTun vypneme pomocí následujících příkazů. Číslo procesu (PID) bude přirozeně jiné než v příkladu.
# ps -A |grep htund
|
Program Httptunnel dokáže protáhnout proxy serverem pouze datový tunel, nikoliv přímo VPN. Je tak možno přes tento tunel provozovat telnet, SSH, apod. IP tunel by možná šel udělat s pomocí PPP. Nevím. Poslední vývojové vydání: březen 2004. OS: GNU/Linux, Windows
Desproxy umožňuje TCP spojení přes HTTP proxy pouze pomocí metody CONNECT - ve stylu SSH port forwardingu. Vývoj v srpnu 2004 ukončen. OS: GNU/Linux, BSD, Windows, Solaris, jiné OS podle standardu POSIX.
HTTPort spojuje funkčnost programů HTun a Desproxy do jednoho balíku. Může běžet ve dvou režimech:
Vývoj: celkem stabilní. OS: Windows, případně emulace pod GNU/Linuxem či Unixem.
HTTP-Tunnel je komerční řešení podobné nejspíše HTTPortu s tím, že lze využít jen volných (pomalých) nebo předplacených (rychlejších) služeb hostovaného serveru (jako HTTHost). OS: pouze Windows.
Uvedené řešení pomocí HTun předpokládá, že máme v rámci sítě s omezenou konektivitou k dispozici počítač, na němž běží GNU/Linux (případně FreeBSD). Máme-li ale tak zlého, paranoidního (nebo neschopného) správce sítě či vedoucího IT oddělení, asi těžko nám povolí i ten Linux. Přesto je HTun zajímavým řešením.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Connection > Proxy > 1. proxy hostname a port 2. Telnet type 3. Proxy command: connect %host:%port HTTP/1.0\n\nPak Putty uz funguje jako normalne. WinSCP lze nastavit podobne. V clanku je uvazovan take vlastni server a tohle mi prijde jako nejjednoduzsi reseni problemu. PS Admin proxy pak v logu muze videt prenosy pres CONNECT 70MB a podobne