У меня есть следующая сеть:

.__________. ._______.
| вм-кли | <==> <enp1s0| vm-gw |enp2s0> <==> Интернет
·-------- · · ·------- ·

vm-cli имеет адрес 192.168.255.2; enp1s0@vm-gw имеет адрес 192.168.255.1; enp2s0@vm-gw, не имеет значения.

Я хочу все интернет-трафик проходит через Tor. Для этого я настраиваю Tor на использование прозрачного сокета и использую политику маршрутизации для перенаправления на него трафика.Сначала я добавляю правило маршрутизации и определяю альтернативную таблицу маршрутизации, которая направляет все на локальный хост:

ip правило добавить fwmark 1 таблица 1
ip route add local 0.0.0.0/0 dev lo таблица 1

Затем я сначала настраиваю брандмауэр для перенаправления вм-гв вывод на прокси:

прокси таблицы {
    # пропускаем перенаправленный трафик на прокси
    переадресация цепи {
        type filter фильтр приоритета предварительной маршрутизации; политика принять;
        ip протокол tcp mark 1 tproxy на: 9040
    }
}

локальная таблица {
    # использовать целевой NAT для DNS-трафика, так как он не работает с tproxy
    цепочка dstNAT {
        type nat hook выходной приоритет mangle; политика принять;
        Перенаправление домена udp dport на: 9053
    }

    # пометить весь не-Tor-трафик, идущий на интерфейс, подключенный к Интернету, как перенаправленный
    цепочка перенаправления {
        тип route hook выходной приоритет mangle; политика принять;
        oif enp2s0 skuid != tor ip protocol tcp meta mark set 1
    }
}

Хорошо, я тестирую это с копать землю и завиток: все идет через Tor.

Что не работает

Теперь я добавляю следующее правило для перенаправления трафика из вм-кли или любой другой хост, использующий вм-гв как шлюз:

удаленный стол {
    цепочка перенаправления {
        type nat hook prerouting priority mangle; политика принять;
        # целевой NAT-трафик DNS
        Перенаправление домена udp dport на: 9053
        # помечаем tcp-трафик от enp1s0 для политик маршрутизации
        iif enp1s0 ip-протокол tcp метаметка набор 1
    }
}

Я пытаюсь сделать DNS-запрос, он работает. Я пытаюсь сделать HTTP-запрос, но ответа нет…

Отслеживание пакетов

Отслеживая пакеты и просматривая журнал Tor, я вижу, что вм-кли TCP-трафик попадает в Tor. Но завиток на вм-кли кажется, что он не видит ответа HTTP.

Поэтому я пытаюсь отследить ответ HTTP-сервера. Поскольку он исходит от Tor, я не увижу никакого HTTP-трафика на входе, но увижу его в вм-гв вывод. Затем я добавляю следующее правило для трассировки:

локальная таблица {
    выход цепи {
        фильтр приоритета вывода обработчика типа фильтра; политика принять;
        tcp sport 80 ip daddr 192.168.255.2 мета nftrace набор 1
    }

    [ ¦ ]
}

Делает завиток http://perdu.com на вм-кли Я получаю следующую трассировку вм-гв:

trace id 2fc29112 ip локальный выходной пакет: oif "enp1s0" ip saddr 208.97.177.124 ip saddr 192.168.255.2 ip dscp cs0 ip ecn not-ect ip ttl 64 ip id 0 ip length 60 tcp sport 80 tcp dport flags 57082 = tcpx12 = tcpx12 TCP-окно 65160
trace id 2fc29112 ip local output rule tcp sport 80 ip saddr 192.168.255.2 meta nftrace set 1 (продолжение вердикта)
trace id 2fc29112 ip local output вердикт продолжить
идентификатор трассировки 2fc29112 ip локальная политика вывода принимает

А там, как мне кажется, все правильно… есть ответ от HTTP-сервера, пункт назначения вм-кли с использованием enp1s0 интерфейс.

