Добрый вечер,
У меня проблема с установкой OpenVPN. Я занимаюсь этим уже 3 дня, но до сих пор не могу понять, что не так с моей жизнью ...
В основном проблема в том, что я могу подключиться к своему серверу (выделенный ящик ubuntu 14.04) с моего клиента (ПК с win 7), но, хотя я подключен, я НЕ могу получить доступ к Интернету и локальной сети (не могу проверить связь с сервером на 10.0 .0.1).
Я настроил переадресацию ip на сервере и добавил правила iptable, насколько мне известно, а также установил переадресацию портов на маршрутизаторе; но до сих пор не удается привести его в рабочее состояние.
Любая помощь будет принята с благодарностью, так как я еще новичок в openvpn. Заранее всем спасибо за ваше драгоценное время.
Ниже приведены копии моих правил server.conf, client.conf и iptable.
Server.conf
dev tun
proto udp
port 1194
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
dh /etc/openvpn/dh1024.pem
user nobody
group nogroup
server 10.8.0.0 255.255.255.0
persist-key
persist-tun
client-to-client
push "route 192.168.0.0 255.255.255.0"
push "redirect-gateway def1"
push "dhcp-option DNS 8.8.8.8"
log-append /var/log/openvpn
plugin /usr/lib/openvpn/openvpn-plugin-auth-pam.so openvpn
client-cert-not-required
username-as-common-name
management localhost 7505
Таблицы IP
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- anywhere anywhere udp dpt:openvpn
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
ACCEPT all -- 192.168.0.0/24 anywhere ctstate NEW
ACCEPT all -- 10.8.0.0/24 anywhere ctstate NEW
ACCEPT all -- 10.8.0.0/24 192.168.0.0/24 ctstate NEW
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Client.conf
client
dev tun
proto udp
remote 196.xxx.xxx.xxx 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
auth-user-pass
comp-lzo
verb 3
Резюме:
Удаленная локальная сеть - 192.168.0.0/24.
Сеть OpenVPN - 10.8.0.0/24.
Ваш клиент OpenVPN получает IP в 10.8.0.0/24. Предположим, это 10.8.0.42.
Пытаюсь поговорить с удаленной LAN:
Когда ваш клиент OpenVPN отправляет пакет на IP-адрес в удаленной локальной сети (скажем, 192.168.0.56), он отправляется с исходным адресом 10.8.0.42 и достигает сервера OpenVPN.
Сервер OpenVPN отключает его, если вы не включили переадресацию IP. sysctl -w net.ipv4.ip_forward=1).
Если IP-переадресация включена, 192.168.0.56 получает пакет и пытается ответить, отправляя пакеты на 10.8.0.42, но у него нет маршрута для этого. Вместо этого он использует шлюз по умолчанию. Если сервер OpenVPN не является шлюзом по умолчанию, пакет будет потерян. Вы можете проверить маршрут на удаленном компьютере с помощью ip route get 10.8.0.42.
Возможные решения:
добавить маршрут к 10.8.0.0/24 для каждого узла в локальной сети (ip route add 10.8.0.0/24 via $ip_of_vpn_server);
добавить маршрут к 10.8.0.0/24 на шлюз по умолчанию
пакеты будут делать бесполезный переход к маршрутизатору вместо того, чтобы напрямую достигать сервера OpenVPN;
но ты send_redirects включен на маршрутизаторе и accept_redirects включен на узлах LAN, маршрутизатор отправит перенаправление ICMP, чтобы указать лучший маршрут, и узлы LAN должны использовать этот маршрут впоследствии;
настроить NAT на сервере OpenVPN, чтобы скрыть адреса 10.8.0.0/24.
Та же проблема возникает при попытке получить общедоступный IP-адрес от вашего клиента OpenVPN:
если вы использовали первое или второе решение, вы должны убедиться, что 10.8.0.0/24 правильно настроен через NAT маршрутизатором удаленной локальной сети;
если вы использовали NAT на сервере OpenVPN, вам не нужно больше ничего делать.
Я бы предложил использовать второе решение. Чем меньше у вас NAT, тем лучше.
Наличие VPN не обязательно означает, что вы можете подключиться сразу. Вам все равно нужно «сказать» своему клиенту, что ему нужно направлять трафик через эту VPN. Если вы попытаетесь подключиться к 10.0.0.1, а ваш клиент находится в другой сети, он попытается связаться со своим шлюзом по умолчанию. Вместо этого вы должны сказать ему, чтобы он разговаривал с VPN-соединением.
В CMD администратора:
route add <remote network> <VPN IP>
ЕСЛИ вы можете подключиться к своему VPN-серверу, то, скорее всего, вы правильно настроили сервер / клиент для разговора. Тогда проблема сводится к IP и маршрутизации. Я обычно использую pfsense для моего сервера openvpn, а не использую файл conf, но эффект должен быть таким же.
Каждый раз, когда я использовал openvpn, у меня никогда не было соединения на x.x.x.2, и я не мог пропинговать x.x.x.1. Это может быть я, но я видел, что он всегда начинается с 0,6 и маршрутизатор с 0,5
Когда вы подключаетесь к vpn, проверьте свой IP-адрес. ipconfig
Проверьте свою таблицу маршрутизации при подключении route print
посмотрите, можете ли вы пропинговать свой IP-адрес vpn и шлюз на vpn. это может быть в вашем случае 10.8.0.5
Если вы можете опубликовать свои маршруты IPv4, это может помочь. и мы можем сузить круг вопросов.