Definindo a classe de tráfego nos pacotes de retorno

Question

Eu tenho uma topologia de rede:

Server <-> router1 <-> router2 <-> router3 <-> edgeRouter <-> "internet"

Todos os roteadores são baseados em linux e suportam iptables.

O servidor define as classes de tráfego com iptables ( --set class X:Y ) e os roteadores fazem um "roteamento" baseado na classe definida. (A classe depende do aplicativo de origem).

Os roteadores de borda encaminham os pacotes via nosso ISP para a Internet e recebem os pacotes de retorno (resposta). O recieves respostas do curso não tem nenhuma classe de tráfego definida.

É possível usar uma regra iptables no roteador de borda (mangle, ou algo semelhante), para rastrear os pacotes de retorno (estilo NAT, pacotes a partir de conexões "ESTABLISHED") e para marcar os pacotes de retorno com o mesma classe de tráfego que o pacote de origem? Ativar o NAT no roteador de borda não é um problema.

TLDR: Como usar o iptables para classificar os pacotes de entrada com a mesma classe de saída da mesma conexão.

    

Answer 1

Como seus pacotes de egresso possuem o conjunto de classes baseado no aplicativo (e acredito que cada aplicativo use um determinado conjunto de portas TCP / UDP), você pode reclassificar os pacotes recebidos com base nessas portas.

por exemplo. para reclassificar uma sessão HTTP estabelecida (saída), em edgeRouter:

iptables -t mangle -A INPUT -i [WANIF] -m state --state ESTABLISHED,RELATED -p tcp -m tcp --sport 80 -j DSCP --set-dscp-class cs3

NB: Pode precisar usar a tabela FORWARD ao invés de INPUT ...

Mas - Para rastrear pacotes de egresso, determinar qual classe eles tinham na saída e então aplicar essa mesma classe para ingresso de pacotes do mesmo fluxo - ainda possível, mas uma montanha de trabalho e possivelmente um módulo de filtro de rede customizado com conntrack.

    

Answer 2

O que você define com --set class X:Y ? Classe do que exatamente? Eu procurei na página man do iptables mas não achei similar ao que você descreveu. Eu acho que você pode querer fazer algo assim:

1. Marque o campo TOS dos pacotes IP em "Servidor".
2. Deixe os roteadores tratarem o pacote especialmente.

3. Em "edgeRouter", faça o seguinte:

     # If a packet arrives from LAN, is marked and we know nothing about the
     #+ connection, then mark the connection
   iptables -t mangle -A PREROUTING -i $LAN_IF -m tos --tos $TOS_VAL -m \
     connmark \! --mark $TOS_VAL -j CONNMARK --set-xmark $TOS_VAL
   
     # Reset the TOS value when going out to prevent strange interpretation
   iptables -t mangle -A POSTROUTING -o $WAN_IF -m tos --tos $TOS_VAL \
     -j TOS --set-tos 0x00
   
     # If a packet arrives from WAN and the connection is marked, then mark
     #+ the packet so that the routers in LAN know how to deal with it
   iptables -t mangle -A PREROUTING -i $WAN_IF -m connmark --mark $TOS_VAL \
     -j TOS --set-tos $TOS_VAL
   

Answer 3

TLDR: How to use iptables to classify ingress packets with the same class as egress for the same connection.

Não está totalmente claro por sua pergunta a que método de classificação você está se referindo, mas, em geral, se estamos falando de modelagem de tráfego usando tc e disciplinas de enfileiramento, aplica-se o seguinte.

act_connmark

Como o processamento do qdisc de ingresso é feito antes do netfilter, você não pode classificar diretamente o tráfego de entrada usando o iptables (sem recompilar seu kernel com o IMQ, veja abaixo). No entanto, você pode classificá-lo indiretamente usando o rastreamento de conexão. Se disponível em seu kernel, você pode usar o módulo act_connmark, projetado para esse propósito exato, que adiciona uma ação connmark aos filtros tc que o suportam.

# 0. Load modules and IFB device
modprobe act_connmark
modprobe ifb
ip link set ifb0 up

# 1. Classify packets by marking them
iptables -t mangle -A POSTROUTING -p tcp --sport 22 -j MARK --set-mark 1

# 2. Append rule to save the packet mark to the connection mark
iptables -t mangle -A POSTROUTING -j CONNMARK --save-mark

# 3. Restore the connection mark to the packet mark with 'action connmark'
#    before redirecting to the ifb-device
tc qdisc add dev eth0 handle ffff: ingress
tc qdisc add dev ifb0 handle 1: root
tc filter add dev eth0 parent ffff: prio 1 \
   protocol ip u32 match u32 0 0 flowid ffff:1 \
   action connmark \
   action mirred egress redirect dev ifb0

# 4. Apply filters to classify packets based on their mark
# ... setup qdiscs and classes as usual on ifb0... then
tc filter add dev ifb0 parent 1: prio 1 protocol ip handle 1 fw classid 1:01

• Exemplo no ArchLinux Wiki

IMQ

O IMQ (Intermediate Queuing Device) contorna o fluxo normal de tráfego no kernel, como eu o entendo, retornando através de um dispositivo virtual após o processamento do netfilter. Ele não é mesclado com a árvore do kernel, portanto, não é incluído na maioria das distribuições e requer o patch e a compilação do kernel. Se você fizer isso, funcionaria algo assim:

# classify and save mark in POSTROUTING as before... then
iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark
iptables -t mangle -A PREROUTING -j IMQ --todev 0

# ... setup qdiscs and classes as usual on imq0 ... then
tc filter add dev imq0 parent 1: prio 1 protocol ip handle 1 fw classid 1:01

Isso também permitiria que você fizesse classificações mais avançadas no ingresso usando o iptables, o que pode ser muito complicado usando filtros simples do u32, como intervalos de porta arbitrários. No entanto, não posso falar sobre o desempenho ou a elegância dessa solução, suponho que exista uma razão pela qual ela nunca foi mesclada.

• IMQ no GitHub