iptables --set-mark - Instrada le diverse porte attraverso diverse interfacce


14

Racconto,
3 interfacce, eth0 (LAN), eth1 (ADSL), eth2 (4G).
eth0 -> eth1: funziona
(porte 80, 443, 4070) eth0 -> eth2: non succede


Questa è una rappresentazione grafica dell'idea:

Porta 80 e 443 tramite eth2
e il resto tramite eth1
inserisci qui la descrizione dell'immagine

Netscheme:

eth0: -ip 10.0.0.1 -net 10.0.0.0/8 -gw 10.0.0.1 (the servers own intf) 
eth1: -ip 192.168.1.74 -net 192.168.1.0/24 -gw 192.168.1.254 
eth2: -ip 192.168.1.91 -net 192.168.0.0/24 -gw 192.168.0.1 






Questo nuovo script reindirizza 22 e 4070 alla tabella corretta, credo.
Tuttavia, dopo essere arrivato a quel tavolo, non viene reindirizzato a eth2.




Questo script funziona, tranne 22 e 4070!

(La porta 80 non è commentata e funziona ma tramite eth1 è sbagliato.)

modprobe iptable_nat
modprobe ip_conntrack

echo "1" > /proc/sys/net/ipv4/ip_forward

iptables -P INPUT ACCEPT
iptables -F INPUT
iptables -P OUTPUT ACCEPT
iptables -F OUTPUT
iptables -P FORWARD DROP
iptables -F FORWARD
iptables -F PREROUTING
iptables -t nat -F
iptables -t mangle -F
iptables -F
# This next line restores any issues trying to connect to something
# if you get weird ACK packets when trying to connect (at least i did)!
iptables -t mangle -A PREROUTING -p tcp -j CONNMARK --restore-mark
ip route flush table main

iptables -A PREROUTING -i eth0 -t mangle -p tcp --dport 22 -j MARK --set-mark 1
###  iptables -A PREROUTING -i eth0 -t mangle -p tcp --dport 80 -j MARK --set-mark 1
iptables -A PREROUTING -i eth0 -t mangle -p tcp --dport 4070 -j MARK --set-mark 1

## Setup routes
# LAN
route add -net 10.0.0.0 netmask 255.0.0.0 dev eth0
# ADSL
route add -net 192.168.1.0 netmask 255.255.255.0 dev eth1
# 4G (Only accessible if marking packages with \x01
route add -net 192.168.0.0 netmask 255.255.255.0 dev eth2
# Default via ADSL
## -- Does the same as ip route below? route add default gw 192.168.1.254


echo "201 eth2.out" >> /etc/iproute2/rt_tables

ip rule add fwmark 1 table eth2.out
ip route add default via 192.168.0.1 dev eth2 table eth2.out
ip route add default via 192.168.1.254 dev eth1



## Setup forwards
# From 4G to LAN
iptables -A FORWARD -i eth2 -o eth0 -m state --state ESTABLISHED,RELATED,NEW -j ACCEPT
# From ADSL to LAN
iptables -A FORWARD -i eth1 -o eth0 -m state --state ESTABLISHED,RELATED,NEW -j ACCEPT
# From LAN to ADSL (Default route out)
# - Note: If marked packages is sent to ADSL they will be mangled and rerouted to 4G
iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth2 -j MASQUERADE









Vecchia sceneggiatura:


  Ignore everything below unless you're interested in retracing my steps!!




Ho creato uno script router.sh per configurare il mio ambiente nel caso in cui faccio qualcosa di brutto. Ho 3 porte che voglio inviare a una connessione 4G e il resto tramite una connessione ADSL fissa. Per fare questo, ho incaricato iptables di manipolare i pacchetti sulla rotta predefinita e inviarli tramite la mia interfaccia 4G se --dport == 443 | 80 | 4070

Tuttavia, questo non funziona; Vengo comunque instradato attraverso il mio telefono fisso, non importa quale.

Ecco come appare la mia sceneggiatura:

#!/bin/bash

## routing tables
# wireless = 4G via eth2
# adsl = adsl via eth1

modprobe iptable_nat
modprobe ip_conntrack

echo "1" > /proc/sys/net/ipv4/ip_forward

iptables -P INPUT ACCEPT
iptables -F INPUT
iptables -P OUTPUT ACCEPT
iptables -F OUTPUT
iptables -P FORWARD DROP
iptables -F FORWARD
iptables -t nat -F
ip route flush table main
ip route flush table wireless
ip route flush table adsl

