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.