Pred par dnami som sa potreboval pretunelovat zo stroja A na stroj
B kvoli http proxy, no a nevedel som akosi najst nic, co by mi to spravilo
lacno a rychlo a hlavne bezbolestne. Mohol som sice pouzit ssh -L, ale chcel
som mat aj autentifikaciu a mat to permanentne zapnute. Nehovoriac o tom,
ze som nechcel klepat skripty a v duchu open source som dufal, ze nieco podobne
uz niekto urobil za mna (hlavne elegantne).
Odpoved je ano - urobil. Balicek sa vola stunnel (www.stunnel.org). No
a kedze mi to pekne ide, rozbehal som ho aj s autentifikaciou cez vlastne
certifikaty za chvilu a islo to na prvy krat bez nutnosti zdlhaveho odradzujuceho
hrabania sa na googli, tak by som sa chcel s vami o to podelit.
Takze to co tu najdete popisane je:
1) Uvod - zakladne veci, co je to stunnel
2) Scenar - modelova situacia: HTTP Proxy
3) Instalacia - balicky a OS
4) Vytvorenie vlastnej CA - potrebne kvoli autentifikacii
5) Vytvorenie 2 certifikatov a ich nasledne pouzite pre ucely tunelu - potrebne
kvoli autentifikacii
6) Konfiguracia k stunnelu - obsah konfiguracnych suborov a co kde najst a kam
dat certifikaty
7) Spustenie - ako tunel spustit, co uvidim v logoch
8) Par poznamok na zaver - coho sa vyvarovat ked tunel bezi ako demon
1.) UVOD
Co je to tunnel (pozor idem hovorit o tuneli ako o pojme) ? Jednoducho
povedane, spojenie medzi dvoma pocitacmi, ktore zapuzdruje v sebe iny protokol.
Samotne zapuzdrenie negarantuje sifrovanie ani autentifikaciu. Nema teda prvky
VPN. Nehovoriac o tom, ze nemusi pracovat na urovni nizsich vrstiev (2,3) tak
ako je to u VPN zvykom (http://tools.ietf.org/html/rfc4026).
'stunnel' je aplikacia, ktora zapuzdruje pakety inych protokolov
podla nastavenia v konfiguracnom subore a pouziva SSL vrstvu na ich sifrovanie
a transport na druhu stranu. Tento program pracuje v mode server alebo klient.
Server poskytuje moznost autentifikacie klienta s pouzitim certifikatov, podla
nastavenej urovne. Uprimne povedane stunnel toho dokaze este trochu viac, ale
kedze ja som ho potreboval na sifrovanie a autentifikaciu, tak tu opisem len
tuto cast.
Podla stranky www.stunnel.org este vie veci, ako napr. vybrat si,
ktore sifry chcem pouzivat, 'transparent proxy mod' (t.j. ten, kto posiela a
prijima pakety, nebude vediet, ze vobec cez nejaky tunel isli, kompresia dat a to,
ci ma udrziavat session, alebo sa autentifikovat pri kazdej konekcii...)
Dovod modu 'server' a 'klient' je v tom, ze niekto autentifikuje a niekto je
autentifikovany (nechcem to rozpitvavat, pretoze skoncime pri diskusii, ktorej
vysledok bude, ze v uplnom detaili je kazda konekcia typu server/klient, nehovoriac
o tom, ze aj argument, co som pouzil, je z isteho pohladu blbost, ale nechajme
to tak).
Rad by som este podotkol, ze podla stranky stunnelu existuje verzia aj
pre windows. Takze ti, co chcete pouzivat tuto srandicku pod windowsom, tak
mozete. Ja moc windows nepouzivam, takze som neskumal nakolko je to obtiazne
a ci su k dispozicii binarky alebo to treba nejako kompilovat. V kazdom pripade
stranku som poskytol, tak mozete vyskusat ;)
2.) SCENAR - MODELOVA SITUACIA
Paranoidni dobre plateni administratori kontroluju traffic medzi mojim
strojom 'A' v ich sieti a okolnym svetom. Ja si chcem samozrejme slobodne behat
po svete a navstevovat stranky, ako bola byvala hysteria alebo sucasny blackhole.
Zli ujovia su taki zli a posrati, ze ked sa pozriem na hysteriu (chap otvorim v
browseri) tak mi posielaju vyhrazne emaily, ze som hrozne strasny hacker uslintany
a skaredy a tucny a odporny, co si v zivote nenabali zensku a nezapicha a preto
si musi liecit komplexy tym, ze sa naburava do narodnych a inych sieti a robi zle
a urcite si v zivote nezapicha atd...
Mna to samozrejme uraza. Nevidim predsa nic zle na ziskavani vedomosti z oblasti IT. Nehovoriac uz o tom, ze nie som ziadny heker a ani sa nenaburavam
do narodnych ani inych sieti (naco by som to robil? a to ostatne co vraveli su
puhe spekulacie, ku ktorym sa nebudem vyjadrovat). Nastastie si spomeniem, ze
mimo ich siete mam stroj 'B', na ktorom mi bezi apache a preto mi napadne
nasledovna vec: spravit si tunel medzi mojim strojom 'A' a strojom 'B' (ktory uz
oni nemozu kontrolovat, lebo je to mimo ich siete) a na ktorom mam
apache so zapnutym http proxy (pre istotu bindnutym na loopback).
Pocitac A z ktoreho sa pripajam:
stunnel V mode 'klient'
IP pocitaca 211.0.0.10
Klient prijima pakety z 127.0.0.1:80
Klient posiela zapuzdrene pakety na 158.100.0.11:1337
Pocitac B na ktory sa pripajam:
stunnel
V mode 'server'
IP pocitaca 158.100.0.11
Server prijima pakety z 158.100.0.11:1337
Server posila odpuzdrene pakety na 127.0.0.1:80
Apache ma nastaveny http proxy na 127.0.0.1:80
Komunikacia potom prebieha nasledovne : A chce otvorit stranku, tak posle http
request na server 127.0.0.1:80. Tunel prevezme data, zapuzdri ich a posle ich na druhu
stranu tunela 158.100.0.11:1337. Tu sa data rozpuzdruju (sorry - lepsi vyraz ma nenapadol)
a poslu sa proxy serveru 127.0.0.1:80. Ten ich preposle do sveta, prijme stranku a
posle data naspat tunelu na pocitaci 'B'. Ten ich zapuzdri a posle po tej istej
session naspat 'A'cku. Ten ich rozpuzdruje a poda browseru.
Pri zacati konekcie sa overi certifikat clienta podla nastavenej urovne v serveri
a to bud:
level 1 : ak certifikat existuje, tak sa overi - inac sa pokracuje bez autentifikacie
level 2 : certifikat sa overi a sleduje sa, ci ho podpisala nejaka CA znama systemu
level 3 : certifikat sa overi s lokalnymi kopiami (jednak samotneho certifikatu
klienta, ako aj celeho chainu az po CA)
3.) INSTALACIA
Ja osobne som to rozbehaval na debiane (aj server aj klient), no a v debiane
v testing je balicek stunnel4. Okrem toho treba aj openssl balicek. Na samotnej stranke
su pokyny k downloadnutiu zdrojakov. Predpokladam, ze ostatne distribucie budu mat podobny
balicek v sebe tiez. Instalacia je klasicka (pre debian). Zo suborovej struktury
je dolezite vediet:
/etc/stunnel/stunnel4.conf - Hlavny konfiguracny subor pre stunnel
/var/lib/stunnel4 - Default chrootjail pre tunel. Tu si defaultne hlada certifikaty
ak nema povedane inak a uchovava tu aj pid file.
/etc/init.d/stunnel4 - Demon
/etc/default/stunnel4 - Konfiguracia pre demona (ci sa ma pustit spolu so startom
systemu, kde ma hladat konfigurak a pod. vid sekcia s poznamkou)
4.) VYTVORENIE VLASTNEJ CA
Kto chce mat "len" tunel, tak moze tuto cast, ako aj cast 5) prekrocit. Vyskusal som
si tunel aj bez certifikatu a fachci to. Akurat, ze je to tunel v podstate verejny. Nenasiel
som totizto ziadne obmedzenia ani kontrolu toho, kto sa moze a kto nemoze pripojit - co je
v podstate aj dovod, preco som tu autentifikaciu vobec riesil.
K tomu, aby som mohol v stunneli pouzit autentifikaciu prostrednictvom certifikatov,
potrebujem samotny certifikat. Okrem toho tento certifikat by mal byt podpisany nejakou
trusted certifikacnou autoritou. Certifikat CA sa vyznacuje tym, ze je self-signed (podpisany
samym sebou). Stunnel ma problem pouzit priamo certifikat CA. Preto si musime vyrobit CA,
na co mame v openssl balicky command line tool-y a pomocou certifkatu tejto CA podpisat
certifikat pre server aj klient.
Rozmyslal som najprv, ze sem samotne vytvaranie CA a certifikatov nedam, ale kedze
to mi zabralo najviac casu, tak to sem napisem, nech to mate kompletne.
Balicek openssl obsahuje nasledovne skripty, ktore budeme pouzivat:
/usr/lib/ssl/misc/CA.pl - perlovsky skrit, vytvorenie tzv. demoCA
/usr/bin/c_rehash - bashovsky skript, ktory vytvori symlinky pre existujuce
certifikaty tak, ze meno tejto symlinky bude hash z certifikatu
(dufam, ze som to nepoplietol. Pravdou vsak je, ze bez tejto symlinky
vam to nepojde. No fakt, ze to meno ma byt take ake ma byt, je dane
openssl kniznicou. Vraj ide o to, ze si ssl aj tak robi z
certifikatov hashe a ked ich uz ma dopredu urobene, tak sa nemusi
stracat cas ich robenim pocas behu. Ak sa mylim tak ma prosim
opravte)
Postup je nasledovny:
1) Bud root
2) Chod do adresara /usr/bin/ssl/misc a pusti CA.pl -newca (dovod, preco som pouzil perlovsky skript
a nie shellovsky je ten, ze shelovsky sa mi zjebal, aj ked som vyplnil vsetko co chcel)
3) Vypln otazky, na ktore sa ta pyta. Ked ich vyplnis, tak sa ti v /usr/bin/ssl/mic vytvori
podadresar demoCA. Tymto skriptom sa vytvorila certifikacna autorita a vsetky potrebne
veci k nej. Cize subor s klucom (demoCA/private/cakey.pem), zoznam certifikatov, ktore
tato CA podpisala plus ich hashe a dodatocne info ako napr. DN (demoCA/index.txt) a
hlavne certifikat certifikacnej autority (demoCA/cecert.pem).
Podotykam, ze v tom vyplnani treba urcite vyplnit polozku 'Common Name'. Ono dalo by sa toho popisat
viac, ale toto je clanok o tuneli nie o certifikacnych autoritach. Podrobnejsi (o cosi) postup
a detaily mozno najst napriklad tu : http://www.octaldream.com/~scottm/talks/ssl/opensslca.html
5) VYTVORENIE CERTIFIKATU PER STUNNEL SERVER A STUNNEL CLIENT
Opat, tato sekcia je len pre tych, co chcu mat autentifikaciu, ak ju nepotrebujete
tak kludne prejdite na cast 6.
Takze, pojdeme do adresara /usr/lib/ssl a spustime CA.pl -newreq tym sa nam vytvori ziadost
pre certifikat (ako root). Ak vytvaram certifikat pre server, tak Common Name ma byt meno hosta.
(cize napriklad www.blackhole.sk). Vytvoria sa 2 subory : kluc (/usr/lib/ssl/newkey.pem) a
ziadost (/usr/lib/ssl/newreq.pem).
Po vytvoreni ziadost o certifikat podpisem: CA.pl -sign Skript standarne hlada newreq.pem.
Vytvori sa mi tentokrat uz certifikat, ktory pouzijem o chvilu. Postup zopakujem pre klienta.
Subory klucov a zodpovedajucich certifikatov pre klienta aj server asi dam niekde bokom, pretoze
ich budem potrebovat, tak isto aj certifiakt CA.
6) KONFIGURACIA STUNNELU PRE SERVER A KLIENT
V tejto casti popisem, ako skonfigurovat stunnel4.conf s a bez autentifikacie pre server
a klient. Tak isto poviem maly detail o konfiguraku k demonovi.
6.1) Konfiguracia servera bez autentifikacie
Upravte subor /etc/stunnel4/stunnel4.conf tak, ze pouzijete len nasledovne veci a ostatne nechate
tak:
----------------------
cert = cesta_k_certifikatu_servera ta je potrebna tak ci tak v serveri, ale v klientovi nie
key = cesta_ku_klucu_servera ta je potrebna vzdy
compression = rle podla mna je fajn mat zapnutu kompresiu
;verify = 1 toto nechat zakomentovane
;debug = 7 defaultne zakomentovane, hodi sa ked to nepojde
output= cesta_k_logu defaultne /var/log/stunnel4/stunnel.log
client = no momentalne chceme server
[https] meno sluzby (stunnel filtruje TCPwrapper, aby sa clovek
vyznal v logoch
accept = 158.100.0.11:1337 na tejto adrese a porte server pocuva na prichodziu zapuzdrenu
zasifrovanu konekciu
connect = 127.0.0.1:80 na tuto adresu a port posle obsah ktory mal v sebe (cize napr.
podla casti 2 toho clanku to je http komunikacia, ktora ide
k apachu na pocitaci B)
-----------------------
Este by som podotkol, ze v konfiguraku moze byt definovanych nieklko sluzieb so smerovanim na uplne ine
servre (cize napr. FTP, POP..., staci pridat novu sekciu [sluzba] a napisat pozadovany accept a connect)
6.2) Konfiguracia servera s autentifikaciu
Upravte subor /etc/stunnel4/stunnel4.conf podla casti 6.1) a pridajte:
----------------------
verify = 3 zapne autentifikaciu na urovni kontroli certifikatou s lokalnou
kopiou
CApath = /certs do adresara certs treba dat vsetky certifikaty (certifikat CA,
certifikat servera, certifikat klientov, ktorych chcem pustit
dalej). Upozornenie: defaultne je zapnuty chroot jail na
/var/lib/stunnel4 a CApath sa hlada v ramci neho.
----------------------
6.3) Konfiguracia klienta bez autentifikacie
Upravuje sa subor /etc/stunnel4/stunnel4.conf nasledovne:
----------------------
key = cesta_ku_klucu_klienta
compression = rle vid 6.1
;verify = 1 vid 6.1
;debug = 7 vid 6.1
output = cesta_k_logu vid 6.1
client = yes ano konfigurujem klienta
[https] meno sluzby. Sluzi pre stunnel na rozoznanie, ku ktorej sluzbe
dana konfiguracia patri.
accept = 127.0.0.1:80 adresa a port kde klient caka na pakety, ktore bude zapuzdrovavat
a sifrovat. (v zhladom na cast 2 tohoto clanku je to browser, ktory
sem bude posielat http)
connect = 158.100.0.11:1337 na tuto adresu a na tento port sa data zapuzdrene a zasifrovane data
poslu
----------------------
6.4) Konfiguracia klienta s autentifikaciou
Upravte subor /etc/stunnel4/stunnel4.conf podla 6.3 a doplnte tam:
----------------------
cert = cesta_k_certifikatu_klienta chceme autentifikaciu, tak musime vediet kde mame certifikat
verify = 3 chceme overovanie podla lokalnej kopie
CApath = /certs Certifiakty budu v adresari /certs (vid upozornenie v 6.2) konkretne
certifikat certifikacnej autority a certifikat klienta
----------------------
6.5) Finalne upravy pred spustenim
Predpokladajme, ze sme dali certifikaty do ich defaultnych adresarov, cize do /var/lib/stunnel4/certs.
Teraz treba spustit funkciu c_rehash s danym adresarom, cize c_rehash /var/lib/stunnel4/certs. V
konfiguracnych suboroch sice uvadzam osobitne cestu k certifikatom a CApath, ale ja som ich dal do CApath
vsetky aj tak. Pozor! Bez c_rehash to na 100% nepojde. Tak isto to na 100% nepojde pokial v CApath nebudu
certifikaty klientov a certifikat CA. To iste plati pre klienta. Ten musi mat v CApath certifikat servera
a certifikat CA.
Dodatok ku konfiguracii demona je len ten, ze keda sa ho clovek pokusi len tak spustit, tak sa nic
nestane. Ked som sa do neho pozrel, tak som zistil, ze sa pozera na konfigurak a tam ma option, ci sa ma
pri starte kompu zapinat alebo nie. Default setting je nie. (Dovod vid sekcia 8) Takze treba ist este
do adresara /etc/default a tam zmenit v subore stunnel4 option ENABLED na 1.
7) SPUSTENIE
Ja ho pouzivam ako demona, takze na tom sa nic nemeni: /etc/init.d/stunnel4 start
Jedina zmena je v tom, ze pri starte si vypyta passphrase pre kluc (aj server aj klient)
8) PAR POZNAMOK NA ZAVER
Nebudem sa tu rozpisovat, aky som z toho nadseny. To je asi evidentne uz z toho, ze
som napisal tento clanok. Chcem len podotknut nasledovne:
- Dajte si bacha ci mate vsetky certifikaty a kluce na spravnych miestach
- Pozor na pustanie stunela s autentifikaciou ako demona. Ak sa rozhodnete napr. upgradnut
stroj a potom ho restartnut, tak si tunel pri boote bude pytat passphrase. To by ani tak
nevadilo do momentu, ked ten upgrade nerobite remote.
- Z toho ako je stunnel urobeny je vidno, ze mozem spravit retaz tunelov.
Dakujem za pozornost. Dufam ze sa vam clanok pacil a najdete si v nom aspon nieco pre seba.
Ja som bol velmi nadseny tym, ze som bol schopny stunnel rozchodit doslova za par minut a
vyriesit tak svoj problem.
Caf,
clanok som si zbezne presiel. Myslim, ze si si dal namahu. Dik, pre mna zaujimave a poucne. Celkom by ma zaujimalo, ci to co si pisal je ozaj iba modelovany pripad, alebo ci si to skutocne takto potreboval riesit, pretoze admini vo vasej sieti takto sleduju trafiku ..
Nie je to modelovi pripad. Je to presne dovod preco som ten tunel potreboval. Isiel som na www.hysteria.sk a po tyzdni mi nesiel net. Ked som sa snazil dozvediet preco, tak mi oznamili ze hysteria je na blackliste a preto ma odpojili.
Na druhu stranu treba podotknut, ze siet o ktorej hovorim patri medzinarodnej organizacii. Nie je to nejaky local ISP a maju svoju policy. Bohuzial pre mna nevedel som, ze prezeranie stranaok podobneho razenia je proti pravidlam. Takze ano, v clanku to bolo pritiahnute za vlasy. Admini si robili len svoju robotu (ten zvysok je moja frustracia zo sveta okolo mna). Admini sory for that, no one is perfect O:)
major_kusanagi
/* no comment */
Edit: Este by som chcel pripomenut, ze dufam, ze nemusim vsetkym vysvetlovat ze IPcky (okrem loopback) su vymyslene.
Dobré. Jediné čo by som vytkol je to strašné zalamovanie riadkov - pri zväčšenom písme je to rozsypaný chaos.
100% s tebou suhlasim. Povodna form abola podstatne krajsia aj s malym "nacrtom", problem je v tom ze CMS na ktorom BH bezi nepozna (zatial) PRE a tak som to nemohol formatovat a nechcelo sa mi to ucesat :-) V kazdom pripade som sa rozpraval s par ludim z BH a vraj PRE sa uz chysta, tak dufam ze to bude.
major_kusanagi
/* no comment */
to nema nic s PRE, odstran si nadbytocne zalamovanie riadkov - vsade - "filtered html" totiz pouziva "Lines and paragraphs break automatically.", tzn. same to vklada BR tam kde das enter
a tiez by nezaskodilo, keby si namiesto tabelovanych (vymedzerovavanych) definicii pouzival tagy dl, dt, dd (namiesto chcenia pouzit PRE, ktore je vhodne na kod, nie na text)
ok, najblizsie si dam pozor. Mea Culpa. Btw. mas pravdu, ze PRE sa pouziva hlavne na kod, ale vyhoda je ta, ze si to mozes naformatovat uplne presne tak ako ty chces. Na druhej strane to moze robit problem browseru pri zmene velkosti pisma/okna. Dalsia vec je vec vkusu. mne sa to cez PRE proste paci no...
major_kusanagi
/* no comment */
presne formatovanie si mozes urcovat, ked si to budes tlacit knizne. web nie je DTP, ze si urcis, ze stranka ma presnu sirku 80 znakov. dynamicke zalamovanie odstavcov sa pouziva implicitne prave preto, ze kazdy ma inac nastavene preferencie na webe a to, co sa tebe paci, moze ineho vytacat do zurivosti, takze pre buducnost nechaj tomu volny spad. nie sme poloartisticky e-zin (zatial), aby umelecky dojem z clanku bol podstatnejsi, nez jeho citatelnost a obsah, ktory poskytuje.
---
Cuchat s nadchou, to je ako sniffovat bez promiscu.
No ale čo keď tí paranoidní a dobre platení administrátori nasadia aplikačný firewall, čo pustí len http/https traffic a len na štandardných portoch? (žiadna modelová situácia, ale krutá realita)
Posledne čo som skúšal tak sa mi to rozchodiť nepodarilo (sw problémy), ale dnešný "google tunnel ssh through https" dal niekoľko zaujímavých výsledkov (corkscrew, gotthard, ...). Možno by nebolo odveci vyskúšať aj takéto scenario :)
Nechapem celkom v com je problem. Pokial nekontrolujes obsah paketu - cize ci naozaj ide o HTTP(S) komunikaciu alebo nie, tak si predsa zvolis port aky chces - napriklad 80, alebo 443.
major_kusanagi
/* no comment */
[quote]aplikačný firewall[/quote]
Každý dobrý BOFH by nasadil takéto riešenie; filtrovať len na základe čísla portu je dosť slabé...
Ináč pozrel som tie softy čo som spomenul vyššie, žiaden sa ani len nesnaží o dáky handshake/KEX. Proste pošlú na port 433 plaintext. A je predsa jasné že firewall pakety obsahujúce v plaintexte PROXY CONNECT pošle rovno do .... Takže hľadanie pokračuje.
no ono pri troche snazenia by sa to dalo oblbnut (minimalne http(s)) podla mna. Pokial tomu fw staci hlavicka HTTP protokolu tak by sa mu mohla dat umelo podsunut, aj ked to uz asi stunnelom neurobis. V kazdom pripade by si vedel spravit riesenie typu netcat + obalenie toho co chces poslat do HTTP s tym ze vo vnutri je gzip dat a na druhej strane by to odchytil druhy netcat a dal by prec http hlavicku, rozzipoval a poslal na spravny port. S tym ze to co je zozipovane by bol cely http paket povodnej komunikacie t.j s http proxy a tvoja umelo dodana hlavicka by bola bez neho.
Nechce sa mi totizto verit, ze by aplikacny fw rozbaloval gzip a kontroloval co je to zac. Pripadne, ze by sa pozeral ci ku kazdej stranke s form zodpoveda tvoj post a pod. Ved to by pri predstave 100 klientov musela byt masina jak svina aby to rozipovavala kontrolovala robila si statistiky a ja neviem co este, ale mozno sa mylim.
major_kusanagi
/* no comment */
Prakticky nemam skusenosti, ale len tak z teoretickeho hladiska programatora (co je mozne a co nie):
V com je kua problem obalit AKYKOLVEK protokol do HTTPS a posielat to tak k nejakemu svojmu proxacu co to preposle dalej? Je tam sice dalsi overhead navyse, ale furt aspon nieco. A kedze je to sifrovane, firemny proxac nema sancu vediet nic o posielanych datach. Urcite take nieco uz musi existovat.
Iste, nieco take uz urcite je, hadam staci pogooglit. Ale:
1. Problem nastane, ked sa zacne niekto hrabat v logoch, a uvidi tam stale rovnaku "podivnu" adresu, s mrte requestami, prave od teba.
2. Dalsi problem je rtt. Na firemnom aplikacnom proxy narasta nielen datovy overhead (co by az tak nemuselo vadit), ale hlavne casovy delay.
3. Ako najvacsi problem by som videl responsiveness z opacnej strany. Priklad: praca s konzolou, pustis napr. praobycajny "ping". Data ti chodia obcas len z druhej strany (zvonka), a kedze https spojenie nie je socks, musis robit polling (vid. pokec.sk alebo icq cez http proxy). Cim menej casto robis polling, tym je odozva dlhsia, cim castejsie, tym mas potom vacsi problem s bodom 1.
V tomto ohlade je ssh tunel (-D) ovela lepsi ako nejake blbe https. A ked uz mas vonku stroj, mozes si ho pustit na porte akom chces.
Ak firma zakazuje vsetky priame connecty (tcp, udp), a na pristup ma cisto http(s) proxy, potom sa este obcas da pouzit pingtunnel.
Ak je firma uplne krepa a nepovoluje vobec nic, riesenie je pichnut si kabel na verejnu siet (resp. nastavit si na switchi trunkovy port az priamo k sebe). Ak tam nikde verejna neprudi, je nacase zmierit sa s tym alebo zmenit zamestnavatela.
Neviem ci mame v praci dost paranoidne riesenie firewallu, ale von sa ide cez HTTP proxy. Hoci web nam nastastie (zatial?) nefiltruju, von sa cez SSH nedostanem. Zda sa ze firewall pusti len porty 80 a 443. Dlho som to riesil skusanim roznych typov tunelov, googlenim, no vacsinou neuspesne. Podarilo sa mi pustit aj shell/scp v prehliadaci, ale to nie je nic na ozajstnu pracu... Medzicasom som nasiel komercne riesenie, ktore ficalo bez zlozitych nastaveni (Barracuda Web Server), ale hladal som nieco sikovnejsie. Nakoniec to vyriesil stunnel, aj ked aj to az po niekolkych neuspesnych pokusoch.
V zasade je nastavenie podobne ako v clanku, len s tym rozdielom, ze v praci mame HTTP Proxy na masine BlbaProxy:8080, takze v prehliadacoch mame ponastavovane BlbaProxy:8080, inak sa na net nedostaneme. S nastavenim z clanku by sa spojenie neporadilo, ale v stunneli od verzie 4.15 je aj moznost definovat proxac. (Dovtedy si tam bolo treba prikompilovat patch.)
Takze do konfiguraku u klienta (moj komp v praci) treba napisat nieco ako:
[https]
accept = 443
connect = BlbaProxy:8080
protocol = connect
protocolHost = MojamMasina-B-NiekdeMimoSiete:443
Potom staci ist cez SSH na localhost:443 a proxac ma v domneni, ze idem na HTTPS stranku https://MojamMasina-B-NiekdeMimoSiete/ pusta na server, kde mam 443 presmerovane na 22 a som vonku.
Dufam ze to niekomu usetri pokusy.:-)
Mohol som sice pouzit ssh -L, ale chcel som mat aj autentifikaciu a mat to permanentne zapnute. Nehovoriac o tom, ze som nechcel klepat skripty a v duchu open source som dufal, ze nieco podobne uz niekto urobil za mna (hlavne elegantne).
SSH odkedy nema autentifikaciu?
Myslim, ze ak mas povolene tcp spojenia (nie iba cisty http/https proxy), je autossh ovela elegantnejsie riesenie.
no ale ja mam iba cisty http/https proxy. Autossh nepoznam, takze som to nemohol vyskusat.
major_kusanagi
/* no comment */
A ako je potom mozne, ze ides cez SSL priamo na port 1337? (Pozor, SSL nie je HTTPS, aj ked sa HTTPS vlastne tvari ako SSL. Rozdiel moze byt najma v max. dlzke spojenia. Tiez moderne all-in-one security gateway riesenia na SSL robia man-in-the-middle, aby mohli filtovat malware vnutri.)
autossh vyskusaj, spoznas :)
pretoze proxy berie/taha data z 127.0.0.1, preto. To je pre proxy "browser"
major_kusanagi
/* no comment */
zjavne si nerozumieme.
su priamo medzi tvojim strojom a 158.100.0.11:1337 routovane pakety, alebo nie?
nie (ak pod tym"moj stroj" myslis to kde bezi apache)
edit: Teda takto, aby som bol uplne presny. Ak je routovanie medzi tvojou normalnou sietovkou a loopbackom tak potom ano. Ale fyzicky je to ta ista masina s 1 sietovkou.
major_kusanagi
/* no comment */
mam na mysli linku medzi A a B (cize tam, kde mas SSL spojenie, teda ak som to z toho textu spravne pochopil)
ak to mienime dlhsie rozoberat, podme radsej si to vysvetlit na irc a potom sem postneme, k comu sme dospeli
edit: teda dospeli sme k tomu, ze pakety medzi A a B prudia sice mozno s kontrolou, ale bez blokovania, normalne routovane. teda je okrem stunnel+apache ako proxy mozne pouzit aj klasicke:
ssh -D 1337 franta@158.100.0.11
A ja este dodavam, ze ti, co chcu vediet ako rozbehat stunnel a nechce sa im hladat po nete si v clanku dufam najdu to co potrebuju. To k comu sme s matejom dospeli je to ze obsah clanku - jakozto navodu na rozbehanie s tunela - je OK ale modelova situcia je na kokot, pretoze sa to dalo riesit podstatne jednoduchsie. Nic to ale nemeni na fakte ze ako clanok o rozbehani stunnela-a s certifikatmi to ujde.
major_kusanagi
/* no comment */