С разделением openvpn сеть, не могущая соединяться с удаленным сервером через vpn
Да. Если Вы не размонтировали папку, то файлы так же доступны, как они были бы в нормальной файловой системе.
Если Вы используете данные в целях резервирования, изучаете Двуличность, которая обеспечит шифрование, в то время как тихое обеспечение быстро передает через двоичный файл diff'ing. Если Вы хотите шифрование уровня громкости, просто используйте шифрование нормальной громкости на файле и размонтируйте и скопируйте файл.
OpenVPN использует подсеть Entre для размещения своих виртуальных интерфейсов на стороне сервера, а также для подключающихся клиентов. В вашем случае эта подсеть настроена как 10.187.1.0/24. OpenVPN назначает 10.187.1.1 для серверной части и разделяет остальную подсеть на более мелкие подсети для каждого клиентского соединения. По умолчанию он будет использовать / 30 с двумя используемыми адресами, один сетевой адрес и один широковещательный адрес по соображениям совместимости и назначить первый из используемых адресов серверу, а второй - подключающемуся клиенту. В вашем примере это будет 10.187.1.9 (сервер) и предположительно 10.187.1.10 (клиент).
Итак, ваша первая проблема заключается в запуске telnet google.com 80 -b 10.187.1.9 - вы указание telnet привязать к нелокальному адресу, что не сработает. Вторая проблема заключается в том, что Linux принимает решения о маршрутизации, оценивая по умолчанию адрес назначения только . Поскольку google.com разрешает что-то не локальное для вашей сети и не охваченное никаким другим маршрутом, пакет ретранслируется по маршруту по умолчанию, который в вашем случае будет 192.168.1.1 и который, вероятно, ничего не знает про подсеть 10.187.1.0/24, так что он эффективно отбрасывает пакет. Если вам нужен этот трафик для маршрутизации через tun0 , вы должны явно указать Linux:
echo "200 vpn" >> /etc/iproute2/rt_tables
ip rule add from 10.187.1.0/24 table vpn
ip route add table vpn default dev tun0
Это создаст дополнительную регистрацию в таблице маршрутизации с именем vpn , добавьте правило в используйте эту таблицу маршрутизации, если пакет исходит из подсети 10.187.1.0/24, и добавьте маршрут по умолчанию через tun0 (который является двухточечным интерфейсом, поэтому для спецификации маршрута не требуется адрес шлюза) для всего маршрутизируемого трафика через таблицу vpn .
Я не думаю, что параметр -b работает так, как вы думаете.
Если вы выполните tcpdump , вы увидите, что соединение telnet будет выходить из шлюза по умолчанию, но будет иметь исходный IP-адрес 10.187.1.9. Проблема заключается в том, что даже если ваш исходный IP-адрес изменился - все ваши маршруты основаны на пункте назначения; вы всегда будете использовать шлюз по умолчанию в вашей текущей конфигурации.
Итак, чтобы решить эту проблему, есть два решения.
- Используйте вашу VPN для всех подключений, то есть сделайте вашу VPN шлюзом по умолчанию.
- Реализовать маршрутизацию от источника - или политический маршрут. Это создаст маршрут на основе IP-адреса источника вашего пакета.
Метод 1 прост - вы уже фактически сделали это.
Метод 2, основной способ сделать это выглядит следующим образом:
ip rule add from <source>/<mask> table <name>
ip route add default via <VPN GW> dev tun0 table <name>
ИЛИ
ip route add default dev tun0 table <name>
Где <имя> будет что-то в / etc / iproute2 / rt_tables (вы можете создать имя) или вы можете использовать номер.
Источники:
http://www.saeedpazoki.com/how-to-implement-source-routing-with-linux/