Od Redakcji: artykuł pochodzi z listopadowego wydania Linux Magazine. Kompletną listę artykułów możecie znaleźć na stronach miesięcznika.
Urodziłem się na wsi, więc przekłuwanie ciała nie było mi obce – dotyczyło jednak byków, nie ludzi; miało to miejsce na długo, zanim ludzie zaczęli zniekształcać sobie twarze i drugorzędne cechy płciowe kawałkami metalu. W międzyczasie (mniej więcej w okolicach wydania Suse 5.3) popularność zyskało przekłuwanie zapór sieciowych – sztuczki z konfiguracją, dzięki którym można przekierować dowolny ruch TCP przez istniejącą dziurę, taką jak HTTP(S).
Httptunnel [1], którego będę używał na wakacjach, pochodzi właśnie z tamtego okresu. Choć dzisiejszy administratorzy mogą je zastąpić kilkoma linijkami iptables, jest ono znacznie bardziej przyjazne użytkownikowi i na większości dystrybucji działa od razu. Po około dwunastu godzinach drogi dotrę do Oksytanii [2], krainy pełnej serdecznych ludzi, pięknych krajobrazów i kawiarenek Internetowych, w których „Internet” jest synonimem „HTTP”. Planuję jednak opublikować na IRC-u wyniki odbywającego się w właśnie w Oksytanii międzynarodowego konkursu w rzucie meduzą, potrzebuję więc SSH.
Httptunnel składa się z klienta i z maszyny docelowej. klient, HTC, nasłuchuje na dowolnym porcie – jeśli nie mamy uprawnień administratora, musi to być port powyżej 1024. Klient osadza połączenia przychodzące w HTTP i przesyła je do celu – na port otwarty na zaporze sieciowej. Przykładowo, jeśli chcemy skorzystać z portu 443, użyjemy polecenia:
htc -w -F 4711 kintyre.kuehnast.com:443
Podczas testów warto użyć parametru -w, który zapobiega przejściu procesu w tło. Po prawidłowym skonfigurowaniu wszystkiego opuszczamy ten parametr, proces będzie działał jako demon. Opcja -F oznacza przekazuj (od ang. forward), po czym następuje źródło i cel do przekazywania. Ponieważ źródłem jest port na maszynie lokalnej, nie ma potrzeby podawać nazwy hosta, wystarczy sam port. Celem może być jakikolwiek adres IP lub nazwa hosta, jak widzimy wyżej.
Tył na przód
Z kolei na serwerze wszystko powinno być skonfigurowane „tył na przód”. Komponent serwerowy HTS przyjmuje połączenia przychodzące na porcie 443, usuwa warstwę HTTP i przekazuje je na port docelowy. W przykładzie poniżej jest to port 22 – do logowania przez SSH:
hts -w -F localhost:22 443
Choć może się to wydawać nielogiczne, musimy najpierw skonfigurować port 22, a następnie port używany przez HTS do nasłuchiwania na połączenia przychodzące. Chcąc wypróbować tę konfigurację, otwieramy połączenie SSH do localhosta na porcie 4711:
ssh -p 4711 charly@localhost
Możemy teraz zalogować się na serwer (Rysunek 1). Zanim posypią się protesty – konkurs w rzucie meduzą to oczywiście żart, ale i tak można mi zazdrościć: właściciele winnic w Langwedocji przerzucili się z przemysłowej produkcji alkoholu na wina, i to naprawdę dobrej jakości.
Rysunek 1: Charly na wakacjach, przebijający się przez zaporę sieciową.
INFO
- [1] Httptunnel: http://www.nocrew.org/software/httptunnel.html
- [2] Oksytania: http://pl.wikipedia.org/wiki/Oksytania http://en.wikipedia.org/wiki/Occitania
Coby nie kombinowac z portami i co dziala nawet jak hotel w dalekiej Oksytanii pozwala tylko na pingi:
http://freshmeat.net/projects/ptunnel/
Bez sensu, ładu i składu artykuł. Jakieś udziwnione analogie. Już myślałem, że dowiem się czegoś ciekawego, co pozwoli mi zgłębić temat tunelowania, a tu zanim się zaczęło to się skończyło.
Mało ciekawy poradnik, dowiedziałem się z niego że jest takie coś jak httptunnel i nic poza tym. Mógłbyś to lepiej opisać.