Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: Ħαℓ₸℮ℵ ␏⫢ ⦚ 17. 05. 2023, 13:44:25
-
Pokud si dám přes sudo ip route add blackhole x.y.z.ž, budou při zapnutém rp_filter blokovány i příchozí pakety? (dává smysl u UDP)
-
Blackhole na routeru slouží k tomu, abyste se rychle zbavil paketů s danou cílovou adresou. Takže se to typicky používá na routeru, kde se chcete zbavit některých paketů, které by normálně procházely dál. Takže se to aplikuje vždy na příchozí pakety (odchozí nejsou, protože ten paket skončí v černé díře místo toho, aby se z něj stal odchozí paket).
Na zařízení, které není routerem, byste to mohl použít pro filtraci odchozích paketů na danou IP adresu – ale v takovém případě dává mnohem větší smysl zastavit generování těch paketů. Takže použití by bylo asi v nějaké nouzové situaci, kdy by to začal generovat nějaký proces, který by zároveň dělal něco smysluplného a důležitého, takže byste ho nechtěl hned zastavit.
rp_filter s tím nijak nesouvisí, ale pokud vím, rp_filter se také aplikuje jenom na příchozí pakety.
Takže moc nerozumím tomu, na co se vlastně ptáte. Protože ip route blackhole a rp_filter spolu nijak nesouvisí (kromě toho, že blokují pakety), a hlavně se oba dva používají především (rp_filter výhradně) na příchozí pakety.
-
Pokud si dám přes sudo ip route add blackhole x.y.z.ž, budou při zapnutém rp_filter blokovány i příchozí pakety? (dává smysl u UDP)
rp_filter funguje jen na prichozi pakety
Tady to mas popsany https://www.howtouselinux.com/post/how-rp_filter-works-on-linux
Jinak receno, pokud ti dorazi paket, ktery neprojde pres rp, tak bude zahozen, kdyz projde, pokroci se k routingu a skonci pripadne v ty dire.
-
Možný byl dotaz špatně pochopen a určitě tomu nepomohlo odstranění blackhole z nadpisu. blackhole a rp_filter byly nedílné podmínky.
Chtěl jsem to napsat sáhodlouze, ale nakonec jsem sklouzl k zvýraznění "i" příchozích. Logicky - odchozích se to týká - to přímo je smysl routovací tabulky. Ta odpovídá na kam?.
Ale dobré bylo upozornění na rozlišení paketů originujících a forwardovaných(nebo jinak router v koncový člen). (i když to já v dotazu hážu do jednoho pytle)...
→→→
Čili můj dotaz, za předpokladu zapnutého rp_filtru (v případě že jde o router) a záznamu v routovací tabulky blackhole x.y.z.ž:
Přijde-li na rp-filtrované rozhraní (pro ilustraci wan0) paket s danou zdrojovou adresou(xyzž=zdroj), je zahozen? A liší se to nějak, když cíl paketu je přímo lokální a nebo v jiné síti(byl by forwardován, například z rp-WAN do LAN).
Tedy uplatní se kontrola rp_filtru, že src paketu, který přišel z wan0 , vychází na blackhole a to je velký špatný protože to nesouhlasí
dotaz kde jen zaměním cílovou a zdrojovou adresu (xyzž=cíl) za cílovou považuju za bez předmětný- to přeci je podstata ip route blackhole, že pokud cíl paketu je v blackhole, je zahozen
expert note: nevím jestli je podstatné, že blackhole technicky vzato je TYPE záznamu a ne VIA routovacího záznamu (ip route add help: ROUTE - NODE_SPEC atd)
a poznámku "dává smysl u UDP" beru zpět, dává to i smysl u TCP(příchozí spojení z WAN), ale u UDP je to viditelnější na pochopení
-
Přijde-li na rp-filtrované rozhraní (pro ilustraci wan0) paket s danou zdrojovou adresou(xyzž=zdroj), je zahozen?
To záleží na tom, zda IP adresa xyzž podle routovací tabulky je za jiným rozhraní, než jwan0. Takhle funguje rp_filter. Blackhole s tím nijak nesouvisí.
expert note: nevím jestli je podstatné, že blackhole technicky vzato je TYPE záznamu a ne VIA routovacího záznamu (ip route add help: ROUTE - NODE_SPEC atd)
Ano, je to podstatné. Nevím, proč jste si usmyslel, že by se blackhole mělo chovat jako rozhraní.
-
Fakticky x.y.z.ž nemůže za nějakým rozhraním, když je blackhole
pp@id:~ $ sudo ip r add 3.3.8.8 dev wan0
pp@id:~ $ sudo ip r add blackhole 3.3.8.8
RTNETLINK answers: File exists
pp@id:~ $ sudo ip r add blackhole 3.3.0.0
pp@id:~ $ sudo ip r add 3.3.0.0 dev wan0
Totéž
RTNETLINK answers: File exists(citace je vytržená z kontextu, patří tam i ta poznámka o blackhole záznamu)
Jináč jde o globální internetovou adresu za norm.okolností , jejíž flow by šlo přes wan0. Doufám, že už si rozumíme.
2.(podružný detail off topic)
v čem je to podstatné, chová se to jako routa. Kváká to jako routa...
-
Jináč už jsem si to ověřil ten rp_filtr nepropustí neproforwarduje pakety dál, když ip je v blackhole. (neověřil jsem to pro INPUT)
, byl to trochu pain, jelikož jsem za NATem, kam ani česká pošta nedoručí paket, takže jsem si musel wan1 vyrobit z tunelu. Na něm jsem měl rp filtr 0 a nastavení na 1 mi utlo komunikaci ještě bez blackholováním (zkoušel jsem pracnější variantu Forward - kdy vzdálený konec DNAToval ne na samotný router, ale na stroj v síti uvnitř) což koresponduje s variantou strict rp filter,. (Teď už sivysvětlení nepamatuju, věděl jsem to když jsem to ladil a náhle mi zamrzlo ssh(přes tunel) jakmile jsem dal rp_filtr 1)
Díky forward jsem viděl na routeru zda paket potenciálně projde vstupním i výstupním rozhranim.
S rp_filtrem off(0) byly forwardovany SYN pakety, zařízení v síti poslalo SYN+ACK(o blackhole nix neví), ale ty logicky přes router neodešly přes blackhole.
ale musel jsem dát rp filter 2..
Což můj setup nerozbilo. Pak jsem mohl dát blackhole a viděl, že ani příchozí pakety nejsou forwardovány. Tudíž ani zařízení v interní síti ani nemělo na co odpovídat.
Taky mimojiné jsem jsem nemohl dávat ip r add blackhole do defaultní routovací tabulky ale to té patřící pro tunel.
Což mě přivádí k otázce, jak rp_filtr funguje v přítomnosti víc routovacích tabulek.... Resp paket se routuje podle právě jedné routovací tabulky?
Ještě , že jsem si zkopíroval text příspěvku a po přihlášení zkontroloval, že formulář se změnil na Nové téma... >:(
-
Ten odstavec o rp filtru s hodnotou 1 jsem zmotal. i když to s původním dotazem nesovisí.
Oprava.
Žádné přerušení ssh(router sám) , to jelo. Dál, Ale utlo se veškerý spojení z internetu portforwardované(zDNATové z veřejného kkonce tunelu ; ovšem nikoli zSNATované kvůli zachování IP) do vnitřní sítě.
martian source 192.168.1.39 from 48
.24.166.r, on dev tun2
Uplně přesně tomu nerozumím, protože inet provoz může přicházet z wlan0 ale i tun8
přestože routovaí tabulku mámip r s t tunelic
default via 10.22.8.2 dev tun2
10.22.8.0/24 via 10.22.8.2 dev tun2
192.168.1.0/24 via 192.168.1.250 dev eth0
ip r s
default via 192.5.1.11 dev wlan0
192.5.1.11 dev wlan0
192.168.1.0/24 dev eth0