У меня есть две машины, A и B, под управлением RHEL Linux. У каждой машины есть сетевая карта 1Gig, подключенная к тому, что я называю "LAN" сетью. У каждой машины есть сетевая карта 10Gig, которая подключена к сети, которую я называю «BIGDATA». Эти сети не связаны друг с другом, кроме как через эти машины.
У меня есть оптоволоконные ответвители на интерфейсе 10Gig A в сети BIGDATA. Ответвления ведут к серверу захвата, где я хочу записывать все входящие и исходящие данные. Изначально весь TCP, но, возможно, в будущем пригодится какой-нибудь UDP.
В целях разработки и тестирования я хочу запустить обе стороны TCP-разговора на A и все же записать разговор с помощью этих нажатий. У разработчиков, которые будут использовать эту настройку, не будет учетных записей на B (по крайней мере, это моя цель).
На мой взгляд, суперпользователь должен иметь возможность настроить какую-то пересылку / ретрансляцию на B, что позволит клиенту на A подключаться к серверу на A, но через оптоволокно. То есть трафик идет от A к B в сети LAN, а затем обратно к A в сети BIGDATA. Обратный трафик возвращается тем же путем.
До сих пор я пытался использовать ssh-туннелирование. подобно A:~ $ssh B -L 8051:<A's-BIGDATA-IP>:3434 -N. Это действительно отлично работает для перехвата трафика от клиента к серверу. Но, к сожалению, ответы сервера находят способ просто оставаться локальным и никогда не появляться в оптоволокне. Если посмотреть на wirehark, пакеты знают свой IP-адрес назначения и не чувствуют себя обязанными возвращать туннель.
я нашел этот ответ, но я считаю, что все решения требуют, чтобы оба интерфейса были в одной сети. Может быть, семена моего решения есть, но я не могу их найти.
Думаю, я мог бы написать это с нуля на C, создав программу для запуска на B, чтобы принимать TCP-соединения на интерфейсе LAN, инициировать другое TCP-соединение на интерфейсе BIGDATA, обратно к A, а также пересылать ответы. Он будет копировать только полезную нагрузку TCP, чего было бы достаточно для моих целей.
Есть ли классный инструмент, который уже выполняет эту пересылку / ретрансляцию?
Есть ли способ заставить ssh-туннелирование работать так, как я хочу для обратного трафика?
Посмотри на EtherPuppet, возможно в сочетании с Scapy; EtherPuppet описывается как
небольшая программа для Linux, которая создаст куклу вуду для интерфейса Ethernet.
...
все, что видит реальный интерфейс, будет видно виртуальному. Все, что будет отправлено в виртуальный интерфейс, будет отправлено реальным.
Скапи описывается как
мощная интерактивная программа обработки пакетов. Он может подделывать или декодировать пакеты широкого ряда протоколов, отправлять их по сети, захватывать их, сопоставлять запросы и ответы и многое другое.
Источник и назначение NAT
Вы можете перенаправлять трафик туда и обратно с помощью комбинации DNAT и SNAT, используя ту же идею, что и ответ ты нашел при условии, что вы не возражаете против искажения пакетов, которые вы захватываете. Захваты будут иметь IP-адрес назначения или src IP B, но похоже, что вы уже сделали это со своим клиентом пересылки. Я полагаю, преимуществом NAT будет скорость, все остается в пространстве ядра.
В этом примере клиент на A подключается к серверу на A: BIGDATA: 3434. Правила NAT перенаправляют соединение от A к B, затем B пересылает обратно к A, устанавливая источник как B, чтобы установить обратный путь. Наверное, взгляните на руководство по netfilter если вы не знакомы с таблицами NAT.
Убедитесь, что на B включена переадресация IP-адресов:
sysctl -w net.ipv4.ip_forward=1
echo 1 > /proc/sys/net/ipv4/ip_forward
трафик идет от A к B в сети LAN
# On A, forward local traffic for local service out LAN to B.
iptables -t nat -A OUTPUT -p tcp -d A:BIGDATA --dport 3434 -j DNAT --to-destination B:LAN
затем вернитесь к A в сети BIGDATA.
# On B, forward the traffic to back to A over fibre
iptables -t nat -A PREROUTING -p tcp -d B:LAN --dport 3434 -j DNAT --to-destination A:BIGDATA
Обратный трафик возвращается тем же путем
# On B, set the source address for this traffic to B fibre
iptables -t nat -A POSTROUTING -d A:BIGDATA -p tcp --dport 3434 -j SNAT --to-source B:BIGDATA
Отслеживание соединения NAT заботится о последнем сопоставлении с исходным IP-адресом источника.
Хотя это не тот ответ, на который я надеялся найти, в итоге я выбрал свой собственный.
Я написал программу для запуска на B, которая будет принимать соединения через интерфейс LAN и инициировать соединения через интерфейс BIGDATA. Программа копирует полезные данные TCP в новые исходящие сообщения. То же самое и с ответами в обратном направлении. Это не сохраняет информацию заголовка (например, исходный IP-адрес) - в моем случае я думаю, что это хорошо, так как обратный трафик не сокращается.
Это работает, хотя это было проблемой для чего-то, что я считаю таким простым. Я бы опубликовал исходник, но он довольно длинный и, вероятно, не очень хорошо написан.
Я собираюсь оставить ответы непринятыми, в надежде, что кто-нибудь в конце концов наткнется на них с идеальным решением!