Směrování zdroje Linuxu, silný model systému / silný model hostitele?

Může linuxový stroj s více domovy implementovat skutečný model Strong ES?

Konkrétní případ použití

Mám systém s pěti různými rozhraními, z nichž každé je připojeno ke stejné podsíti, tedy ke stejné bráně k internetu.

• Chtěl bych naslouchat na každém rozhraní samostatně na stejném portu a zajistit, aby pakety vždy odcházely ze stejného rozhraní, do kterého přišly, a zajistit, aby pakety, které se snaží přijít do „nesprávného“ rozhraní, byly zahozeny.
• Chtěl bych mít možnost vázat se na každé rozhraní a vytvářet odchozí připojení k internetovým destinacím, které vždy pocházejí ze stejné zdrojové IP adresy, na kterou se vážu. Například

  curl --interface interface_ip http://ipecho.net/plain

  by měl vždy zobrazovat stejnou IP adresu, ke které jsem se připojil pomocí --interface .

• Statické trasy mohou být problematické kvůli použití DHCP na jednom z těchto rozhraní.

RFC 1122

Z RFC 1122 – Požadavky na internetové hostitele – Komunikační vrstvy, oddíl 3.3.4.2 – Požadavky na multihoming:

Implementátoři internetových hostitelů použili dva různé
koncepční modely pro multihoming, stručně shrnuté
v následující diskusi. Tento dokument nestojí
na tom, který model je preferován; zdá se, že každý má své
místo. Tato ambivalence se odráží v tom, že problémy (A)
a (B) jsou nepovinné.

• Silný model ES

  Model Strong ES (End System, tj. hostitel)
  zdůrazňuje rozdíl mezi hostitelem a bránou (ES/IS),
  , a proto by v
  otázkách nahradil MUST MUST (A ) a (B) výše. Má tendenci modelovat
  hostitele s více domovy jako sadu logických hostitelů v
  stejném fyzickém hostiteli.

  Pokud jde o (A), zastánci modelu Strong ES
  poznamenávají, že mechanismy automatického směrování internetu
  nemohly nasměrovat datagram do
  fyzického rozhraní, které neodpovídalo
  cílová adresa.

  V rámci modelu Strong ES je výpočet trasy
  pro odchozí datagram mapování:

       route(src IP addr, dest IP addr, TOS) -> gateway
  

  Zde je zdrojová adresa zahrnuta jako parametr
  za účelem výběru brány, která je přímo
  dosažitelná na odpovídajícím fyzickém rozhraní.
  Upozorňujeme, že tento model logicky vyžaduje, aby
  obecně existovala alespoň jedna výchozí brána a
  pokud možno více výchozích hodnot, pro každou zdrojovou IP
  adresu.

Slabý model ES

Tento pohled snižuje důraz na rozlišení ES/IS, a
by proto nahradil MUSÍ NEV
v
otázkách (A) a (B). Tento model může být
přirozenější pro hostitele, kteří odposlouchávají protokoly směrování brány
, a je nezbytný pro hostitele, kteří mají
integrovanou funkci brány.

Slabý model ES může způsobit selhání mechanismu přesměrování
. Pokud je datagram odeslán s fyzickým
rozhraním, které neodpovídá
cílové adrese, brána prvního přesměrování si
neuvědomí, kdy potřebuje odeslat přesměrování. Na druhou stranu
pokud má hostitel vestavěnou funkci brány
, pak má informace o směrování
bez naslouchání přesměrování.

V modelu Weak ES je výpočet trasy pro
odchozí datagram mapování:

     route(dest IP addr, TOS) -> gateway, interface

Linux je ve výchozím nastavení modelem Weak ES, zatímco FreeBSD a další varianty Unixu fungují jako systémy Strong ES. Existuje nějaký způsob, jak zajistit, aby se choval více jako systém Strong ES?

Co sysctl nebo by bylo nutné nastavit konfiguraci v době kompilace, aby se ve výchozím nastavení chovala jako Strong ES, aniž by bylo nutné přidat konkrétní pravidla směrování pro jakékoli nové rozhraní, které přidáte? Vím, že můžeme provést přísné filtrování zdrojové trasy pomocí net.ipv4.conf.default.rp_filter = 1 , ale zdá se, že je v tom mnohem víc. Jak mohu ve výchozím nastavení provést směrování podle zdroje?

Přijatá odpověď:

Pouhé přidání pravidel brány firewall v tomto případě nebude stačit. Chcete, aby systém směroval provoz, jako by to byly dva nezávislé systémy, které shodou okolností sdílejí stejný hardware a procesy:přesně to je model Strong ES.

