OpenVPN w sieci kampusowej?

Mam swój router w domu z uruchomionym Tomato USB z OpenVPN działającym na porcie 1194. Sieć kampusu ma publicznie otwarty port 80 i jestem prawie pewien, że tworzą kształtowanie ruchu i filtrowanie treści. Czy jedyną opcją jest tutaj zmiana portu OpenVPN na Tomato USB na port 80 i połączenie z kampusu w obrębie klienta z portu 80?

— Aaron
źródło

Możesz jednak spróbować, na podstawie tego, co powiedziałeś, prawdopodobnie sprawdzają pakiety HTTP, których ruch VPN NIE jest.

— Vick Vega

Dzięki, myślę, że na pewno spróbuję w tym tygodniu.

— Aaron

czy twój ISP ma otwarty port 80? wielu dostawców usług internetowych blokuje to

— Journeyman Geek

Odpowiedzi:

Brak reklamy, ale w moim kampusie usługa SwissVPN (która uruchamia OpenVPN) działa dobrze, ponieważ faceci skonfigurowali serwer OpenVPN do akceptowania połączeń na porcie 443 (często używanym dla HTTPS), a ponieważ gniazdo OpenVPN ma warstwę SSL, do głupiej ściany mój kampus to tak, jakbym robił HTTPS z jakimś serwerem.

HTTPS nie odróżnia się od niczego innego działającego na gnieździe wymuszonym przez SSL. Niektóre słabe firewalle zakładają SSL na 443 == HTTPS.

Wypróbuj (ustawienie własnego serwera VPN na porcie 443 lub spróbuj darmowego testu SwissVPN), może to działać.

Jeśli to nie działa i masz dużo wolnego czasu, możesz spróbować znaleźć narzędzie do tunelowania HTTP, ale nie jest czyste jak OpenVPN.

— gd1
źródło

@Aaron Port 443 nie jest otwarty? Co robią, gdy użytkownicy potrzebują dostępu do stron HTTPS?

— Kromey

Jestem trochę zdezorientowany twoimi odpowiedziami, albo masz problem z koncepcją „otwartych portów”. To oczywiste, że nie możesz akceptować połączeń przychodzących z sieci twojego kampusu bez tunelu, do dowolnego swojego portu. Ale możesz ustanowić połączenia wychodzące, do trochę porty innych serwerów w Internecie. To nie jest twój 443 port otwarty, to tylko: „połączenia wychodzące do portu 443 innych hostów są dozwolone”. To jest inne! Co więcej, jeśli twój router domowy nie akceptuje połączeń przychodzących, problem nie ma rozwiązania, chyba że użyjesz trzeciego węzła.

— gd1

Jako serwer potrzebny jest dostęp przychodzący. Jako klient musisz wykonać połączenie wychodzące do określonego portu prawidłowo skonfigurowanego serwera OpenVPN. To klasyczny projekt klient-serwer. Jeśli ten port to 443, OpenVPN może naśladować HTTPS, będąc prawie niewykrywalnym przez wiele korporacyjnych zapór ogniowych. Niektóre inne zapory ogniowe są bardziej sprytne i przełamią połączenie między klientem a serwerem, opierając się na fakcie, że „żadne połączenie HTTPS nie jest czasami bezczynne przez 10 minut!”, Więc będziesz musiał ponownie łączyć się co n minut lub wybrać inne rozwiązanie (Miałem uczciwe wyniki z tunelowaniem „segmentowanym” HTTP - powoli)

— gd1

Wiem, że minęło trochę czasu, ale zapomniałem zaznaczyć tę odpowiedź jako najlepszą odpowiedź. Chciałem również poinformować wszystkich, że musiałem zmienić port, z którego korzystał OpenVPN na 443. Po wykonaniu tego wszystko działało dobrze.

— Aaron

Dobrze słyszeć. SSL na porcie 443 jest główną wadą każdej korporacyjnej zapory ogniowej (tak jak w przypadku połączeń wychodzących)

— gd1

Osobiście wolę uruchamiać WinSSHD na moim komputerze na kampusie (na porcie 80 zamiast 22), a następnie otwierać tunel z zewnątrz za pomocą klienta Tunnelier. Następnie mapuj porty zgodnie z potrzebami, aby przejść przez tunel. To nie jest VPN, więc musisz ręcznie mapować porty ... rzeczy nie są szeroko otwarte, jak na połączeniu VPN. Pomysł na wypadek, gdyby Twoja metoda VPN nie działała.

— djangofan
źródło

Dzięki za twój pomysł. W rzeczywistości udało mi się uruchomić OpenVPN. Główny problem polegał na tym, że moja szkoła blokuje tak wiele portów wychodzących, a jeden z nich przypadł do 1194. Zmiana serwera na routerze, aby nasłuchiwał na porcie 443 i połączenie przez port 443, zadziałało.

— Aaron

Nie łączysz się przez port 443, prawdopodobnie używasz losowego portu ... Serwer nasłuchuje na 443 :)

— gd1

Szybkie pytanie. Powiedzmy, że łączę się z serwerem SSH na jakimś serwerze, na którym jest uruchomiony na porcie 22. Kiedy próbuję połączyć się z serwerem SSH działającym na moim VPS lub nawet próbując połączyć się z Github (z kampusu), jest zablokowany. Teraz zmieniłem serwer SSH VPS, aby słuchał na zupełnie innym porcie, który pozwala mi łączyć się z kampusem. Jeśli łączę się z tym innym portem na moim VPS, ale najprawdopodobniej używam losowego portu na moim komputerze w kampusie dla połączenia wychodzącego, co zatrzymałoby wszystkie połączenia wychodzące do portu 22? Czy zapory ogniowe mogą temu zapobiec?

— Aaron

Większość sieci jest skonfigurowana tak, aby zezwalać na porty wychodzące. Na przykład przeglądarki internetowe używają zakresu 3000 do zwracania połączeń. Możliwe jest jednak, że zapory mogą blokować ruch na podstawie typu protokołu, a nie portu.

— djangofan