pptpd VPN: нет доступа в интернет после подключения
Я следовал инструкциям в этом руководстве, чтобы настроить сервер vpn, чтобы я мог подключиться к нему и просматривать Интернет практически из другого места. Так далеко от окон, я могу подключиться к нему, но нет доступа в Интернет.
IP-адреса, которые я использовал в файле conf, точно такие же, как в руководстве
localip 192.168.0.1
remoteip 192.168.0.100-200
То же самое для DNS, который 8.8.8.8.
(Все, что вам нужно знать о том, что я сделал, уже есть в этой ссылке)
Как вы думаете, может быть проблема?
2 ответа
Если вашей основной целью настройки VPN-сервера является доступ к веб-сайту, то трафик должен перенаправляться из общедоступного сетевого интерфейса VPN-сервера. Таким образом, включите переадресацию портов, отредактировав файл sysctl.conf. Я предполагаю, что "net.ipv4.ip_forward" комментируется в файле /etc/sysctl.conf:
nano /etc/sysctl.conf
Добавьте или найдите и закомментируйте следующую строку
net.ipv4.ip_forward=1
Сохраните, закройте файл и выполните следующую команду, чтобы изменения вступили в силу.
sysctl -p
Следующие правила брандмауэра iptables разрешают порт 1723, GRE и выполнять NAT
iptables -I INPUT -p tcp --dport 1723 -m state --state NEW -j ACCEPT
iptables -I INPUT -p gre -j ACCEPT
iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
В последнем правиле замените "eth0" на интерфейс подключения к интернету на вашем VPN-сервере. Наконец, для правильной загрузки сайтов необходимо следующее правило
iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -s 172.20.1.0/24 -j TCPMSS --clamp-mss-to-pmtu
Замените 172.20.1.0/24 диапазоном IP-адресов, который используется в параметре "remoteip" в /etc/pptpd.conf. Это правило брандмауэра используется для обеспечения правильного значения MTU для предотвращения фрагментации.
Надеюсь, это может помочь.
Следующая команда решила мою проблему (без интернета) с использованием PPTPD на Ubuntu 14.x
iptables -I INPUT -p tcp --dport 1723 -m state --state NEW -j ACCEPT
iptables -I INPUT -p gre -j ACCEPT
iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -s 10.0.0.0/24 -j TCPMSS --clamp-mss-to-pmtu
sudo iptables-save
sudo iptables -P FORWARD ACCEPT
sudo iptables -P OUTPUT ACCEPT
sudo iptables-save
Обратите внимание: я использовал этот диапазон IP-адресов 10.0.0.0/24 в моем /etc/pptpd.conf
используйте диапазон, который соответствует вашей конфигурации.
У нас были идентичные симптомы, но все Iptables были настроены так, как указано выше. Было возможно подключиться, соединение было стабильным, оно позволяло войти на сервер pptp через ssh и, на удаленном компьютере, даже разрешить DNS (это заметно через браузеры и ping - поскольку он правильно разрешил IP), но веб-страницы не загружались, и невозможно было подключиться к другим серверам через ssh. Это дало понять, что туннель для сервера pptp в порядке.
Проблема заключалась в том, что на этой машине у меня было два независимых восходящих канала, открытых в Интернет (например, mainInf и поддержка), оба настроены через netplan (с этим проблем нет), но, несмотря на подключение к серверу pptp с использованием IP-адреса 1-й восходящий канал (i-face, называемый mainInf), мой шлюз по умолчанию работал во втором восходящем канале (поддержка).
Решением было настроить NAT на правильный выходной шлюз, что позволило пакетам достигать других серверов, как это было изначально (не работало).
iptables -t nat -I POSTROUTING -o mainInf -j MASQUERADE
(имейте в виду, что в нашем случае соединение с сервером pptp осуществляется через IP-адрес, выделенный в адаптере mainInf / восходящей линии связи), и после перехода на тот же адаптер / восходящий канал, что и шлюз по умолчанию (поддержка), он работал:
iptables -t nat -I POSTROUTING -o support -j MASQUERADE
Следовательно, если вы можете стабилизировать VPN-соединение, проверить связь или подключиться к серверу pptp (в нашем случае через ssh), но не можете получить доступ к IP-адресу, которого нет на этом сервере, у вас, вероятно, есть проблема с маршрутизацией / пересылкой.
4 полезных команды для устранения неполадок:
- смотреть iptables -t nat -L -nv
- смотреть iptables -L -nv
- маршрут -n
- tcpdump -i -s 0 TCP-порт 1723 или proto 47 (подробнее здесь)