Související:Linux – manuálová stránka nalezena až po spuštění s rootem?

Při zaměřování na Strong ES Model v Linuxu budete nejprve potřebovat tato nastavení sysctl:

net.ipv4.conf.all.arp_filter=1 
net.ipv4.conf.all.arp_ignore=1 # or even 2
net.ipv4.conf.all.arp_announce=2

Tato nastavení způsobí, že se ARP bude chovat tak, jak je vhodné s modelem Strong ES, tj. když je přijat požadavek ARP, odpoví pouze rozhraní s přesnou požadovanou adresou, a to pouze v případě, že by provoz na původní adresu byl ve skutečnosti odeslán přes tuto konkrétní adresu. rozhraní.

Potom, protože máte pět rozhraní, která chcete, aby se chovala jinak, pokud jde o směrování, budete muset nastavit pět vlastních směrovacích tabulek. K jejich identifikaci můžete použít čísla, ale obecně je jasnější pro ně specifikovat názvy. Vyberte tedy čísla pro každou z nich mezi 1 a 252 a některá vhodná jména. (Čísla 0, 253, 254 a 255 jsou vyhrazena.)

Vyberme například 100 =rtable0, 101 =rtable1, 102 =rtable2, 103 =rtable3 a 104 =rtable4. Přidejte tato čísla a jména na konec /etc/iproute2/rt_tables soubor:

# ...default stuff above...
100    rtable0
101    rtable1
102    rtable2
103    rtable3
104    rtable4

Potom naplňte každou vlastní směrovací tabulku minimální sadou položek směrování vhodných pro každé rozhraní. (Skutečné hodnoty nahrazuji snad popisně pojmenovanými názvy proměnných prostředí.)

ip route add $ETH0_NET dev eth0 proto static src $ETH0_IP table rtable0
ip route add default via $ETH0_GW dev eth0 proto static src $ETH0_IP table rtable0

ip route add $ETH1_NET dev eth1 proto static src $ETH1_IP table rtable1
ip route add default via $ETH1_GW dev eth1 proto static src $ETH1_IP table rtable1

# ... and so on, for all 5 interfaces

Nakonec přidejte pokročilá pravidla směrování, která zkontrolují zdrojovou adresu každého balíčku a podle toho zvolí směrovací tabulku, která se má použít:

ip rule add from $ETH0_IP table rtable0
ip rule add from $ETH1_IP table rtable1
#...

Aby celá tato konfigurace trvala i po restartu, možná budete muset napsat vlastní spouštěcí skripty (nebo případně ifup-pre nebo ifup-post skripty), aby vyhovovaly konvencím vaší distribuce Linuxu.

Pro další pojištění můžete přidat pravidla iptables pro jednotlivá rozhraní, která tiše zahodí všechny příchozí pakety, které mohou být přijaty na nesprávném rozhraní. Pokud je vše v pořádku, počet paketů by měl zůstat nulový:pokud se začnou zvyšovat, možná jste něco přehlédli v konfiguraci.

iptables -A INPUT -m addrtype --dst-type UNICAST -i eth0 ! -d $ETH0_IP -j DROP
iptables -A INPUT -m addrtype --dst-type UNICAST -i eth1 ! -d $ETH1_IP -j DROP
# ... and so on for each interface

Poznámka: Jednou jsem implementoval takové nastavení na základě staré internetové diskuse Ricka Jonese a dalších síťových guru. Řekli, parafrázováno, „zatímco to všechno je jasně nezbytné k dosažení silného chování hostitelského modelu v Linuxu nemohu zaručit, že je dostatečné pro všechny možné případy použití“. Fungovalo to pro mě bezchybně; může a nemusí vám stačit, v závislosti na tom, k čemu přesně jej budete používat.

Upozornění: při nastavování této konfigurace se ujistěte, že máte nějaký druh místního nebo vzdáleného přístupu konzoly k systému. Toto nastavení s velkou pravděpodobností zcela zkazí váš přístup k síti, zatímco je hotovo jen z poloviny.

I když by bylo možné nastavit N rozhraní pouze s (N-1) vlastními směrovacími tabulkami, moje osobní preference je přesunout veškerou konfiguraci směrování do vlastních tabulek při použití pokročilého směrování. S route -n nebo ip route show v podstatě prázdné, zatímco systém má zjevně síťová připojení, bude velmi velkým vodítkem, že se děje něco velmi zvláštního. Nicméně, když jsem nastavil systém, jako je tento, nastavil jsem také trvalé upozornění v /etc/motd o aktivním pokročilém směrování a umístění skutečných skriptů, které jej nastavily.

Související:Aliasy pro ‚sudo /etc/init.d/‘?