Роутинг, бриджинг, tun, tap, ovpn и много других страшных слов.

Схема сети выглядит примерно так:

[Ноут]<->[Домашний сервер] <- ovpn -> [VPS] <-> интернет
                                             | ovpn (tap) -> клиент1
                                             | ovpn (tun) -> клиент2

Все ходят в интернет через VPS.

VPN, соединяющий HS(Домашний сервер) и VPS: 10.101.101.0/24
Интерфейс в обоих случаях называется tap6

VPN, соединяющий VPS и клиента: 10.101.102.0.24
Интерфейс называется tun0

На HS при подъеме tap6:
/bin/ip route add 10.101.102.0/24 dev tap6

Gateway не указан, потому как я не знаю как это сделать:

HS# ip route add 10.101.102.0/24 via 10.101.101.1 dev tap6
RTNETLINK answers: Network is unreachable

Но хватает и просто указания интерфейса.

Проблема 1.

Почему-то HS отказался пропускать пакеты из интернета обратно к ноуту. Методом мучительного тыка выяснил, что дело в rp_filter. Проблема решилась его отключением на HS tap6.

Вопрос: почему проблема вообще возникла? Я могу запросить страницу с HS через VPS и получить ответ, но если HS выступает в роли роутера, то syn-запрос уходит, подтверждение возвращается и не идет в домашнюю сеть пока не будет убран rp_filter. Правильно ли выключать в таком случае rp_filter? Можно ли включить интерфейс tap6 ovpn в мост с интерфейсами локальной сети и как с этим будет разбираться ovpn, который, вроде как, должен назначать ему ip-адрес?

Проблема 2.

Если клиент, подключается к VPS через tun (на андроиде tap не работает), то не может добраться ни до каких ресурсов HS.
Запрос доходит и не возвращается, как если бы роутинг не работал. Если включить arp_proxy на tap6 VPS, то все начинает работать.

# route
...
10.101.102.0    0.0.0.0         255.255.255.0   U     0      0        0 tap6

При попытке пинговать до включения arp_proxy на интерфейсе tap6 VPS:

HS# ping 10.101.102.6
From 10.101.101.2: icmp_seq=1 Destination Host Unreachable

10.101.101.2 - это ip tap6 у HS, т.е. запрос как бы добрался до tap6.

tcpdump на tap6 VPS показал запросы вида:
ARP, Request who-has 10.101.102.6 tell 10.101.101.2, length 28

Но если пинговать клиента прямо с VPS, то все в порядке:

VPS# ping 10.101.102.6
64 bytes from 10.101.102.6: icmp_seq=1 ttl=64 time=233 ms

При включении arp_proxy для VPS tap6 - все тут же начинает работать, но везде предупреждают, что так лучше не делать.

Вероятно проблема связана с роутингом - HS не может найти 10.101.102.6 и рассылает ARP-запросы по всем интерфейсам. При включенном arp_proxy он получает ответ вида
10.101.102.6 at ************ [ether] on tap6 и после этого уже спокойно шлет все в tap6.

iptables точно ни при чем.

Похоже, что существует какие-то правила из-за которых разные сетевые интерфейсы не могут просто передавать пакеты друг другу, согласно таблице роутинга. Но я их не знаю.
Везде рекомендуют объединять нужные интерфейсы в мост, но я не представляю как это сделать с tun/tap, да и не нравится мне это решение.

Если кто-то с этим уже сталкивался, пожалуйста, расскажите об особенностях роутинга, настройке областей видимости (и вообще, важны ли они тут), работе rp_filter вообще и марсианских адресах в частности, допустимости использования arp_proxy и опасностях с этим связанных и о возможности как-то засунуть в мост tun (если она вообще есть).
-----

UPDATE: gateway можно указать, если делать это после соединения. Поскольку у ovpn нет post-up, то добавил в ovpn route-up вызов скрипта с &, в котором выставлен sleep 1, а потом уже роутинг. В документации к ovpn сказано, что такая ситуация возможна и для ее устранения можно в конфиге специально указать паузу в секундах.

С указанием GW роутинг сразу заработал. Если я правильно понял, то когда GW не указан, то отправляется ARP-запрос на интерфейс с целью выяснить, куда же все-таки доставлять.
Но и без указания GW все иногда работает. Например, клиент 10.101.102.6 мог соединяться с виртуалкой на HS и после этого его можно было даже пинговать.

В общем, пожалуйста, если кто в теме - раскройте тайну, как же работает ARP, когда, куда и при каких условиях посылаются запросы, формируется ли таблица без запросов (на основе форвардинга проходящих пакетов, например), и так далее.