## Setup routing tables
# ADSL
ip route add table adsl to 192.168.1.0/24 dev eth1
# 4G
ip route add table wireless to 192.168.0.0 dev eth2
ip rule add fwmark 0x1 table wireless

## Setup routes
# LAN
route add -net 10.0.0.0 netmask 255.0.0.0 dev eth0
# ADSL
route add -net 192.168.1.0 netmask 255.255.255.0 dev eth1
# 4G (Only accessible if marking packages with \x01
route add -net 192.168.0.0 netmask 255.255.255.0 dev eth2
# Default via ADSL
route add default gw 192.168.1.254


## Forward ports into the LAN
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j DNAT --to 10.0.0.3:80


## Lets mark all packets we want for 4G forward
# HTTPS
iptables -A OUTPUT -t mangle -o eth1 -p tcp --dport 443 -j MARK --set-mark 1
# HTTP
iptables -A OUTPUT -t mangle -o eth1 -p tcp --dport 80 -j MARK --set-mark 1
# Spotify
iptables -A OUTPUT -t mangle -o eth1 -p tcp --dport 4070 -j MARK --set-mark 1

## Setup forwards
# From 4G to LAN
iptables -A FORWARD -i eth2 -o eth0 -m state --state ESTABLISHED,RELATED,NEW -j ACCEPT
# From ADSL to LAN
iptables -A FORWARD -i eth1 -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
# From LAN to ADSL (Default route out)
# - Note: If marked packages is sent to ADSL they will be mangled and rerouted to 4G
iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT
iptables -A FORWARD -j LOG
#iptables --table nat --append POSTROUTING --out-interface eth2 --jump SNAT --to-source "192.168.1.74"
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

Ho anche provato ad aggiungere questi 3 al bottomg dello script:

iptables -t nat -A POSTROUTING -o eth2 -p tcp --dport 80 -j SNAT --to "192.168.0.91"
iptables -t nat -A POSTROUTING -o eth2 -p tcp --dport 443 -j SNAT --to "192.168.0.91"
iptables -t nat -A POSTROUTING -o eth2 -p tcp --dport 4070 -j SNAT --to "192.168.0.91"

Anche provato senza successo:

iptables -A PREROUTING -t mangle -i eth0 -p tcp --dport 80 -j MARK --set-mark 1

Ultimo ma non meno importante, ho provato:

## Lets mark all packets we want for 4G forward
# HTTPS
iptables -A POSTROUTING -t mangle -o eth1 -p tcp --dport 443 -j MARK --set-mark 1
# HTTP
iptables -A POSTROUTING -t mangle -o eth1 -p tcp --dport 80 -j MARK --set-mark 1
# Spotify
iptables -A POSTROUTING -t mangle -o eth1 -p tcp --dport 4070 -j MARK --set-mark 1

Il routing funziona, posso navigare sul web, ascoltare musica e quant'altro, ma lo sto facendo attraverso l'interfaccia sbagliata. Ho cercato su Google per molto tempo e ho trovato pezzi per capire cosa sto facendo e perché lo sto facendo. Potrei fare il traffic shaping tramite tc ma se è possibile contrassegnare i pacchetti in iptables mi aiuterebbe molto.

La mia ipotesi è che sto facendo l'ordine sbagliato sulle diverse regole, principalmente la parte MASQUERADE ? o se anche quello dovesse esserci?

Qualcuno può spiegare come dire la porta DNAT , tcp: 80 da un'interfaccia esterna (uno o entrambi i protocolli) a uno spazio di indirizzi interno 10.0.0.0?



Uscite:

root@Netbridge:~# route -n Kernel IP routing table Destination    

Gateway         Genmask         Flags Metric Ref    Use Iface<br>
0.0.0.0         192.168.1.254   0.0.0.0         UG    0      0        0 eth1<br>
10.0.0.0        0.0.0.0         255.0.0.0       U     0      0        0 eth0<br>
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth2<br>
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1


root@Netbridge:~# ifconfig

eth0      Link encap:Ethernet  HWaddr 00:0c:29:7e:9e:4e  
          inet addr:10.0.0.1  Bcast:10.255.255.255  Mask:255.0.0.0

