abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    včera 22:33 | Nová verze

    Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.

    Ladislav Hagara | Komentářů: 0
    včera 17:44 | Zajímavý článek

    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.

    karkar | Komentářů: 0
    včera 12:11 | Humor

    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).

    Ladislav Hagara | Komentářů: 2
    včera 10:44 | IT novinky

    Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.

    Ladislav Hagara | Komentářů: 22
    včera 09:55 | IT novinky

    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.

    Ladislav Hagara | Komentářů: 2
    včera 09:33 | IT novinky

    Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.

    Ladislav Hagara | Komentářů: 0
    včera 08:11 | Nová verze

    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.

    Ladislav Hagara | Komentářů: 0
    29.4. 20:55 | Nová verze

    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.

    Ladislav Hagara | Komentářů: 0
    29.4. 16:22 | Nová verze

    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.

    Ladislav Hagara | Komentářů: 0
    29.4. 15:55 | Pozvánky

    Š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 »
    Zdenek H. | Komentářů: 2
    Jaký filesystém primárně používáte?
     (58%)
     (1%)
     (9%)
     (21%)
     (4%)
     (1%)
     (2%)
     (0%)
     (1%)
     (3%)
    Celkem 494 hlasů
     Komentářů: 19, poslední včera 11:32
    Rozcestník

    HTun: Strč prst skrz proxy

    21. 10. 2004 | Bohumír Zámečník | Recenze | 14039×

    Jak obejít zlého a nepřejícího správce sítě? Jak protáhnout obousměrnou IP konektivitu tunelem přes HTTP proxy server? Třeba pomocí programu jménem HTun.

    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.

    Jak to vůbec funguje?

    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.

    HTun protokol 1: Half Duplex

    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.

    HTun protokol 2: Full Duplex

    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.

    Další vlastnosti

    Vyrovnání se s poruchami

    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.

    Podpora pro více klientů

    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.

    Soužití s webovým serverem

    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.

    Snaha o kompatibilitu

    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.

    TUN/TAP ovladač

    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.

    Instalace a provoz

    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
    10.0.0.2 Kryton - HTun klient
    1.2.3.4 Holly - HTun 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
    192.168.0.2 Kryton

    Instalace

    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
    # wget http://htun.runslinux.net/dist/htun-0.9.5.tar.gz
    # tar -xzvf htun-0.9.5.tar.gz
    # cd htun-0.9.5/src
    # make all
    # cp htund /usr/local/bin
    # cp ../doc/htund.conf /etc

    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
    /lib/modules/2.4.6/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.

    Nastavení

    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
    913 ? 00:00:00 htund
    # kill -9 913

    Podobné projekty

    Httptunnel

    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

    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

    HTTPort spojuje funkčnost programů HTun a Desproxy do jednoho balíku. Může běžet ve dvou režimech:

    1. Využítí proxy metody SSL/CONNECT, tj. přímého spojení (jako Desproxy).
    2. Využití pomocného serveru HTTHost provozovaného výrobcem, nebo vlastní instalace - pouze omezená demo verze (tech. princip jako jako HTun, ten je ale svobodný).

    Vývoj: celkem stabilní. OS: Windows, případně emulace pod GNU/Linuxem či Unixem.

    HTTP-Tunnel

    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.

    Závěr

    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.

           

    Hodnocení: 50 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    21.10.2004 08:42 Martin
    Rozbalit Rozbalit vše este ze som sam (schopnym) adminom v nasej firme
    %SUBJ% :-)
    21.10.2004 09:32 android@email.cz
    Rozbalit Rozbalit vše Putty skrz proxy
    Pokud proxy umoznuje https a mate na inetu svuj pocitac s ssh poslouchajicim na 443, pak Putty:
    Connection > Proxy > 
    1. proxy hostname a port
    2. Telnet type
    3. Proxy command: connect %host:%port HTTP/1.0\n\n
    
    Pak 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 ;-))
    Bohumír Zámečník avatar 21.10.2004 15:04 Bohumír Zámečník | skóre: 19 | blog: bohous
    Rozbalit Rozbalit vše Re: Putty skrz proxy
    Ale pouze, pokud proxy umi, nebo ma povolenu metodu CONNECT (urcenou pro HTTPS) a pokud chcete pouzivat pouze SSH/SCP. Jinak stejne nezbyde nez pouzit HTun, ci jine zminene programy. Presto je tohle jednoduche reseni s pouzitim Putty (ci jineho SSH/telnet klienta) moc zajimave.
    "Dobrý den pane, nevíte, která bije?!"
    21.10.2004 18:29 Radek
    Rozbalit Rozbalit vše Re: Putty skrz proxy
    Anebo si pomoci SSH tunelu otevrete libovolne spojeni kamkoliv :) Ve spojeni s Java SSH clientem se jedna o jednoduche ale mocne reseni...
    21.10.2004 09:35 Keny
    Rozbalit Rozbalit vše Lidská blbost je věčná
    Pracuji jako webmaster na úřadě, kterému zajišťuje připojení nadřazený orgán. Umožňuje pouze průchod http dat a ftp blokuje tak, že je možné sice stahovat tuny dat do zblbnutí, ale když chci updatovat jednu pitomou stránku na našem webu, tak to musím realizovat pokoutně přes vytáčené připojení.

    Největší katastrofa však je, že své nestandartní řešení prezentují coby zabezpečení sítě. Argumentují totiž možností napadení systému přes FTP. Pokud je mi známo, tak FTP protokol umožňuje pouze šoupat souborama a při správně nastavených právech by neměl být žádným rizikem.
    21.10.2004 11:08 jm
    Rozbalit Rozbalit vše Re: Lidská blbost je věčná
    Kazda sluzba pristupna zvenci je rizikem. Jak bude bezpecna, zalezi na tom, jak je nastavena a zabezpecena, jak je nastaven firewall, jaky se pouziva software, atd. atd. To plati o HTTP stejne jako o FTP. FTP je mozne sifrovat stejne jako HTTP, nevidim v tom rozdil. Blbost nekterych tzv. spravcu site jde dokonce tak daleko, ze povoluji nesifrovane FTP a sifrovane naopak zakazuji.

    Tyhle admini nezabezpecuji sit, ale jsou naprosto neschopni a protoze ji nejsou schopni zabezpecit, tak proste vsechno zakazou. Nekdy mam pocit, ze by bylo nejlepsi rovnou vytahnout kabel a vyslo by to nastejno. Mimochodem, SSH je predpokladam taky v ramci "zabezpeceni" zakazano, ze?
    Jiří Svoboda avatar 21.10.2004 13:49 Jiří Svoboda | skóre: 37 | blog: cat /dev/mind | Prostějov
    Rozbalit Rozbalit vše Re: Lidská blbost je věčná
    Ten dotaz sice nebyl smerovan na me, ale ano, napriklad u nas (od te doby co nemame vlastni linku, ale jsme "krmeni centralne"), je kvuli bezpecnosti zakazano i to SSH. Povoluje se jen ze zvlastnich duvodu z jedne konkretni IP na jinou konkretni IP. No comment...
    21.10.2004 11:54 Michal
    Rozbalit Rozbalit vše Re: Lidská blbost je věčná
    FTP umoznuje veci, ze by jste se az divil. Zacina to "stazenim" stromu adresarove struktury a koncit to muze dost spatne ..... SCP the best. Nebo aspon sifrovane FTP.
    25.10.2004 14:56 Slušností je se představit!
    Rozbalit Rozbalit vše Re: Lidská blbost je věčná
    zkuste si nastavit passivni rezim u ftp klienta, treba vam to pujde
    vogo avatar 21.10.2004 12:05 vogo | skóre: 34 | blog: "Skládat papír"
    Rozbalit Rozbalit vše Proc Queeg
    Muj komp se menuje Queeg a neni proxy serwer tak proc :) :))
    Nejsem paranoidní, ale to ještě neznamená, že po mě nejdou.
    Bohumír Zámečník avatar 21.10.2004 14:55 Bohumír Zámečník | skóre: 19 | blog: bohous
    Rozbalit Rozbalit vše Re: Proc Queeg
    Jmeno Queeg (stejne jako Kryton nebo Holly) pochazeji z kultovniho serialu cerveny Trpaslik. Vybral jsem je, protoze se ke svym funkcim v clanku celkem hodi. Queeg je zly pocitac, co drzi vladu nad siti a buzeruje usery. Holly je mily pocitac, ktery stedre poskytuje svuj bandwidth. A Kryton, chudacek, je prave onen bity user. S jmenem tvyho kompu to nema nic moc spolecneho. Az na to jmeno. ;)
    "Dobrý den pane, nevíte, která bije?!"
    vogo avatar 21.10.2004 15:05 vogo | skóre: 34 | blog: "Skládat papír"
    Rozbalit Rozbalit vše Re: Proc Queeg
    to vim celej serial znam na spamet videl sem vsechny dily aspon 10x a scenare mam procteny mockrat :), a nemyslim si ze Queeg byl zlej, vzdyt to byl holly :)) ale odsud je to trosku zamotanejsi,a pak i cely clanek :)))) a tak mi nejde do hlavy jak muze proxy delat prevlecenej webowej server :))) sem rad ze je tady i nejakej trpaslikovec :)
    Nejsem paranoidní, ale to ještě neznamená, že po mě nejdou.
    27.10.2004 07:18 SPV
    Rozbalit Rozbalit vše Re: Proc Queeg
    A já mám doma Hollyho u sebe a v obyváku Hilly :-)
    21.10.2004 14:16 Antonin Kral
    Rozbalit Rozbalit vše Alternativy
    teda podle prvniho odstavce jsem si myslel, ze minimalne objevili mimozemsky zivot. Docela fungujici aternativa je treba tady: http://www.winton.org.uk/zebedee/
    21.10.2004 16:42 alenka
    Rozbalit Rozbalit vše Re: Alternativy
    zebedee je dobrá hračka. a protože je i verze v jave, lze provozovat i na win.

    ještě zajímavější je ještě trochu jiný problém - běží mi počítač za NATem nad kterým nemám žádnou kontrolu a já se na tento počítač chci připojovat zvenku (typické použití - v práci mám "svůj" počítač s vnitřní adresou, síť chrání "zlý_admin" a já si něco potřebuji zrovna o víkendu z práce stáhnout). a i tam existuje zajímavé řešení...
    21.10.2004 23:06 Martin Čížek | skóre: 20 | Praha
    Rozbalit Rozbalit vše Re: Alternativy
    Teď jsem mrknul na zebedee, a nezdá se že by to byla alternativa HTunu - nikde v popisu nevidím, že by to umělo tunelovat IP přes HTTP requesty. Nebo se špatně dívám?
    Kdyby dva z nás byli dvěma z nich, všichni z nás by mohli být všemi z nich.
    21.10.2004 15:43 Martin Čížek | skóre: 20 | Praha
    Rozbalit Rozbalit vše Projde to i přes proxy s antivirem?
    Na některých proxy se dělá "antivirová" kontrola, což mj. znamená, že nefunguje předávání dat metodou cut-through (celý request/response se nejdříve _celý_ přijme, pak zkontroluje antivirem a pak případně předá dál). Zkoušel jsem GNU http tunnel a ten nefungoval. Poradí si s tím HTUN?

    Dík.
    Kdyby dva z nás byli dvěma z nich, všichni z nás by mohli být všemi z nich.
    21.10.2004 18:33 Radek
    Rozbalit Rozbalit vše Re: Projde to i přes proxy s antivirem?
    A pres to funguje i SSL? Resp. chova se takhle i prikaz connect?
    21.10.2004 19:29 Martin Čížek | skóre: 20 | Praha
    Rozbalit Rozbalit vše Re: Projde to i přes proxy s antivirem?
    SSL přes to z principu samozřejmě projít nemůže.

    Nicméně, tam kde jsem to zkoušel (nebudu jmenovat :-)), je sice metoda connect klasicky povolena na https port. Ale - ta proxy (resp. některá z nich, mají jich víc v kaskádě) dělá kontrolu formátu aplikačního protokolu, takže když jsem přes metodu connect zkoušel tlačit ssh, prostě mě to uřízlo.

    Takže co se týče uvedeného nejmenovaného "bezpečnostního" řešení a https, sice se nejedná o antivirovou kontrolu, nicméně Queeg zůstává Queegem.
    Kdyby dva z nás byli dvěma z nich, všichni z nás by mohli být všemi z nich.
    21.10.2004 20:31 Radek
    Rozbalit Rozbalit vše Re: Projde to i přes proxy s antivirem?
    Ptam se prave, protoze pres to SSL projit nemuze. K cemu tam pak ten connect je? A proc se na nem provadi nejaka aplikacni kontrola, kdyz by stacilo zakazat ten connect?

    Ja zase znam jednu instituci, kde z "bezpecnostnich" duvodu nebylo povolene ftp, ale jejich IIS delal i proxy (a byl to server pro www.instiituce.cz :) ). A stacilo zvenku udelat cosi jako: connect 10.1.1.25 a byl jsem na svem pocitaci :)
    21.10.2004 22:45 Martin Čížek | skóre: 20 | Praha
    Rozbalit Rozbalit vše Re: Projde to i přes proxy s antivirem?
    Connect je povolen právě kvůli https. A kontrola aplikačního protokolu je kvůli tomu, aby se ověřilo, že to co jde ven na https port, je https. Zřejmě to má sloužit zvýšení bezpečnosti - když už se nějaký škůdce (program) dostane dovnitř, aby měl ztíženou komunikaci se světem.

    Jj, stačí se podívat do logu libovolného http serveru s veřejnou IP -- connectů je tam jak ... ehm. hodně :) Obzvlášť na port 25.
    Kdyby dva z nás byli dvěma z nich, všichni z nás by mohli být všemi z nich.
    22.10.2004 00:25 Radek Hladik
    Rozbalit Rozbalit vše Re: Projde to i přes proxy s antivirem?
    Tak ted jsem zmatenej jak Goro pred Tokijem :)

    Pres tu aplikacni kontrolu SSL z principu projit nemuze (pac ta ceka na celej pozadavek), ale kvuli SSL je tam connect i ta aplkiacni kontrola....

    Unika mi neco? :)
    22.10.2004 02:51 Jirka Kosina
    Rozbalit Rozbalit vše Re: Projde to i přes proxy s antivirem?
    To je ale blbost, ze? HTTPS spojeni je sifrovane, pokud by bylo mozne treti stranou (proxy) nejak "overovat" jeho obsah, tak by si to skutecne privlastek 'secure' nezaslouzilo. Pro tu proxy je to oboje binarni smeti jako binarni smeti. Leda ze by se vydavala za cilovy HTTPS server, jenze to by zase ponekud nesedel certifikat, ze.
    22.10.2004 07:15 Martin Čížek | skóre: 20 | Praha
    Rozbalit Rozbalit vše Re: Projde to i přes proxy s antivirem?
    Myslím, že jsem to řekl dost srozumitelně. Nekontroluje se obsah toho spojení, ale _formát_ procházejících dat. I https má nějakou strukturu/sadu pravidel, kterou můžete zkotrolovat bez znalosti datového obsahu. Klíče to naštěstí nepodvrhuje.

    Jestli stále nevěříte, otevřte si 2 terminály a zkuste se připojit na server, kde běží https i ssh telnetem nebo netcatem (nc) na port 22 a 443. Rozdíl určitě poznáte. A pozná ho i ta proxy.
    Kdyby dva z nás byli dvěma z nich, všichni z nás by mohli být všemi z nich.
    22.10.2004 07:45 Martin Čížek | skóre: 20 | Praha
    Rozbalit Rozbalit vše Re: Projde to i přes proxy s antivirem?
    PS. Ta první věta měla být "Asi jsem to neřekl dost srozumitelně" :-D. Při zmínkách o aplikační protokolu jsem měl namysli aplikační protokol ve smyslu TCP/IP (ne OSI), proto možná to nedorozumění.

    Každopádně tím povídáním o CONNECTu jsem hlavně chtěl říct, že ač je povolen, není pro tunelování o moc přívětivější než klasické HTTP metody.
    Kdyby dva z nás byli dvěma z nich, všichni z nás by mohli být všemi z nich.
    22.10.2004 11:23 Digero
    Rozbalit Rozbalit vše Uzasna proxy
    Delam v jedne vetsi firme. Jediny pristup jak se dostat ven je MS proxy, ktera provadi jakousi divnou autorizaci, takze IE projde, Mozilla obcas taky, Opera a dalsi programy jsou bez sance. Nejvetsi sranda je kdyz tahle proxy spadne (jednou do tydne tak na dve hodiny)... uz jsme se parkrat pripojovali pres GPRS.

    :-[
    23.10.2004 10:12 Lubomir Roubal
    Rozbalit Rozbalit vše Re: Uzasna proxy
    A nebude to ten uzasny Microsoft ISA server? Nejsem agent mrkvicky takze se v MicroSOFTU nevyznam. Ale od te doby co spravuji indosackou ucebnu pripadam si jak alenka v risi divu. Pred tim jsem spravoval jen prevazne unixove masiny.Ten proxy autorizuje klient Proxy firewall client co se nachazi na widli masine a IMHO predava proxyne udaje o tom ktera aplikace posila http pozadavky(jiny smysl ve vyuziti programu na klientovi nevidim).
    25.10.2004 10:03 myxlmynx
    Rozbalit Rozbalit vše Re: Uzasna proxy
    Tiez pracujem vo vacsej firme a tiez mame MS proxy. A preto pouzivam toto. Vytvori sa lokalny sever, ktory sa pernamentne autentifikuje na M$ ISA Proxy(parent proxy), potom uz len staci v Firefoxovi(Opere, Mozille, ...) nastavit proxy na lokalhost+prislusny port.
    Pre nastavenia toho servera je potrebne vediet adresu a port parent proxy, ale to by uz namal byt problem.
    26.10.2004 20:00 kvbik
    Rozbalit Rozbalit vše Re: Uzasna proxy
    Jestli jsi myslel "ntlm proxy", tak ano, pomoci neho jde rozchodit ve windowsacke siti kde co. Je to aplikace napsana v pythonu a chova se jako takovy maly proxy server, ktery vsechny pozadavky zabali MS (ntlm) autorizaci a posle dal na skutecnou proxy.

    Rozchodil jsem tak firefox a wget.
    Pak jsem zkousel httptunnel, ktery z domova fungoval, ale tady jsem skoncil. Tady, kde pracuji ja, je ryze MS sit, proxy nepodporuje metodu CONNECT, takze mohu tunelovat jedine pomoci klient/server tunelu. Ale jak jsem jiz psal, pomoci httptunnelu se mi to nepovedlo. Az bude cas, vyzkousim i tento HTun.

    Podarilo se nekomu rozchodit tunel (treba protunelovat ssh akrz http) v takovehle MS siti jakou jsem popisoval?
    15.5.2005 13:16 Trinom | skóre: 8 | Brno
    Rozbalit Rozbalit vše Jiná možnost
    Jak bych měl postupovat, když chci toto: Mám webserver s mdk linuxem na veřejné adrese (213.191.107.131) a ten má 2 síťovky. Jedna jde na net a druhá do mé minisítě (kde se hlásí jako 192.168.0.1). Vedle mám druhý komp, na kterém běží taky webserver (má 192.168.0.2) pro webkameru (nejde mi pod linuxem :-( - mám tam wokna). A já bych se chtěl připojit na ten druhý komp tak, abych zadal http://213.191.107.131:8080 (nebo jakýkoliv jiný port). Náš admin mi poradil, že se mám ptát po ip tunelu. Co mám udělat (nejsem žádnej profík!)?

    Díky za nakopnutí, Tomáš
    15.5.2005 17:30 Dramon
    Rozbalit Rozbalit vše Re: Jiná možnost
    Myslim, ze tohle by mohlo vyresit obycejne mapovani portu.
    Bezpecne to bude tak, jak je zabezpecena ta kamera, jelikoz to ona bude videt z venku.
    Doufam, ze jsem to posal alespon trochu jasne.

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.