Как отключить обнаружение соседей по ipv6 для заданного адреса?
У меня есть балансировщик нагрузки centos, использующий пиранью и прямую маршрутизацию. Это использует arptables на реальных серверах, чтобы они не претендовали на виртуальные адреса ipv4. Я хотел бы расширить эту настройку, чтобы также поддерживать ipv6. До сих пор я нашел единственный вариант - использовать решение iptables вместо arptables с ip6tables и целью TPROXY, но я не уверен, что это сработает. Но я все же хотел бы, чтобы существующий IP-адрес был ...
Я хотел бы запустить OpenVPN в клиентском режиме на моей облачной виртуальной машине (экземпляр EC2), чтобы трафик, исходящий из виртуальной машины, обычно проходил через VPN. Но я бы все равно хотел, чтобы существующий IP-адрес был доступен для SSH-подключений (чтобы он не прерывал SSH-соединение, которое я сейчас подключил к машине).
Вот текущий .ovpn файл настроек, который я использую:
client
dev tun
proto udp
remote xxx.yyy.com 1198
resolv-retry infinite
nobind
persist-key
persist-tun
cipher aes-128-cbc
auth sha1
tls-client
remote-cert-tls server
auth-user-pass
comp-lzo
verb 1
reneg-sec 0
crl-verify crl.rsa.2048.pem
ca ca.rsa.2048.crt
disable-occ
Изменить: этот вопрос может быть дубликатом Предотвратить потерю SSH-соединения после входа в VPN на сервере ... но там нет принятого ответа либо.
Вы можете использовать расширенную маршрутизацию для маршрутизации пакетов, входящих на ваш основной интерфейс, через тот же интерфейс. Таким образом, любой трафик, исходящий с сервера, будет маршрутизироваться через VPN, но основной интерфейс вашего сервера останется доступным для подключений. Идея заключается в том, что если пакет проходит через основной интерфейс, он будет использовать другую таблицу маршрутизации с именем «vpn», поэтому на него не будут влиять настройки маршрутизации VPN-клиента.
Для достижения этого выполните следующие действия:
Отредактируйте файл / etc / iproute2 / rt_tables . Он должен содержать что-то вроде этого:
#
# reserved values
#
255 local
254 main
253 default
0 unspec
#
# local
#
Добавьте эту строку в конец файла:
1 vpn
В файл / etc / network / interfaces в настройках вашего основного интерфейса (или в соответствующий файл в /etc/network/interfaces.d/ ), добавьте следующие строки:
up ip route add 0.0.0.0/0 via def.ault.gw table vpn
up ip rule add from the.primary.ip.addr table vpn
down ip route del 0.0.0.0/0 table vpn
down ip rule del from the.primary.ip.addr
Замените the.primary.ip.addr IP-адресом вашего основного интерфейса (то есть IP-адрес, через который должен быть доступен ваш сервер) и def.ault.gw с адресом шлюза по умолчанию.
Я бы посоветовал использовать параметры '--up' и '--down' для запуска сценариев оболочки, которые управляют межсетевым экраном и таблицей маршрутизации на вашей виртуальной машине по мере необходимости. Это позволит вам туннелировать трафик через вашу VPN (если openvpn этого еще не делает) и сделать исключение для трафика ssh. Помните, что правила iptables применяются сверху вниз, поэтому убедитесь, что ваше правило исключения применяется до правила туннелирования. Есть и другие вопросы, которые вы можете использовать в качестве примеров о том, как управлять таблицами маршрутизации и правилами брандмауэра.
iptables - Цель для маршрутизации пакета на определенный интерфейс?
Я думаю, что проблема, с которой вы столкнулись, заключается в том, что по умолчанию Маршрут находится в VPN, и есть некоторые маршруты, которые фильтруют пакеты, поступающие с интерфейса, у которого нет маршрута к источнику. Это называется RP-фильтр .
У вас есть 2 решения, чтобы иметь другой маршрут по умолчанию для sshd, чем для остальных процессов. Вы можете использовать сетевые пространства имен или контрольные группы. Я мало что знаю о них, но вы можете прочитать больше в ответах на:
https://superuser.com/questions/271915/route-the-traffic-over-specific-interface-for-a-process -in-linux
Вы можете сделать это с помощью расширенной маршрутизации, как предлагается, но это не так просто.
Самым простым решением для достижения вашей цели является маршрутизация пакетов с другим адресом вашего (домашнего) IP-адреса. Всегда полезно ограничить доступ по ssh несколькими безопасными IP-адресами. Например, вы можете сделать:
ip route add 1.1.1.1 via 9.9.9.9
Здесь 1.1.1.1 - ваш домашний IP-адрес, а 9.9.9.9 - это какой-то шлюз по умолчанию , уже доступный в таблице маршрутизации. Теперь все пакеты с вашего компьютера на внешний IP-адрес будут возвращаться одинаково. Вы можете маршрутизировать все остальное через VPN как обычно. Вы даже можете добавить этот маршрут в конфигурационный файл openvpn. Все супер.
Однако это не так уж и здорово, если ваш домашний IP-адрес меняется (он же динамический адрес) или вам нужно подключаться к своей машине со случайных адресов (несколько пользователей, в пути). В этом случае вы должны пойти тяжелым путем.
Обратите внимание, если вы ничего не сделаете, пакеты ssh будут доставлены на ваш внешний интерфейс (и ip), но они не смогут найти обратный путь, если вы направите их через VPN (на самом деле они могут в зависимости от ваших настроек VPN, но исходный IP-адрес будет другим, и пакет будет удален). Ваша цель - перенаправить некоторые исходящие пакеты на внешний интерфейс, а некоторые - на VPN. Это проблема.
Создайте альтернативную таблицу маршрутизации:
echo "100 secure" >> /etc/iproute2/rt_tables
Заполните и управляйте маршрутизацией:
# route ssh over external iface eth0 to router 9.9.9.9
ip route add default via 9.9.9.9 dev eth0 table secure
# send all packages with fwmark 1 to the secondary routing table
ip rule add fwmark 0x1 table secure
# Mark outgoing ssh packages with the mark 1
iptables -t mangle -A OUTPUT -p tcp --sport 22 -j MARK --set-mark 1
Здесь мы отметим все исходящие пакеты ssh, а затем перенаправим все отмеченные пакеты по альтернативной маршрутизации. Конечно, теперь вы не сможете использовать ssh через vpn, потому что все ответы будут перенаправлены на другой интерфейс. Дело в том, что вы можете создавать произвольно сложные правила iptables и по-разному маршрутизировать их, используя set-mark.
К счастью, у нас есть вещь под названием CONNMARK, которая (используя функцию отслеживания соединений ядра) может отмечать целые соединения туда и обратно (вам понадобится модуль xt_connmark).
# mark incoming ssh *connection* with 1. Here eth0 is your external interface
iptables -A INPUT -m state --state NEW -i eth0 -p tcp --dport 22 -t mangle -j CONNMARK --set-mark 1
# restore connection mark (e.g. mark the packages)
iptables -A OUTPUT -t mangle -j CONNMARK --restore-mark
# send all packages with fwmark 1 to the secondary routing table as before..
ip rule add fwmark 0x1 table secure
Пожалуйста, используйте вышеуказанное в соответствии с вашими текущими настройками после понимания концепций, а не просто копируйте и вставляйте.
Изменить: с точки зрения клиента
Если вы используете свою VPN с того же самого компьютера, с которого установлено ssh-соединение, возникает дополнительная проблема.
По умолчанию одноранговый узел VPN становится шлюзом по умолчанию. Это может легко разорвать ваше существующее соединение, поскольку ваши пакеты ssh будут маршрутизироваться по каналу VPN (сервер будет получать их из интерфейса tun или tap, а не из физического интерфейса eth). Простое решение - не включать параметр шлюза по умолчанию в конфигурацию стороны клиента (или не использовать его). Проталкивайте только маршрут предпочтительных подсетей. Предупреждение: если вы сделали VPN, чтобы скрыть свой (домашний) публичный адрес, возможно, это не то, что вам нужно!