У меня есть клиент OpenVPN, работающий на моем сервере, который получает общедоступный IP-адрес в удаленной сети в другой стране. Конфигурация клиента следующая:
dev tap
remote a.b.30.7
float a.b.30.7
port 5167
ifconfig a.b.28.178 255.255.255.128
route-gateway a.b.28.129
#redirect-gateway def1
secret woot.key
cipher AES-128-CBC
dhcp-option DNS a.b.8.8
redirect-gateway прокомментирован, так что мой сервер (на котором запущен клиент openvpn) не "захвачен" VPN-соединением. Я могу привязать службы к интерфейсу tap0 (например, httpd и т. Д.) И запустить веб-сайт с этого IP-адреса в другой стране. Интернет-провайдер, на котором работает клиент openVPN, не имеет фильтрации исходящего трафика, поэтому трафик для VPN может просто выходить через шлюз по умолчанию eth0 с общедоступным IP-адресом в другой стране. Только входящий трафик маршрутизируется через VPN (т.е. входящие запросы httpd), но исходящий трафик выходит через eth0 подделанным публичным IP-адресом VPN. Без ЛЮБОЙ возиться с маршрутами или iptables, это просто работает без проблем .. на сервере DEBIAN. Очевидным преимуществом является то, что у меня скорость и маршрутизация моего обычного интерфейса eth0, но с IP-адресом в другой стране.
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
x.y.150.64 0.0.0.0 255.255.255.224 U 0 0 0 eth0
a.b.28.128 0.0.0.0 255.255.255.128 U 0 0 0 tap0
0.0.0.0 x.y.150.65 0.0.0.0 UG 0 0 0 eth0
x.y - это фактическая сеть сервера, а a.b - удаленная сеть openvpn.
Эта проблема? ТОЧНО то же самое НЕ РАБОТАЕТ в Ubuntu, и я не могу понять, почему. Я сделал это на бесчисленных серверах Debian без проблем, без каких-либо настраиваемых маршрутов или каких-либо правил iptables. Ни на одном сервере нет брандмауэра. Я считаю, что это очень простая проблема, или в Ubuntu происходят какие-то странные вещи. Стоит отметить, что VPN действительно работает на серверах Ubuntu, если я раскомментирую шлюз перенаправления (как и должно), за исключением того, что это не то, что я хочу. Мне все еще нужно получить доступ к серверу через его основной интерфейс, eth0.
Трассировка сервера Debian (РАБОТАЕТ):
# traceroute -i tap0 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 40 byte packets
1 blah (a.b.29.1) 39.161 ms 39.140 ms 39.332 ms
2 asdf (a.b.30.1) 40.870 ms 40.879 ms 40.850 ms
3 sth-sbb2-ank35-1-ge26-100.dcs.net (217.78.35.5) 40.816 ms 40.818 ms 40.783 ms
4 google-gw.dcs.net (217.78.35.14) 40.780 ms 40.601 ms 40.565 ms
etc. fine here.
Трассировка сервера Ubuntu (НЕ РАБОТАЕТ):
# traceroute -i tap0 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
borked.
8.8.8.8 общедоступный DNS в Google.
IP-адрес VPN недоступен из внешнего мира. Интересно, если бы я:
ssh -b [debian.server.openvpn.client.IP] user@[ubuntu.server.openvpn.client.IP]
Я могу подключиться / пинговать / увидеть его. Это с двумя отдельными VPN-клиентами, работающими как в Debian, так и в Ubuntu, в той же сети a.b, что и в таблице маршрутов (разные IP-адреса в удаленной сети). IP-адрес VPN-клиента debian server общедоступен, но на сервере Ubuntu его нет! Только изнутри a.b!
Цель состоит в том, чтобы обмануть трафик с eth0 вместо того, чтобы отправлять его обратно через VPN и тратить впустую пропускную способность VPN. Кроме того, такая же конфигурация VPN будет без проблем работать на сервере debian. Я могу поместить конфигурацию для VPN, которая находится в коробке Ubuntu, в коробку Debian, и все в порядке.
Сервер Debian работает под управлением Debian 5 64bit с 2.6.32-bpo.5-xen-amd64
Сервер Ubuntu работает под управлением Ubuntu 10.04.1 LTS с сервером 2.6.32-24
Я подумал, что это может быть проблема с модулями ядра и tun.ko, так как я не видел этого с помощью modprobe -l на сервере Ubuntu, но DID на сервере debian. Видеть https://bugs.launchpad.net/ubuntu/+source/linux/+bug/565856 Если Вы заинтересованы. Я пробовал обходные пути безрезультатно. Думаю, дело в другом.
Любая помощь приветствуется! Я приношу свои извинения за отсутствие надлежащих сетевых терминов там, где это необходимо, у меня есть только промежуточные знания в области сетевых технологий, и поскольку это сработало для меня с легкостью в debian, мне не пришлось делать ничего особенного.
Ubuntu может иметь другое значение по умолчанию для фильтрации обратного пути. Проверить различные rp_filter в /proc/sys/net/ipv4/conf/....
Если это не поможет, следующим шагом будет подтверждение того, входят / исходят пакеты с помощью tcpdump или wirehark. Также подтвердите, что у вас действительно нет брандмауэра с iptables -vL.
Я должен признать, что (пока) не до конца понимаю, чего вы пытаетесь достичь. Но я думаю, вы хотите, чтобы ваш сервер Ubuntu (и Debian) был доступен по IP-адресу, который вы получили через OpenVPN (входящий трафик), но отправлял свой собственный (= серверы Ubuntu) трафик через интерфейс eth0, локальный для вашего (Ubuntu) сервера («спуфинг ") VPN-IP. Или в этом роде. Я не уверен, что это очень хорошая идея (возможно, это зависит от того, почему вы это делаете), но я предполагаю, что для этого есть причина, и, как вы говорите, она работает с Debian. Так что не будем вдаваться в подробности (хотя это может быть важно позже).
Далее интересно, почему строчка
route-gateway a.b.28.129
включенный в вашу конфигурацию VPN не ведет (кажется) к записи в вашей таблице маршрутизации.
Также я не уверен, какова цель / понимание двух маршрутов трассировки, которые вы показываете ... Кажется, вы пытаетесь трассировать маршрут до 8.8.8.8 через VPN-туннель. Как это исходящий трафик Я не очень понимаю его отношение к вашей проблеме. И я бы сказал (глядя на вашу таблицу маршрутизации), что трафик, который вы генерируете таким образом, не проходит (не должен?) Через туннель. Я вижу, что это похоже на Debian ... Но я не понимаю, почему это так. Глядя на таблицу маршрутизации, я бы предпочел предположить, что пакеты traceroute, которые вы пытаетесь отправить, tap0 (должны быть?) "перенаправлены" на eth0 (маршрут по умолчанию).
Теперь это подводит меня к предположению, которое я бы принял за вашу проблему: Переадресация IP. Может быть, в вашем Debian он включен, а в Ubuntu он отключен? Вы можете найти дополнительную информацию (например, как узнать, включена ли переадресация IP), перейдя по ссылке выше (или воспользуйтесь своей любимой поисковой системой или руководством по Ubuntu).
Ваша возможность связаться с демоном SSH в Ubuntu говорит о том, что вы очень близки :). Поэтому может быть важно знать, что вы имеете в виду под
«IP-адрес VPN-клиента debian server общедоступен, но не на сервере Ubuntu!»
Что вы пытаетесь сделать (т.е. к какой службе вы пытаетесь подключиться), когда компьютер с Ubuntu «недоступен»? Доступ к его веб-серверу? Какой IP прослушивает эта служба?
Проверьте, активен ли rp_filering
sysctl -a | grep \\.rp_filter
Ищите интерфейсы с = 1
Отредактируйте /etc/sysctl.conf и установите
net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.all.rp_filter=0
Здесь есть хорошая веб-страница об этом http://www.tolaris.com/2009/07/13/disables-reverse-path-filtering-in-complex-networks/