Вы не написали, что говорит tcpdump на стороне сервера.
По ощущению если с NAT-ом пинг работает а без него нет значит скорее всего на сервере нет маршрута в вашу сеть.
Поясню.
На сервере в директории /etc/openvpn/ccd должен лежать файлик который описывает маршрут в вашу сеть. Имя файла должно совпадать с CommonName сертификата вашего хоста-клиента vpn (дубликаты CN не подойдут! тоесть сертификат уникальный)
Содержимое файла по-моему должно быть для вас таким:
iroute 192.168.243.0 255.255.255.0
ifconfig-push 192.168.251.25 192.168.251.26
В конфиге OpenVPN сервера должна быт опция
client-config-dir ccd
После этого рестартануть OpenVPN сервер. Он должен будет подхватить конфиг. После соединения клиента он должен создать маршрут в вашу сетку на стороне openvpn сервера.
Для проверки можете прописать маршрут руками.
ip route add 192.168.243.0/24 via 192.168.251.25 dev tunX
Пинги должны забегать без NAT.
Но давайте разбираться дальше. Давайте опустим возможности русского языка и относительно ответов команд будем общаться конкретно. tcpdump не говорит OK! :) Он говорит что слышит на интерфейсе и фильтруя по заданному условию. Вы сказали пинг один раз всё проходит. Тоесть стабильно один раз есть запрос и ответ? А потом только запросы, без ответов. При прерывании в стратистике написано сколько отправлено и получен только один ответ. Так?
Если Вы имеете доступ к офисному серверу (или попросите админа) запустите там
# tcpdump -i tunХ proto ICMP
далее смотрите адрес источника и адрес получателя на входящем пакете и на ответе.
Затем посмотрите таблицу маршрутизации на сервере есть ли единственный маршрут в сеть где находится адрес источника. Нет ли какого-то конфликта сетей (например в офисе есть сетка такая же как у вас)?
Вот ещё что можно попробовать.
Можете добавить в iptables правило
-A POSTROUTING -o tun0 -j MASQUERADE
Только добавьте аксептирующие правила input и forward (вы говорили что отключали iptables) лишнее закоментируйте и запустите iptables.
Это включит NAT в сторону VPN и исключит необходимость серверу-получателю знать про маршрутизацию в вашу сетку. Ему хватит роута который добавил VPN сервер. Если заработает — значит проблема в маршрутизации на стороне сервера.
В случае ping -I eth1 пакеты улетают "наружу" непосредственно в интерфейс.
А в случае ping -I 192.168.243.1 используется таблица маршрутизации хоста на котором запущен ping. Тоесть пакет попадает как бы внутрь хоста с адресом источника равным заданному адресу на интерфейсе.
@Abdus traceroute тут не поможет. Дампить нужно.
Вы обратили внимание на адреса (src dst) пакета который уходит?
Тaaак... И не люблю я эти пинги с интефейсов без адреса.
В одном окне терминала
$ ping -I 192.168.243.1 8.8.8.8
В другом терминала
# tcpdump -n -i eth0 proto ICMP
Есть ещё один момент:
"The search keyword of a system's resolv.conf file can be overridden on a per-process basis by setting the environment variable LOCALDOMAIN to a space-separated list of search domains."
Если Вы при вызове nslookup не задавали адрес DNS сервера то в качестве DNS стоит ваша машина. И раз для домена host.company.local ответ верен, значит работает она верно.
Посмотрите таблицу маршрутизации
# ip route
Попробуйте в одном окне консоли запускать
$ resolveip host.company.local
а во второй
# tcpdump -i -nn udp and port 53
пройдитесь по всем интерфейсам включая локальный и посмотрите правильно ли ходят пакеты.
Также посмотрите файл
# cat /etc/resolv.conf
если используете NetworkManager он должен создаваться автоматически
Что выдаёт ?
$ hostname -f
Ну и если до этого момента не встало всё на места можно заглянуть в
# strace resolveip host.company.local
при закоментированной строке с адресом host.company.local в /etc/hosts
Предыдущий вывод strace можно сравнить его с
# strace nslookup host.company.local
1) Всегда есть место костылю. Делаете в цикле nslookup всех имён и формируете список строк для заталкивания в hosts.
2) Если nslookup отдаёт правильные адреса то почему же браузер не получает их? А нет ли какого конфликта имён вашей машины с сеткой офиса?
Браузер перегрузить не помогает? Компьютер? Может где-то осело в кеше.
А ping в правильную сторону работает?
Если стоит resolveip из пакета community-mysql-server что он говорит?
