Server VPN sur Google Compute Moteur avec OpenVPN
J'essaie d'utiliser Google Compute Server comme serveur VPN pour tout mon trafic (je vis en Russie, nous avons des problèmes avec la censure ici).
Il y a un mini-tutoriel sur VPN sur GCE , mais il s'agit d'un réseau entre 2 serveurs à l'intérieur du GCE et non avec OpenVPN.
J'ai fait toutes les étapes d'un autre tutoriel, à propos de configurer VPN avec OpenVPN sur Debian , je peux vous connecter à VPN à partir du client, mais je ne peux pas ouvrir les connexions (ne peut même pas ping google) . Sur le serveur, je peux ping et télécharger tout comme d'habitude.
J'ai VPN sur Linode avec la même configuration et ça marche bien. Donc, la question est dans les règles de routage du réseau GCE ou de pare-feu.
J'ai essayé beaucoup de variantes mais rien ne fonctionne. S'il vous plaît, regardez les paramètres et dites-moi que dois-je changer.
// Les lignes de configuration supprimées, car la question est résolue //
Tout d'abord, merci à @shivox pour son Réponse .
Et voici la marche rapide:
- Je vous recommande de créer un réseau supplémentaire (voir "Networks" onglet "). Dans les préférences de réseau, ajoutez des règles permettant: TCP: 22 (Sinon exist), TCP: 9700, TCP: 17619 . 17619 Voici une variable - changez-la à n'importe quel port que vous aimez (la plage est 9075-65534). Vous avez seulement besoin de 3 règles et 2 itinéraires par défaut, rien d'autre.
- Accédez à "Créer une instance de moteur Compute", cliquez sur "Afficher les options avancées", autorisez le renvoi des ports, sélectionnez Emplacement du serveur.
- Maintenant (lorsque vous avez sélectionné l'emplacement), ajoutez une adresse IP statique au serveur.
- Sélectionnez Ubuntu 14.04 image (exactement cette version).
- Créer une instance
- Connectez via SSH (moyen le plus facile - Utilisez l'outil dans le navigateur à partir du panneau GCE)
Sudo suapt-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- Dans le navigateur Open
https://instance_ip:9700 - Sur la question à propos de DB, cliquez sur "Enregistrer"
- Dans la fenêtre de connexion, utilisez
pritunlcomme nom d'utilisateur et mot de passe - Maintenant, changez le nom d'utilisateur et le mot de passe de l'utilisateur admin
- Ajouter une organisation, puis 2 utilisateurs (pour ordinateur de bureau et mobile)
- Cliquez sur "Ajouter le serveur" dans l'onglet "Serveurs"
- Utilisez le numéro de port de la première étape ( 17619 à titre d'exemple) et protocole TCP.
- Joindre une organisation au serveur
- Serveur de démarrage
- Dans l'onglet "Utilisateurs" Téléchargez des touches pour les deux utilisateurs (archives de goudron avec les fichiers OVPN à l'intérieur).
J'utilise la viscosité pour OS X et OpenVPN Connect pour iOS en tant que clients. En viscosité, activez l'option "Envoyer tout le trafic sur la connexion VPN" dans l'onglet "Networking".
Vous pouvez résoudre le problème de ne pas pouvoir naviguer sur le Web à travers le VPN malgré de la possibilité de ping, de traceroute ... par l'une des deux manières suivantes:
Tout d'abord, vous pouvez utiliser TCP Protocol au lieu d'UDP, en modifiant "Proto UDP" sur "proto TCP" dans les fichiers Conf du client et du serveur.
Deuxièmement, vous pouvez utiliser le périphérique TAP au lieu de la TUN, en modifiant 'Dev Tun' sur "Dev Tap" dans les fichiers Conf du client et du serveur.
Je ne sais pas quel est le problème, il semble que ce soit un problème de la fin de Google.
N'oubliez pas que Google VPC est de laisser tomber des paquets qui ont source_ip Autre une adresse IP interne d'A VM après une adresse IP externe.
Ce doc - https://cloud.google.com/compute/docs/vpc/advanced-vpc états:
Le réseau VPC réécrit l'en-tête IP pour déclarer l'adresse IP externe de l'instance comme source. Si l'instance n'a pas d'adresse IP externe, l'appel n'est pas autorisé et le réseau VPC dépose le paquet sans informer l'expéditeur.
Donc, si votre openvpn vient de renvoyer des paquets de l'autre réseau, les paquets à internes publiques seront supprimés comme source_ip ne correspond à aucune adresse interne interne de VM existante. Pour cette raison, vous devez avoir besoin de NAT== Les paquets quittant votre réseau local, par exemple sur votre nœud VPN.
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- 192.168.0.0/16 !192.168.0.0/16
"Pritunl" mentionné dans la réponse oz_ fonctionne, car il configure le NAT automatiquement.
Ce n'est pas vraiment une réponse, mais le site ne m'a pas permis de l'ajouter comme un commentaire à votre question.
Néanmoins, j'ai presque la même configuration que vous avez décrite ci-dessus (je n'ai pas configuré le DNSMAQ sur le serveur dur)
Malheureusement, le VPN ne fonctionne pas comme prévu. Je peux résoudre une adresse, ping quelques hôtes Internet et même faire une trace complète lorsqu'elle est connectée au VPN. Cependant, lorsque j'ouvre le navigateur et accédez à un site, la connexion est vraiment lente. Je ne sais pas ce qui peut affecter la connexion, mais c'est vraiment un problème étrange.
Peut-être que quelqu'un de Google peut nous aider à savoir ce qui se passe.
PS 1. Comme d'autres personnes ont suggéré auparavant, pouvez-vous vérifier si la transmission IP est activée? Pour moi, le seul moyen d'assurer la valeur pour net.ipv4.ip_forward a été correctement rétabli après qu'un redémarrage était après avoir utilisé une règle personnalisée sur /etc/sysctl.d
Par exemple, vous pouvez ajouter la règle à l'aide de la commande suivante:
$ Sudo echo "net.ipv4.ip_forward = 1" > /etc/sysctl.d/90-useroverrides.conf
PS 2. Si l'avenir fonctionne pour vous, pouvez-vous tester une trace d'itinéraire vers un hôte externe lorsqu'il est connecté au VPN ?. La sortie que j'ai obtenue quand je fais cela est un peu étrange (pourquoi il y a plusieurs sautes sur la même adresse 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. La seule chose qui semble fonctionner correctement est que le VPN utilise l'adresse IP externe de mon hôte pour accéder à Internet.
$ 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>
Éditer /etc/sysctl.conf Par mot notation #net.ipv4.ip_forward=1
Cela devrait permettre à OpenVPN de diriger votre trafic.
Vous avez besoin de transfert IP activé pour votre VM instance dans Google Cloud, sinon les paquets n'atteint pas votre VM. Note, c'est séparé de net.ipv4.ip_forward = 1 Vous pouvez installer dans votre VM.
Le transfert IP ne peut être défini qu'une fois avant de créer un VM et ne peut pas être modifié par la suite. Pour l'activer pour un nouveau VM Cliquez sur Management, security, disks, networking, sole tenancy: 
Ensuite, dans Networking onglet Cliquez sur Network Interface et définir le transfert IP sur ON:
Vous devez ajouter une règle qui permettent la circulation pour OpenVPN lui-même:
iptables -A INPUT -p udp --dport 1194 -j ACCEPT