Я пытаюсь отследить пакет на вм-кли. Там мы можем увидеть исходящий пакет и его ответ:

trace id d9101d30 Выходной пакет IP-фильтра: oif "enp2s0" ip saddr 192.168.255.2 ip saddr 208.97.177.124 ip dscp cs0 ip ecn not-ect ip ttl 64 ip id 40142 ip length 60 tcp sport 57124 tcp dport 80 TCP-окно 64240 
идентификатор трассировки d9101d30 правило вывода ip-фильтра tcp dport 80 meta nftrace set 1 (продолжение вердикта)
trace id d9101d30 ip filter вывод вердикта продолжить
идентификатор трассировки d9101d30 политика вывода IP-фильтра принять

идентификатор трассировки 51163d64 пакет предварительной маршрутизации ip-фильтра: iif "enp2s0" ether saddr 52:54:00:bd:38:6d ether saddr 52:54:00:f0:a2:51 ip saddr 208.97.177.124 ip saddr 192.168.255.2 ip dscp cs0 ip ecn not-ect ip ttl 64 ip id 0 длина ip 60 tcp sport 80 tcp dport 57124 tcp flags == 0x12 tcp window 65160 
идентификатор трассировки 51163d64 правило предварительной маршрутизации ip-фильтра мета-nftrace set 1 (продолжение вердикта)
trace id 51163d64 ip filter prerouting вердикт продолжить 
идентификатор трассировки 51163d64 политика предварительной маршрутизации IP-фильтра принять

Я вижу:

1. исходящий пакет с 192.168.255.2:57124 на 208.97.177.124:80
2. ответ с 208.97.177.124:80 на 192.168.255.2:57124

Адреса и порты совпадают… завиток --подробный сообщает, что соединение установлено, но почему HTTP-запрос не получает ответа?

сетевая кошка подтверждает, что ответ HTTP не доходит до приложения. я тоже пробовал хинг, и с настройкой tproxy я получаю дубликаты:

hping perdu.com --destport 80 --syn --count 10
HPING perdu.com (enp2s0 208.97.177.124): набор S, 40 заголовков + 0 байтов данных
len=44 ip=208.97.177.124 ttl=64 DF id=0 sport=80 flags=SA seq=0 win=64240 rtt=9,8 мс
len=44 ip=208.97.177.124 ttl=64 DF id=0 sport=80 flags=SA seq=1 win=64240 rtt=9,8 мс
ДУП! len=44 ip=208.97.177.124 ttl=64 DF id=0 sport=80 flags=SA seq=0 win=64240 rtt=1049,9 мс
len=44 ip=208.97.177.124 ttl=64 DF id=0 sport=80 flags=SA seq=2 win=64240 rtt=9,8 мс
ДУП! len=44 ip=208.97.177.124 ttl=64 DF id=0 sport=80 flags=SA seq=1 win=64240 rtt=1099,9 мс
len=44 ip=208.97.177.124 ttl=64 DF id=0 sport=80 flags=SA seq=3 win=64240 rtt=29,8 мс
ДУП! len=44 ip=208.97.177.124 ttl=64 DF id=0 sport=80 flags=SA seq=2 win=64240 rtt=1059,9 мс
ДУП! len=44 ip=208.97.177.124 ttl=64 DF id=0 sport=80 flags=SA seq=0 win=64240 rtt=3120,0 мс
len=44 ip=208.97.177.124 ttl=64 DF id=0 sport=80 flags=SA seq=4 win=64240 rtt=29,8 мс
ДУП! len=44 ip=208.97.177.124 ttl=64 DF id=0 sport=80 flags=SA seq=3 win=64240 rtt=1079,9 мс

--- perdu.com держит статистику ---
5 пакетов передано, 10 пакетов получено, -100% потеря пакетов
туда-обратно мин./средн./макс. = 9,8/749,9/3120,0 мс