eth1      Link encap:Ethernet  HWaddr 00:0c:29:7e:9e:58  
          inet addr:192.168.1.74  Bcast:192.168.1.255  Mask:255.255.255.0

eth2      Link encap:Ethernet  HWaddr 00:0c:29:7e:9e:62  
          inet addr:192.168.0.91  Bcast:192.168.0.255  Mask:255.255.255.0

Seguite queste istruzioni:
output-traffic-on-different-interfaces-based-on-destination-por
iptables-forward-specific-port-to-specific-nic
Tra alcuni altri thread correlati.


Mi dispiace, ma c'è un motivo per non associare apache solo all'indirizzo localhoste eth2all'interfaccia?
— Jan Marek,

@JanMarek: qui non si parla di apache. E per tua informazione, l'associazione di un socket ethXall'indirizzo IP di un utente impedirà agli host della ethXlan di accedere al server locale utilizzando ethYl'indirizzo IP e non impedirà agli host ethYdi accedere al server utilizzando ethXl'indirizzo IP. Ricorda che Linux utilizza un modello host debole.
— BatchyX,

OK, ci sono più server Web possibili, non solo server Apache ... Tuttavia, quel server Web vincolante sull'interfaccia eth2 può essere una soluzione semplice. Ma posso sbagliarmi, lo so.
— Jan Marek,

Risposte:


5

BatchyX fornisce già alcune ottime spiegazioni su iptables e routing, quindi eserciterò la mia pigrizia e andrò direttamente allo script.

Dovrebbe NAT tutto il traffico verso la porta da 80.443,22,4070 a 192.168.0.91. Tutto il resto sarà NAT attraverso 192.168.1.254.

Eseguo nuovamente i test e finisco per seguire questa guida . Ciò che manca in quella guida sono le ultime 3 righe della mia sceneggiatura. Che ho scoperto da un'altra porta, ma ho perso la traccia di quel collegamento.

È uno script funzionante testato.

È necessario il percorso predefinito

Una cosa che non ho inserito nello script è l'impostazione del percorso predefinito. Dovrebbe essere

route add default gw 192.168.1.254

Quando lo fai route -n, dovrebbe essere l'unica route predefinita (Dest: 0.0.0.0)

0.0.0.0    192.168.1.254    0.0.0.0    UG    0    0    0    eth1

fw-router.sh

# Ripristina / Svuota iptables
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P AVANTI IN AVANTI
iptables -P ACCETTA L'USCITA

# Reset / Flush / Setup IP Route (tabella 4)
tabella di instradamento ip route 4
percorso ip mostra la tabella principale | grep -Ev ^ default | mentre leggi ROUTE; percorso ip aggiungi tabella 4 $ ROUTE; fatto
ip route aggiunge la tabella 4 di default tramite 192.168.0.1

#Mark Packet con D.Port corrispondente
iptables -t mangle -A PREROUTING -p tcp --dport 22 -s 10.0.0.0/24 -j MARK --set-mark 4
iptables -t mangle -A PREROUTING -p tcp --dport 80 -s 10.0.0.0/24 -j MARK - set-mark 4
iptables -t mangle -A PREROUTING -p tcp --dport 443 -s 10.0.0.0/24 -j MARK --set-mark 4
iptables -t mangle -A PREROUTING -p tcp --dport 4070 -s 10.0.0.0/24 -j MARK --set-mark 4

#SNAT Rules
iptables -t nat -A POSTROUTING -o eth1 -j SNAT - to-source 192.168.1.74
iptables -t nat -A POSTROUTING -o eth2 -j SNAT - to-source 192.168.0.91

#IP Route
regola ip aggiungi fwmark 4 tabella 4
cache di instradamento ip route

#IP Stack
#Questa è la parte mancante della guida
echo 1> / proc / sys / net / ipv4 / ip_forward
per f in / proc / sys / net / ipv4 / conf / * / rp_filter; echo 0> $ f; fatto
echo 0> / proc / sys / net / ipv4 / route / flush

PS1: in breve, MASQUERADEnon funziona (nella maggior parte dei casi, e sicuramente nel tuo caso) per NAT con più IP esterni che richiedono un qualche tipo di bilanciamento del carico o DNAT per gestire il traffico in entrata. È necessario SNATper il controllo della direzione.

PS2: iptables puri non è sufficiente.


