Serwer VPN w Google Compute Engine z OpenVPN

Próbuję używać serwera Google Compute Engine jako serwera VPN dla całego mojego ruchu (mieszkam w Rosji, mamy tutaj pewne problemy z cenzurą).

Istnieje mini-poradnik na temat VPN na GCE , ale dotyczy sieci między 2 serwerami wewnątrz GCE, a nie z OpenVPN.

Zrobiłem wszystkie kroki z innego samouczka, dotyczącego konfiguracji VPN z OpenVPN na Debianie , mogę połączyć się z VPN z klienta, ale potem nie mogę otworzyć połączeń (nie mogę nawet pingować google). Na serwerze mogę pingować i pobierać wszystko jak zwykle.

Mam VPN na Linode z tą samą konfiguracją i działa dobrze. Problem dotyczy reguł routingu sieciowego lub zapory sieciowej GCE.

Próbowałem wielu wariantów, ale nic nie działa. Proszę spojrzeć na ustawienia i powiedzieć, co powinienem zmienić.

// usunięto wiersze konfiguracji, ponieważ problem został rozwiązany //

Przede wszystkim dziękuję @Shivox za odpowiedź .

A oto krótkie instrukcje:

• Polecam utworzyć dodatkową sieć (zobacz zakładkę „Sieci” "), ustawienia sieci, dodaj reguły pozwalające na: TCP: 22 (jeśli nie istnieje), TCP: 9700, TCP. 17.619 . 17.619 tutaj jest zmienna - zmienić na dowolny port, który lubisz (zasięg to 9075-65534). Potrzebujesz tylko 3 reguł i 2 domyślnych tras, nic więcej.
• Przejdź do „Utwórz instancję silnika obliczeniowego”, kliknij „Pokaż opcje zaawansowane”, zezwól na przekierowanie portów, wybierz lokalizację serwera.
• Teraz (po wybraniu lokalizacji) dodaj statyczny adres IP do serwera.
• Wybierz obraz Ubuntu 14.04 (dokładnie ta wersja).
• Utwórz instancję
• Połącz przez SSH (najłatwiejszy sposób - użyj narzędzia przeglądarki z panelu GCE)
• sudo su
• apt-key update && apt-get update && apt-get -y upgrade && apt-get -y install python-software-properties && apt-get -y install software-properties-common && add-apt-repository -y ppa:pritunl && apt-get update && apt-get -y install pritunl
• W przeglądarce otwórz https://instance_ip:9700
• W pytaniu o DB kliknij „Zapisz”
• W oknie logowania użyj pritunljako nazwy użytkownika i hasła
• Teraz zmień nazwę użytkownika i hasło administratora
• Dodaj organizację, a następnie 2 użytkowników (na komputery i urządzenia mobilne)
• Kliknij „Dodaj serwer” na karcie „Serwery”
• Użyj numeru portu z pierwszego kroku ( 17619 jako przykład) i protokołu TCP.
• Dołącz organizację do serwera
• Uruchom serwer
• W zakładce „Użytkownicy” pobierz klucze dla obu użytkowników (archiwa tar z plikami ovpn w środku).

Używam Viscosity dla OS X i OpenVPN Connect dla iOS jako klientów. W opcji Lepkość włącz opcję „Wyślij cały ruch przez połączenie VPN” na karcie „Sieć”.

Możesz rozwiązać problem niemożności przeglądania sieci przez VPN, mimo że możesz pingować, traceroute ... jednym z dwóch poniższych sposobów:

Po pierwsze, możesz użyć protokołu TCP zamiast UDP, zmieniając „proto udp” na „proto tcp” zarówno w plikach conf klienta, jak i serwera.

Po drugie, możesz użyć urządzenia tap zamiast tun, zmieniając „dev tun” na „dev tap” w plikach conf klienta i serwera.

Nie jestem pewien, na czym polega problem, wydaje się, że jest to problem od końca Google.

Pamiętaj, że Google VPC upuszcza pakiety, które mają source_ipinne niż wewnętrzny adres IP maszyny wirtualnej mającej zewnętrzny adres IP.

Ten dokument https://cloud.google.com/compute/docs/vpc/advanced-vpc stwierdza:

Sieć VPC przepisuje nagłówek IP, aby zadeklarować zewnętrzny adres IP instancji jako źródło. Jeśli instancja nie ma zewnętrznego adresu IP, połączenie jest niedozwolone, a sieć VPC odrzuca pakiet bez informowania nadawcy.

Więc jeśli twoja openVPN po prostu przesyła pakiety z innej sieci, wówczas pakiety do publicznego wewnętrznego zostaną odrzucone, ponieważ source_ipnie są zgodne z wewnętrznym IP istniejącej maszyny wirtualnej. Z tego powodu musisz NAT przesłać pakiety wychodzące z sieci lokalnej, np. W węźle VPN.

Chain POSTROUTING (policy ACCEPT)
target      prot opt source              destination         
MASQUERADE  all  --  192.168.0.0/16      !192.168.0.0/16

„Pritunl” wspomniany w odpowiedzi OZ_ działa, ponieważ automatycznie konfiguruje NAT.

To nie jest tak naprawdę odpowiedź, ale strona nie pozwoliła mi dodać go jako komentarza do twojego pytania.

Niemniej jednak mam prawie taką samą konfigurację, jak opisana powyżej (nie skonfigurowałem dnsmaq na serwerze trudnym)

Niestety VPN nie działa zgodnie z oczekiwaniami. Mogę rozwiązać adres, wysłać polecenie ping do niektórych hostów internetowych, a nawet dokonać pełnego śledzenia podczas połączenia z VPN. Jednak po otwarciu przeglądarki i przejściu do witryny połączenie jest naprawdę wolne. Nie wiem, co może mieć wpływ na połączenie, ale to naprawdę dziwny problem.

Może ktoś z Google może pomóc nam wiedzieć, co się dzieje.

PS 1. Jak sugerowały wcześniej inne osoby, czy możesz sprawdzić, czy przekazywanie adresów IP jest włączone? Dla mnie jedynym sposobem na prawidłowe przywrócenie wartości net.ipv4.ip_forward po ponownym uruchomieniu było użycie niestandardowej reguły na /etc/sysctl.d

Na przykład możesz dodać regułę za pomocą następującego polecenia:

$ sudo echo "net.ipv4.ip_forward = 1" > /etc/sysctl.d/90-useroverrides.conf

PS 2. Jeśli przekazywanie działa dla Ciebie, czy możesz przetestować trasę śledzenia do hosta zewnętrznego, gdy jest podłączony do sieci VPN ?. Dane wyjściowe, które otrzymałem, gdy to robię, są nieco dziwne (dlaczego istnieje wiele przeskoków w tym samym adresie IP ????):

$ sudo traceroute www.yahoo.com -T -p 80 -N 1 -z 0.5 -q 1
traceroute to www.yahoo.com (98.139.183.24), 30 hops max, 60 byte packets
 1  209.85.241.26 (209.85.241.26)  0.764 ms
 2  209.85.241.34 (209.85.241.34)  0.668 ms
 3  209.85.241.26 (209.85.241.26)  0.966 ms
 4  209.85.241.36 (209.85.241.36)  0.702 ms
 5  209.85.241.28 (209.85.241.28)  0.865 ms
 6  209.85.241.36 (209.85.241.36)  0.642 ms
 7  209.85.241.26 (209.85.241.26)  0.921 ms
 8  209.85.241.28 (209.85.241.28)  18.837 ms
 9  72.14.238.107 (72.14.238.107)  13.378 ms
10  72.14.237.131 (72.14.237.131)  38.275 ms
11  209.85.254.131 (209.85.254.131)  13.349 ms
12  *
13  ae-8.pat1.bfz.yahoo.com (216.115.101.231)  44.903 ms
14  ae-4.msr1.bf1.yahoo.com (216.115.100.25)  45.323 ms
15  xe-10-3-1.clr1-a-gdc.bf1.yahoo.com (98.139.232.101)  47.382 ms
16  et18-25.fab6-1-sat.bf1.yahoo.com (98.139.128.103)  45.793 ms
17  po-13.bas1-7-prd.bf1.yahoo.com (98.139.129.209)  41.143 ms
18  ir2.fp.vip.bf1.yahoo.com (98.139.183.24)  42.451 ms

PS 3. Jedyne, co wydaje się działać poprawnie, to VPN korzysta z zewnętrznego adresu IP mojego hosta w celu uzyskania dostępu do Internetu

$ sudo curl --interface tun0 checkip.dyndns.org
<html><head><title>Current IP Check</title></head><body>Current IP Address: 107.178.XXX.XXX</body></html>

Edytuj /etc/sysctl.confprzez odkomentowanie#net.ipv4.ip_forward=1

To powinno pozwolić OpenVPN na kierowanie ruchem.

Musisz włączyć przekazywanie IP dla instancji maszyny wirtualnej w chmurze Google, w przeciwnym razie pakiety nie dotrą do maszyny wirtualnej. Uwaga: jest to oddzielne od net.ipv4.ip_forward = 1tego, które można ustawić na maszynie wirtualnej.

Przekazywanie IP można ustawić tylko raz przed utworzeniem maszyny wirtualnej i nie można go później modyfikować. Aby włączyć to dla nowej maszyny wirtualnej, kliknij Management, security, disks, networking, sole tenancy:

Następnie w Networkingzakładce kliknij Network Interfacei ustaw Przekazywanie IP na ON:

Musisz dodać regułę, która zezwala na ruch dla samego OpenVPN:

iptables -A INPUT -p udp --dport 1194 -j ACCEPT

O sieci.

1) Włącz cały ruch z podsieci OpenVPN (np. 10.8.0.0/24) w konsoli

2) Zdecydowanie zalecam dodanie Masquerade do swojej sieci

firewall-cmd --zone=trusted --add-masquerade --permanent
firewall-cmd --reload-all

3) Nie zapomnij włączyć routingu pakietów w jądrze

raz

 echo 1 > /proc/sys/net/ipv4/ip_forward

b) na zawsze w /etc/sysctl.conf:

 net.ipv4.ip_forward = 1