Tunnel over HTTPS
W moim miejscu pracy blokowanie ruchu / firewall staje się coraz gorsze. Nie mogę połączyć się z moją maszyną domową na porcie 22, a brak dostępu ssh mnie zasmuca. Wcześniej byłem w stanie użyć SSH, przenosząc go na port 5050, ale myślę, że niektóre ostatnie filtry traktują teraz ten ruch jako IM i przekierowują go przez inny proxy, może. To moje najlepsze przypuszczenie; w każdym razie moje połączenia ssh kończą się, zanim będę mógł się zalogować.
Ostatnio używam Ajaxterm przez HTTPS, ponieważ port 443 jest nadal niezaspokojony, ale jest to dalekie od ideału. (Beznadziejna emulacja terminala, brak przekierowania portów, moja przeglądarka wycieka pamięć w niesamowitym tempie...) Próbowałem skonfigurować mod_proxy_connect Na górze mod_ssl, z pomysłem, że mogę wysłać CONNECT localhost:22 HTTP/1.1 żądanie za pośrednictwem HTTPS, a potem będę gotowy. Niestety, to wydaje się nie działać; połączenie HTTPS działa, aż skończę wysyłać moją prośbę; następnie SSL craps out. Wygląda na to, że mod_proxy_connect przejmuje całe połączenie, zamiast kontynuować Przełącz mod_ssl, myląc heck z klientem HTTPS.
- zostawianie takiego wielkiego otwartego proxy po prostu śmierdzi
- duży, gruby otwarty serwer proxy nie jest również dobry dla HTTPS, ale z wymaganym uwierzytelnieniem czuje się dobrze]}
- HTTP przechodzi przez proxy -- nie jestem zbyt zaniepokojony tym, że mój ruch jest wąchany, ponieważ to ssh będzie "zwykły tekst" przez tunel - ale jest o wiele bardziej prawdopodobny do zniekształcenia niż HTTPS, który zasadniczo nie może być proxy
Wymagania:
- Nie mogę po prostu umieścić serwera ssh na porcie 443, ponieważ nie będę już mógł obsługiwać stron przez HTTPS)
- Mam lub mogę napisać prosty klient port Forwarder, który działa pod Windows (lub Cygwin)
Edit
DAG: Tunelowanie SSH przez HTTP (S) zostało mi wskazane, ale to nie pomaga: na końcu artykułu wspominają o błędzie Bug 29744 - CONNECT nie działa nad istniejącym połączeniem SSL zapobiegając tunelowaniu przez HTTPS, dokładnie na jaki problem się natknąłem. W tym momencie prawdopodobnie patrzę na jakiś skrypt CGI, ale nie chcę wymieniać tego jako wymogu, jeśli dostępne są lepsze rozwiązania.
13 answers
Dowiedz się, dlaczego firma prowadzi tak restrykcyjną politykę. To może być dobry powód.
Jeśli nadal okaże się, że chcesz ominąć zasady, Możesz napisać mały serwer proxy, który będzie nasłuchiwał na twoim serwerze na porcie 443, a następnie, w zależności od żądania, przekaże ruch do twojego serwera www lub do demona SSH. Są jednak dwa haczyki.
Aby określić, czy jest to żądanie HTTPS, czy żądanie SSH, musisz spróbować odczytać niektóre dane za pomocą (small) timeout, dzieje się tak dlatego, że TLS/SSL handshake zaczyna się od wysłania przez Klienta niektórych danych, podczas gdy SSH handshake zaczyna się od wysłania przez serwer niektórych danych. Limit czasu musi być wystarczająco duży, aby opóźnienia w dostarczaniu początkowych danych od klienta w uścisku dłoni TLS/SSL, więc spowoduje to wolniejsze nawiązywanie połączeń SSH.
Jeśli serwer proxy HTTP w Twojej firmie jest inteligentny, to faktycznie podsłuchuje oczekiwany "handshake" TLS / SSL, kiedy
CONNECTwejdziesz na port 443, a gdy wykrywa, że nie jest to uścisk dłoni TLS/SSL, może zakończyć próbę połączenia SSH. Aby temu zaradzić, możesz zawinąć demona SSH w tunel TLS/SSL (np.stunnel), ale będziesz musiał rozróżnić żądania na podstawie wersji TLS / SSL w żądaniu klienta, aby określić, czy przekierować połączenie TLS / SSL do serwera www, czy do tunelowanego TLS / SSL demona SSH.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-10-08 23:35:58
Powinieneś być w stanie używać iptables do przekazywania ruchu ssh z Twoich maszyn roboczych do ssh, podczas gdy wszystkie inne maszyny podłączające się do twojego serwera domowego na porcie 443 otrzymują serwer Apache.
Wypróbuj taką zasadę:
iptables -t nat -A PREROUTING -p tcp -s 111.111.111.111 --dport 433 -j REDIRECT --to-port 22
Gdzie 111.111.111.111 to adres ip twojego komputera biurowego.
To wszystko zakłada, że używasz Linuksa > = 2.4, który powinieneś już być. Jest na rynku od prawie dekady.
Dokumentacja dla iptables jest na http://www.netfilter.org .
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-10-08 23:57:41
Skonfiguruj serwer OpenVPN 2.1 w domu, użyj portu 443 (jeśli skonfigurujesz domową usługę HTTPS na porcie 443, Uruchom opcję port-share OpenVPN, aby obsługiwać zarówno transakcje OpenVPN, jak i HTTPS na porcie 443; ta funkcja jest dostępna tylko dla Systemów innych niż Windows)
Następnie skonfiguruj klienta OpenVPN na swoim laptopie w trybie road-warrior, aby uzyskać dostęp do serwera OpenVPN W Domu. Będziesz mógł zadzwonić do domu lub gdziekolwiek chcesz w bezpiecznej sieci VPN, którą utworzyłeś za pomocą OpenVPN. Nie jest już wymagane do korzystania z SSH w tym celu.
Co powiesz na użycie 2 adresów IP na komputerze?
Bind apache / https na jednym IP_1: 443 i twój sshd na drugim IP_2: 443?
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-10-08 08:51:42
Mógłbyś ustawić pośrednika?
Uruchom małą / darmową / tanią instancję w chmurze nasłuchującej na 443 dla SSH, a następnie przenieś tę instancję w chmurze do skrzynki głównej na ulubionym porcie-22 lub cokolwiek innego.
To na pewno doda trochę latencji, ale rozwiązuje problem pozostawienia oryginalnej konfiguracji domowej nienaruszonej.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-03-01 23:11:36
Myślę, że będziesz musiał znaleźć port, którego obecnie nie używasz, na którym możesz wyjść i posłuchać. 443 to oczywisty kandydat, ale mówisz, że to niemożliwe. Co z mail (25, 110, 143), telnet (23), ftp (21), DNS (53), a nawet whois (43)?
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-10-08 04:52:12
Naprawdę mi przykro, że Jestem tu adwokatem diabła, ale jeśli blokują porty w twojej pracy, prawdopodobnie dlatego, że nie chcą, aby ludzie naruszali bezpieczeństwo.
Teraz, jeśli masz pozwolenie na otwarcie tunelu od swojego szefa, to w porządku, ale jeśli coś się stanie, cokolwiek, i zorientują się, że masz tunel, mogę cię prawie zapewnić, staniesz się kozłem ofiarnym. Więc na Twoim miejscu nie otwierałbym tuneli w pracy, jeśli ustawiają przeciwko temu firewalle.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-10-08 05:17:14
Proxy tunnel may be your answer
Http://proxytunnel.sourceforge.net/
Powiedzmy, że mój serwer ssh to host.domena.tld i moje prace serwer proxy jest 10.2.4.37
Dodałbym to do mojej lokalnej konfiguracji ssh
Host host.domena.tld ProxyCommand / usr / local/bin / proxytunnel-q-P 10.2.4.37: 3128-d %h:%p ProtocolKeepAlives 30
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-10-08 07:38:48
Ponieważ apache nie ma żadnego problemu z CONNECT, gdy nie ma SSL, wyłączam funkcje SSL i używam stunnel do obsługi wersji https mojej strony. Nie wymaga to żadnej rekompilacji i pozwala witrynie normalnie obsługiwać https. Jak dotąd najczystsze obejście, jakie znam.
Zobacz http://chm.duquesne.free.fr/blog/?p=281 Po szczegóły.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-07-17 11:29:01
Musi działać przez port 443, bez zakłócania ruchu HTTPS (tj. nie mogę po prostu umieścić serwera ssh na porcie 443, ponieważ nie będę mógł już obsługiwać stron przez HTTPS)
Czy można powiązać serwer HTTPS z innym portem? W zależności od tego, do czego jest używany, możesz nawet obejść problem braku możliwości bezpośredniego dostępu do niego z pracy, po prostu SSHing home, A następnie używając lynx stamtąd.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-10-08 23:47:41
Więc spróbuj proxifier (- obsługuje serwer proxy HTTP)!
Udało mi się ominąć firewall mojej firmy za pomocą następującego projektu za pośrednictwem AjaxTerm, działa dla mnie.
PC w sieci firmowej -- > proxy firmy przez https -- > INTERNET -- > My home Apache reverse proxy server on SSL + .htpasswd protection --> AjaxTerm Server (stąd mogę SSH na inne serwery ).
Wciąż nie jest to idealny świat... byłoby dobrze, gdybym mógł tunelować do mojej sieci domowej za pośrednictwem HTTPS.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-12-03 04:18:16