Я настроил статическую IP-конфигурацию для клиентов, подключающихся к серверу OpenVPN, работающему на экземпляре AWS EC2 (CentOS). Назначение статического IP-адреса - выделить QUOTA с помощью iptables каждому клиенту, так что использование полосы пропускания находится под контролем.
Ниже приведены мои конфигурации:
server.conf:
mode server
tls-server
dev tun
topology subnet
push "topology subnet"
ifconfig 10.8.1.1 255.255.255.0
push "route-gateway 10.8.1.1"
port 443
proto tcp-server
push "redirect-gateway def1 bypass-dhcp"
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
tls-crypt tc.key
cipher AES-256-CBC
user nobody
group nobody
persist-key
persist-tun
client-config-dir /etc/openvpn/ccd/
management localhost 7505
/ и т.д. / openvpn / ccd / клиент:
ifconfig-push 10.8.1.2 255.255.255.0
правила iptables:
-P FORWARD DROP
-A FORWARD -d 10.8.1.2/32 -g client
-A FORWARD -s 10.8.1.2/32 -g client
-A client -m quota --quota 10000000000 -j ACCEPT
client.ovpn:
client
dev tun
remote-cert-tls server
cipher AES-256-CBC
pull
resolv-retry infinite
remote xyz.dynu.net 443 tcp-client
nobind
<ca> ... </ca>
<cert> ... </cert>
<key> ... </key>
<tls-crypt> ... </tls-crypt>
В число клиентов входят пользователи Windows, Linux и Android.
Мои вопросы:
client (путем ручной настройки IP-адресов и маршрутов) для использования IP 10.8.1.3 вместо того 10.8.1.2 который был вытолкнут с сервера?Я не предпочитаю topology net30 потому что он устаревает и оставляет клиентам меньший пул IP-адресов.
Здесь задается аналогичный вопрос: Запретить клиенту openvpn изменить IP-адрес устройства с краном но это не для tun устройств.
Старая ветка пропущенная ссылка Заставить клиента принять ifconfig-push состояния:
Когда он (сервер OpenVPN) получает пакет от определенного клиента, он выполняет проверку обратного пути, чтобы подтвердить, что если бы он отправлялся на исходный IP-адрес, он отправил бы его этому клиенту. Если нет, он отбрасывает пакеты.
Поэтому, если клиент выбирает другой IP-адрес, пакеты не проходят.
Это поведение где-то задокументировано и верно ли это для последних выпусков OpenVPN (2.4.6)?
Цитата Нила Брауна в старой ветке, которую вы опубликовали, сопровождается ссылкой на исходный код:
См. Комментарий в строке 1605 файла multi.c и окружающий код.
Я думаю, он имел в виду комментарий, который сейчас на строка 2569:
/* make sure that source address is associated with this client */
Позже, в строках 2580 и 2690, вы можете увидеть, что это может привести к появлению следующего сообщения журнала:
«MULTI: неверный адрес источника от клиента [% s], пакет отброшен»
Так что я предполагаю, что это справедливо и сегодня.
Для справки в будущем «сегодня» относится к версии 2.4.7.
Редактировать:
Сегодня я установил тестовый сервер OpenVPN. Я также установил правило в брандмауэре машины для подсчета всех входящих пакетов с виртуального интерфейса. После подключения от клиента я смог пропинговать другой адрес, доступный через сервер, и счетчик увеличивался (даже для несуществующих хостов). Затем я изменил адрес в клиентском интерфейсе:
ip a add 192.168.1.3/24 dev tun0
ip a del 192.168.1.2/24 dev tun0
Я больше не мог пинговать что-либо через этот интерфейс, и счетчик не увеличивался. Похоже, что клиент все еще отправлял пакеты через туннель, потому что, когда я устанавливаю подробность на 5 на клиенте, я получаю rW для каждого отправленного пакета ping. r представляет собой пакет, полученный от tun интерфейс (с точки зрения openvpn процесс) и W инкапсулируется ли этот пакет и отправляется на сервер. (Обычно я бы также получил Rw если бы был ответ.) Это говорит о том, что пакеты отбрасывались на стороне сервера., и это хорошо.
Я не видел отбрасываемых пакетов на сервере openvpnжурнала, но это, вероятно, потому, что моя многословность была установлена на 3 и в соответствии с этот, D_MULTI_DROPPED появляется только на 4 и выше.
Затем я изменил адрес обратно на изначально назначенный (без перезапуска соединения):
ip a add 192.168.1.2/24 dev tun0
ip a del 192.168.1.3/24 dev tun0
И все снова заработало, счетчик увеличивался, и существующие хосты отвечали.