ValdikSS

Я слабо разбираюсь в Windows, поэтому не считайте моё мнение экспертным, могу быть не прав.

Если не ошибаюсь, при входящих TCP-соединениях Windows автоматически сохраняет IP-адрес назначения, на который это соединение пришло, во внутренних структурах сокета, поэтому в рамках одного TCP-соединения пакеты будут уходить с одного IP-адреса (они автоматически bind'ятся на этот source ip address).

Далее маршрутизация: в Windows, начиная с Vista, используется strong host model (см. RFC1122), которая предписывает отправлять пакеты с того сетевого интерфейса, IP-адрес которого указан в структурах сокета.
Старая статья на technet имеет следующую приписку:

If the program specifies a source IP address, that IP address is used as the source IP address for connections sourced from that socket and the adapter associated with that source IP is used as the source interface. The route table is searched but only for routes that can be reached from that source interface.

И далее описываются похожие принципы, связанные с RFC3484.

«Автоматически» всё работает только для протоколов с концепцией соединения, т.е. с TCP. Для UDP, если программа не написана с учётом поддержки multihoming, пакеты могут уходить согласно метрике, т.е. с неправильного адреса (не с того, на какой пришел входящий пакет), и ничего не заработает.

Без дампа захвата трафика и анализа ситуации могу только ткнуть пальцем в небо и предположить, полагая, что у вас корректно настроен NAT (MASQUERADE) из VPN-интерфейса на физический интерфейс, что от VPN-клиентов уходит трафик без подмены адреса (без NAT'а), если TCP-сессия уже была установлена с каким-либо хостом в момент соединения с VPN.

В этом случае, при типичной настройке iptables, правило MASQUERADE не будет выполняться (так как у пакетов состояние conntrack INVALID, а не NEW/ESTABLISHED), и пакеты будут маршрутизироваться без замены исходного адреса.

Решение:

iptables -I FORWARD -m conntrack --ctstate INVALID -j DROP

Аналогичная ситуация может происходить, если кто-то из клиентов генерирует пакеты TCP на низком уровне, без установки TCP-сессии. Например, единичный SYN/ACK-пакет, не принадлежащий какой-либо TCP-сессии, отправленный через VPN, не попадёт под действие NAT MASQUERADE-правила.

Так как вы пытаетесь маршрутизировать подсеть через роутер 10.0.0.1, которая доступна через другой "роутер" (10.0.0.2) в вашем же L2-сегменте, роутер 10.0.0.1 отправляет вашему компьютеру ICMP Redirect в целях оптимизации маршрута.
Настраивается принятие ICMP-редиректов опцией net.ipv4.conf.all.accept_redirects и сопутствующими, а отправка — net.ipv4.conf.all.send_redirects и сопутствующими.

Почему маршрутизация перестаёт работать, когда трафик идёт напрямую? Сложно сказать без отладки, но пальцем в небо: Wi-Fi — не Ethernet, хоть и пытается быть похожим на него. В Wi-Fi не передаётся MAC-адрес отправителя, из-за чего, например, его нельзя добавить в Ethernet-бридж.
Компьютер подключён также по Wi-Fi? В таком случае, вероятно, смартфон получает ваши пинги с MAC-адреса роутера 10.0.0.1, соответственно и ответить пытается ему, а не компьютеру.

Браузеры не имеют привилегий изменения таблицы маршрутизации в ОС, не могут создавать и настраивать сетевые интерфейсы, не могут использовать TCP/UDP-сокеты. Все браузерные расширения — прокси, VPN средствами браузерного расширения реализовать нельзя.

Однако можно написать нативную программу, которую браузерное расширение может запускать и контролировать с помощью Native Messaging (Chrome / Firefox).
Нативная программа не ограничена возможностями браузера и может выполнять любые действия на компьютере. Соответственно, с её помощью можно настроить VPN.

Примеры диапазонов IP-адресов многих хостинг-провайдеров можно увидеть в агрегаторах Looking Glass, например на сайте https://looking.house/points.php
А вообще, информацию по IP-диапазонам можно получать из анонсов диапазонов AS через BGP. Например: https://bgp.he.net/AS200350#_prefixes
Также дополнительная информация может быть доступна во whois.

Если вам нужен VPN для Туркменистана, а не сами диапазоны и серверы, можете написать мне личное сообщение — подскажу, где купить.

v=spf1 ip4:165.165.165.0/24 ip4:136.136.136.0/20 include:_spf.mail.ru include:spf.unisender.com a mx ~all

Не смогут ли посторонние лица эксплуатировать сервер в качестве маршрутизатора?

Могут, у вас же в IPv4 FORWARD-таблице policy accept без каких-либо запрещающих правил.
Добавьте разрешающее правило для интерфейса туннеля, а остальное заблокируйте.
Также блокировка всех исходящих и входящих IPv6-пакетов создаст проблемы программам, рассчитывающим на доступность IPv6-связности (хотя бы внутри хоста). Разрешите пакеты с/до lo.