Исправлено: это оказалось комбинацией того, что сказал BatchyX (отсутствует маршрут 172.16.101.0/24 на удаленном конце), и tinc на удаленной стороне не удалось запустить сценарий -up (сценарий не был исполняемым).
Так что теперь все работает супер, всем спасибо за помощь :)
================================================== ===========================
Моя проблема на удивление сложна для объяснения, поэтому я разобью ее на более мелкие части, заранее извините за длинный текст :)
У меня есть сервер у хостинг-провайдера, у которого есть общедоступный IP-адрес, на этом сервере работает tinc (программное обеспечение vpn).
Дома у меня есть два vlan, VLAN1 (моя обычная подсеть для компьютеров и т. Д., За NAT) и VLAN20 для моей лаборатории vmware. Окружающая среда.
Я бы хотел настроить так, чтобы моя сеть VLAN20 могла использовать сервер у хостинг-провайдера в качестве своего шлюза (его внешний IP-адрес) вместо внешнего шлюза, который есть у меня дома.
Для этого у меня есть домашний сервер с двумя сетевыми интерфейсами, один nic на VLAN1 и один nic на VLAN20.
Допустим, у меня есть следующие IP-адреса:
Server at hosting provider:
Public IP: 123.123.123.123 (eth0)
Private IP: 10.1.0.1/24 (tun0)
Network at home:
VLAN1 - 192.168.1.0/24 (.1 is the gateway)
VLAN20 - 172.16.101.0/24
Network on server at home:
NIC1 (VLAN1) - 192.168.1.50/24 (eth0)
NIC2 (VLAN20) - 172.16.101.1/24 (eth1)
Tunnel - 10.1.0.2/24 (tun0)
Я настроил tinc, так что мой домашний сервер работает через туннель, я могу пинговать 10.1.0.1 с домашнего сервера и 10.1.0.2 с сервера у хостинг-провайдера.
В дополнение к этому я настроил так, что домашний сервер использует туннель для шлюза по умолчанию, все это работает с фактического домашнего сервера, моя проблема в том, что я не могу получить клиентов в сети VLAN20 для доступа в Интернет.
Проблема в том, что я не могу понять, как настроить маршрутизацию так, чтобы сеть 172.16.101.0/24 использовала шлюз по умолчанию в туннеле.
Маршруты на домашнем сервере следующие:
root@home:/etc/tinc/vpn/hosts# ip route
0.0.0.0/1 dev tun0 scope link
default via 192.168.1.1 dev eth0
10.1.0.0/24 dev tun0 proto kernel scope link src 10.1.0.2
123.123.132.123 via 192.168.1.1 dev eth0
128.0.0.0/1 dev tun0 scope link
172.16.101.0/24 dev eth1 proto kernel scope link src 172.16.101.1
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.50
/ 1 добавляются, когда туннель работает с:
ip route add 0.0.0.0/1 dev $INTERFACE
ip route add 128.0.0.0/1 dev $INTERFACE
Выполнение трассировки с домашнего сервера до 8.8.8.8:
root@home:/etc/tinc/vpn/hosts# traceroute -s 10.1.0.2 8.8.8.8 -n
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 10.1.0.1 33.681 ms 33.698 ms 33.658 ms
2 Router_At_Hosting_Provider 34.930 ms 34.907 ms 34.875 ms
Таким образом, «туннельная» подсеть (10.1.0.0) отлично работает со шлюзом по умолчанию через туннель.
Это тоже отлично работает:
root@home:/etc/tinc/vpn/hosts# traceroute -s 172.16.101.1 10.1.0.2 -n
traceroute to 10.1.0.2 (10.1.0.2), 30 hops max, 60 byte packets
1 10.1.0.2 0.032 ms 0.003 ms 0.005 ms
Но моя проблема в следующем:
root@home:/etc/tinc/vpn/hosts# traceroute -s 172.16.101.1 8.8.8.8 -n
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
Если у кого-то есть указатели на то, где я должен искать, я был бы очень признателен.
(Полный список изменений, внесенных на оба сервера после простой установки debian, находится здесь http://pastebin.com/r3Vsvycq)
Редактировать Я плохо разбираюсь в Visio, но вот моя попытка показать, что я пытаюсь настроить: http://i.stack.imgur.com/ff2R6.png (пока не могу вставить строку, потому что моя репутация недостаточно высока).
В этой конфигурации есть несколько WTF:
ip route add 0.0.0.0/1 dev $INTERFACE
ip route add 128.0.0.0/1 dev $INTERFACE
Помогите себе и замените это ip route change default dev $INTERFACE. Это удалит шлюз по умолчанию на eth1 и заменит его своим собственным. Вы также можете указать предпочтительный исходный адрес на этом маршруте, добавив src 10.1.0.2 в конце.
Если вместо этого вы хотите сохранить маршрут по умолчанию, но добавить свой собственный, просто измените метрику исходного маршрута по умолчанию на 1 или более. Когда вы добавите свой маршрут по умолчанию, он переопределит (но не уничтожит) исходный маршрут по умолчанию.
Кроме того, маршрут к 10.1.0.0/24, когда VPN работает, немного избыточен, поскольку он уже покрыт маршрутом по умолчанию.
То, что вам нужно в качестве таблицы маршрутизации, будет выглядеть примерно так:
default dev tun0 scope link src 10.1.0.2
default via 192.168.1.1 dev eth0 metric 1
123.123.132.123 via 192.168.1.1 dev eth0
172.16.101.0/24 dev eth1 proto kernel scope link src 172.16.101.1
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.50
Теперь эта таблица маршрутизации верна. Единственная проблема теперь заключается в том, что у вашего сервера нет маршрута к 172.16.101.0/24, поэтому мы попытаемся маршрутизировать его через свой открытый интерфейс. Обратный путь практически нарушен, поэтому traceroute работает, а ping - нет.
Просто добавьте маршрут на удаленном сайте к 172.16.101.0/24 через tun0, и все будет хорошо.