Prima di tutto, applausi per essere andato direttamente alla sceneggiatura :) Stasera ci provo mentre torno nell'ambiente in cui andrà a finire!
— Torxed il

hmm, potrebbe aver bisogno di una revisione pesante. Fammi sapere risultato.
— John Siu,

Revisionato, dovrebbe funzionare ora.
— John Siu,

Dolce, ti
— risponderò tra

Ti amo così tanto mal di testa e l'hai risolto! Grazie!
— Torxed

6

Nota: ho preso in considerazione solo la prima sceneggiatura, ignorando quella precedente.

  • Non è necessario modprobe i moduli netfilter a mano con gli attuali iptables. Ciò è necessario solo per i tracker di connessione personalizzati.
  • Non confondere routee ip route. Questo è puro male. Basta usare ipovunque e dimenticare ifconfigeroute
  • /etc/iproute2/rt_tablesnon viene ripristinato tra i riavvii. Aggiungere la stessa voce più e più volte non è una buona idea, devi solo farlo una volta. Ricorda che rt_tablesbasta definire gli alias dei nomi in valori numerici, non cambia alcuna configurazione.

  • Ora per iptables: Nella tua FORWARDcatena, i pacchetti vengono rilasciati dalla LAN al 4G. Questo non va bene. il FORWARDgancio viene utilizzato dopo aver eseguito il routing. A questo punto, viene eseguito tutto il routing dei criteri ed è già noto se il pacchetto debba essere inviato a 4G o ADSL. Non è stato eseguito alcun reinstradamento in FORWARDo dopo FORWARD(beh, tecnicamente, il reinstradamento può essere eseguito POSTROUTINGin casi gravi, ma tornando al punto).

Ora per il tuo instradamento: ricorda che Ubuntu abilita il filtraggio del percorso inverso per impostazione predefinita. Il filtro del percorso inverso funziona come segue: Quando il kernel riceve un pacchetto (può essere inoltrato o meno) da un'interfaccia A, inverte l'indirizzo di origine e l'indirizzo di destinazione e controlla se il pacchetto risultante deve essere instradato attraverso l'interfaccia A. In caso contrario, il pacchetto viene eliminato come tentativo di spoofing dell'indirizzo.

Per i pacchetti ricevuti da eth0, questo non è un problema. Per i pacchetti ricevuti eth1, anche questo non è un problema, perché quando si inverte l'indirizzo IP di origine e l'indirizzo IP di destinazione, il kernel farà il percorso predefinito nella tabella main. Per i pacchetti ricevuti da eth2, che non contrassegnate, questo è un problema, poiché il kernel colpirà la rotta predefinita nella tabella maine considera che questi pacchetti dovrebbero essere stati ricevuti eth1. La soluzione più semplice è disabilitare il filtro del percorso inverso su eth1:

sysctl -w net.ipv4.conf.eth1.rp_filter=0

Tutti i grandi commenti e sì, ci sono alcune logiche errate da parte mia, ad esempio aggiungendo ogni volta a rt_tables e soprattutto non cancellando determinate tabelle come dovrei, ma ci arriverò :) Darò tutto e vedrò se funziona, in tal caso, +50 per te e, soprattutto, hai salvato un uomo dietro dall'essere tagliato a pezzi e in pezzi! :)
— Torxed

1
Di seguito la sceneggiatura funziona ma tu meriti anche tutta la gratitudine, mi hai dato una cosa o due a cui pensare e rp_filter = 0 mi ha aiutato molto! : D
— Torxed

@BatchyX molto istruttivo, vota anche a te.
— John Siu,

@Torxed Il post che ho visto menzionare rp_filter per TUTTA l'interfaccia deve essere disabilitato. Non sono sicuro che funzioni diversamente.
— John Siu,

@JohnSiu: devi solo disabilitare il filtro rp sulle interfacce dove è problematico. In tal caso, è eth1, perché non è possibile accedere a tale interfaccia quando non sono impostati i segni. eth2 non ha questo problema, poiché la route predefinita va in quella interfaccia. Per eth0, in realtà è utile mantenere abilitato il filtro rp, altrimenti qualcuno sulla LAN potrebbe creare un pacchetto IP con un indirizzo di origine su Internet e un indirizzo di destinazione sulla LAN, e il router lo accetterebbe felicemente, e inoltrarlo torna a ... eth0.
— BatchyX il
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.