Как я могу вызвать весь интернет-трафик по VPN PPTP, но все еще позволить доступ к локальной сети?
Необходимо смочь использовать Маршрутизацию и Удаленный доступ (RRAS) на обоих серверах для установки соединения VPN между двумя. Можно установить соединения как "Персистентные", и они автоматически соединят VPN при запуске. Я протестировал это с Сервером 2003 на Rackspace в одном конце и Топке Цепочки для часов X20e на другом конце, связывающемся по VPN PPTP. Это работало безупречно. Я смог соединить облачный сервер с доменом и не общаться ни с какой проблемой.
Эти правила iptables не разрешать трафик к серверу VPN, поэтому VPN не может быть установлен. Вам потребуются следующие правила в цепочке OUTPUT перед окончательным правилом DROP , где 1.2.3.4 - это IP-адрес VPN-сервера. Они позволяют TCP-подключения к порту 1723 (канал управления PPTP) и пакеты GRE (канал данных).
iptables --append OUTPUT --destination 1.2.3.4 --protocol tcp --dport 1723 --jump ACCEPT
iptables --append OUTPUT --destination 1.2.3.4 --protocol gre --jump ACCEPT
Добавьте другой маршрут по умолчанию с более высокой метрикой, указывающий на пустой интерфейс. Когда VPN недоступен, сработает 2-й маршрут и заблокирует трафик
Это не задание iptables - для этого вам не нужны iptables.
Просто установите маршрут по умолчанию для прохождения через VPN, и все готово. Вы также можете добавить другой маршрут по умолчанию с худшей метрикой для использования, когда VPN не работает.
Ваша локальная сеть подключена напрямую, поэтому она имеет приоритет над шлюзом по умолчанию.
Существует два подхода к этому: на основе маршрутизации и на основе межсетевого экрана.
Подход к маршрутизации
Типичная таблица маршрутизации машины, не подключенной к VPN, выглядит примерно так:
10.23.11.0/24 dev eth0
default via 10.23.11.1
Первый маршрут - к хостам в локальной сети, а второй маршрут отправляет все остальное на шлюз по умолчанию. При подключении к VPN таблица маршрутизации выглядит примерно так (где 1.2.3.4 - это общедоступный IP-адрес VPN-сервера, а 10.8.0.1 - частный IP-адрес VPN-сервера):
10.23.11.0/24 dev eth0
1.2.3.4 via 10.23.11.1
default via 10.8.0.1
Первый маршрут такой же, а третий маршрут это то, что отправляет все через VPN. Однако обратите внимание на второе правило: в нем говорится, что для доступа к VPN-серверу общедоступные IP-пакеты должны отправляться через шлюз по умолчанию. Это сделано для того, чтобы туннелированные пакеты, созданные клиентом VPN, действительно доходили до сервера; если этот маршрут отсутствует, пакеты, созданные клиентом VPN, будут снова отправлены через VPN и никогда не попадут на сервер.
Теперь, если третий маршрут удален, тогда пакеты будут отправлены в любую точку Интернета. кроме VPN-сервера, не будет подходящего маршрута, и поэтому хост никогда не отправит их. Поэтому мы хотим, чтобы таблица маршрутизации выглядела так, когда VPN не подключен:
10.23.11.0/24 dev eth0
1.2.3.4 via 10.23.11.1
Хосты в локальной сети все еще доступны, а сервер VPN все еще доступен (поскольку нам нужно иметь возможность запускать VPN), но все остальное не будет удалено. Однако получить эту настройку может быть немного сложно, особенно если вы используете DHCP. Однако статическая конфигурация в Debian будет включать следующее в / etc / network / interfaces :
auto eth0
iface eth0 inet static
address 10.23.11.10
netmask 255.255.255.0
up ip route add 1.2.3.4 via 10.23.11.1
Обратите внимание, что нет оператора gateway , так как это то, что устанавливает маршрут по умолчанию.
Обратной стороной этого подхода является то, что не-VPN-трафик к VPN-серверу по-прежнему разрешен незашифрованным. Если вы запускаете другие службы на VPN-сервере и вам необходимо обеспечить их защиту, вам придется использовать подход брандмауэра.
Изменить : @JamesRyan предполагает, что этот подход хрупок, потому что маршрут по умолчанию может быть добавлено автоматически или случайно. Другой подход - добавить маршрут черной дыры, который отправляет трафик куда-то, но не направляет его дальше. Однако это не будет работать с автоматически добавленным маршрутом по умолчанию, потому что он уже использует метрику с наивысшим приоритетом 0. Маршрут по умолчанию все еще необходимо удалить, но затем можно добавить что-то вроде следующего.
default via 127.255.255.255
Подход межсетевого экрана
Идея состоит в том, чтобы заблокировать весь исходящий трафик на физическом интерфейсе, кроме туннелированного трафика, создаваемого клиентом VPN, и трафика, предназначенного для локальной сети. Объем трафика для VPN зависит от используемого протокола. PPTP использует TCP-порт 1723 в качестве канала управления и GRE в качестве фактического туннеля. OpenVPN использует порт UDP 1194. Правила брандмауэра будут выглядеть примерно так:
iptables --append OUTPUT --out-interface eth0 --destination 10.23.11.0/24 --jump ACCEPT
iptables --append OUTPUT --out-interface eth0 --destination 1.2.3.4 --protocol tcp --dport 1723 --jump ACCEPT
iptables --append OUTPUT --out-interface eth0 --destination 1.2.3.4 --protocol gre --jump ACCEPT
iptables --append OUTPUT --out-interface eth0 --jump REJECT
Первое правило принимает трафик для локальной сети. Второе и третье правила принимают VPN-трафик на VPN-сервер. Четвертое правило отклоняет весь другой трафик, выходящий из физического интерфейса.
Еще одна вещь, которую вам может потребоваться принять, - это DNS, если вы используете DNS-сервер не в локальной сети, потому что клиенту VPN, вероятно, необходимо выполнить поиск DNS для того, чтобы найти VPN-сервер. Следующее правило, вставленное перед REJECT , разрешает трафик DNS к общедоступной службе DNS Google.
iptables --append OUTPUT --out-interface eth0 --destination 8.8.8.8 --protocol udp --dport 53 --jump ACCEPT