Shorewall 5.x a alias veřejné IP

[totalek]

Zdravim vespolek, prosim o postrceni spravnym smerem. Kdyby nekdo vedel, byl bych moc rad. Pokud ho takhle nekdo pouziva ...

Pouzivam SHOREWALL, vse funguje, jsem spokojen. Mam VLANY a neni problem. Jen jsem ted pridal na venkovnim rozhrani alias s dalsi verejnou IP. Zvenci mi alias odpovida stejne jako fyzicke rozhrani. Snazil jsem se porozumet, jak SHOREWALL (5.x) zachazi s ALIASEm, ale nic z toho nefunguje. Ja bych potreboval, aby se jedna VLANa z vnitrni site dostala ven pod druhou verejnou IP toho aliasu. Zkousim, testuji a porad bez vysledku. Myslel jsem si...

NETWORK INTERFACES
up ip addr add 77.242.12.34/24 brd 77.242.12.34 dev enp0s31f6 label enp0s31f6:0

IPTABLES (snat file v SHOREWALL)
iptables -t nat -A POSTROUTING -s 172.16.220.0/24 -o enp0s31f6:0 -j MASQUERADE

Diky moc za pripadne nakopnuti.

[Reklama]

[dzavy]

Co pouzit SNAT s --to-source misto MASQUERADE? https://terrywang.net/2016/02/02/new-iptables-gotchas.html

[totalek]

Co pouzit SNAT s --to-source misto MASQUERADE? https://terrywang.net/2016/02/02/new-iptables-gotchas.html

Diky. SNAT jsem taky zkousel a bez vysledku (pokud ho mam dobre).

(snat file - SHOREWALL)

SNAT(77.XX.XX.XX) 172.16.220.0/24   enp0s31f6:0

[Michal Kubeček]

Jen jsem ted pridal na venkovnim rozhrani alias s dalsi verejnou IP. Zvenci mi alias odpovida stejne jako fyzicke rozhrani.

IP aliasing existoval naposledy v jádrech řady 2.0 (a dost možná pouze v jádrech řady 2.0), od jádra 2.2.0 (které vyšlo v lednu 1999) žádné aliasy neexistují a rozhraní má přiřazen pouze seznam adres. (Jen pro pořádek, dnes existují i ipvlan rozhraní, která se trochu podobají těm někdejším aliasům, ale fungují jinak a slouží k jinému účelu.)

Pokud chcete, aby určité pakety měly zdrojovou adresu přeloženu na druhou adresu odchozího rozhraní, použijte SNAT a napište přímo, jakou adresu chcete použít.

[Miroslav Šilhavý]

Druhá adresa, pokud je ze stejného subnetu, jako ta první, by se měla přidávat s maskou /32.

Řešení Vašeho problému je SNAT - musíte si nastavit pravidla, za jakou adresu se jaké spojení schová.
MASQUERADE vybere tu první (hlavní) adresu na interfacu.

[Reklama]

[totalek]

Druhá adresa, pokud je ze stejného subnetu, jako ta první, by se měla přidávat s maskou /32.

Řešení Vašeho problému je SNAT - musíte si nastavit pravidla, za jakou adresu se jaké spojení schová.
MASQUERADE vybere tu první (hlavní) adresu na interfacu.

Zamerim se na SNAT (masku u druhe IP jsem zmenil - diky za radu) a na miste odzkousim. Diky za vas cas !

[Michal Kubeček]

Druhá adresa, pokud je ze stejného subnetu, jako ta první, by se měla přidávat s maskou /32.

Máte pro takové doporučení nějaké zdůvodnění? Případně vysvětlení, co by to v tomto konkrétním případě řešilo?

[snuff1987]

https://docs.huihoo.com/darwin/opendarwin/articles/network_config/ar01s03.html

V linuxovych manualoch sa nic take nepise, ale freebsd odporuca pouzivat pre aliasy masku 32 bitovu.Vysvetlenie v linku.

Inak v tomto pripade vam to urcite fungovat nebude, kedze default routa ukazuje cez povodny interface a -J MASQUERADE vieme co robi. Cize ano ak chcete maskovat urcitu vlanu potrebujete robit SNAT s konkretnou IP (nie s IP subnetu ako ste to robili).

[Michal Kubeček]

V linuxovych manualoch sa nic take nepise, ale freebsd odporuca pouzivat pre aliasy masku 32 bitovu.Vysvetlenie v linku.

Ať koukám, jak koukám, vysvětlení se odkazuje na implementační detaily routovacích tabulek ve FreeBSD, které jsou pro Linux zjevně irelevantní (protože to, co se tam píše, na Linuxu není pravda).

[totalek]

https://docs.huihoo.com/darwin/opendarwin/articles/network_config/ar01s03.html

V linuxovych manualoch sa nic take nepise, ale freebsd odporuca pouzivat pre aliasy masku 32 bitovu.Vysvetlenie v linku.

Inak v tomto pripade vam to urcite fungovat nebude, kedze default routa ukazuje cez povodny interface a -J MASQUERADE vieme co robi. Cize ano ak chcete maskovat urcitu vlanu potrebujete robit SNAT s konkretnou IP (nie s IP subnetu ako ste to robili).

Diky moc za odezvu. Takze pokud tomu rozumim, takze pokud je primarni rozhrani (enp0s31f6 -j MASQUERADE) tak si na muzu delat, co chci, ale SNAT pro subnet a enp0s31f6:0 proste nepojede. A kdybych specifikoval kazde rozhrani solo SNAT ? Otazkou je, jak se k tomu stavi SHOREWALL (i kdyz to jsou jen IPTABLES).

Veskery provoz 172.16.220.0/24 jde pres 172.16.220.1. Bohiuzel se musim dostat na misto, nektere veci vzdalene nevyzkousim, ale aspon se mohu pripravit.

iptables -t nat -A POSTROUTING -s 172.16.220.1 -o enp0s31f6:0 --j SNAT --to 77.x.x.x

SHOREWALL (snat file)
SNAT(77.XX.XX.XX) 172.16.220.1  enp0s31f6:0

[snuff1987]

Ved ja netvrdim nic ine. Na linuxe s tym problem nie je.

Skor nieco taketo by som povedal:
iptables -t nat -A POSTROUTING -s 172.16.220.1 -o enp0s31f6 --j SNAT --to 77.x.x.x

Ale treba vyskusat, iptables su krasny nastroj. Len si treba pustit tcpdump a sledovat co sa deje.

[Michal Kubeček]

Diky moc za odezvu. Takze pokud tomu rozumim, takze pokud je primarni rozhrani (enp0s31f6 -j MASQUERADE) tak si na muzu delat, co chci, ale SNAT pro subnet a enp0s31f6:0 proste nepojede.

Měl byste začít tím, že konečně pochopíte, že žádné rozhraní enp0s31f6:0 neexistuje. Už dvacet let ne. Máte jen jedno rozhraní a na něm dvě IP adresy. Target SNAT vám umožňuje specifikovat, na kterou zdrojovou adresu se mají které pakety překládat, to je všechno, žádnou mystiku v tom nehledejte.

[Miroslav Šilhavý]

Druhá adresa, pokud je ze stejného subnetu, jako ta první, by se měla přidávat s maskou /32.

Máte pro takové doporučení nějaké zdůvodnění? Případně vysvětlení, co by to v tomto konkrétním případě řešilo?

Má to několik pozitivních dopadů. Maska na druhotných IP stejného subnetu víceméně nedává smysl. První definice nastaví interface routu, která už při dalších IP adresách není potřeba nastavovat. (Např. na broadcasty bude vždy odpovídat ta prvotní IP adresa, takže i z tohoto důvodu je maska zbytečná). Linux si s tímto sice umí poradit, ale proč spoléhat na automagii, když se to dá nastavit správně?

Dalším důvodem je prevence chyb administrátora. Kdyby v důsledku nějaké chyby vyrušil primární IP adresu, tak s maskou /32 nenaskočí na její místo; většinou je vhodnější, aby systém přestal odpovídat, než aby z ničeho nic fungoval nepředpokladatelně.

Posledním důvodem je, že můžete mít kombinaci X adres na stejném interface, ale z různých subnetů, např.:

192.168.0.1/24
192.168.0.2/24
10.0.0.1/24
10.0.0.2/24

Všechny současné OS spolehlivě dosadí tu první ip adresu jako primární. Ta bude odpovídat na broadcasty, z ní budou defaultovat nová spojení. Ale co v případě subnetu 10.0.0.0/24? Tam jsou obě adresy v rovnocenné pozici a nelze spoléhat na to, že každá distribuce (a ostatně i každá verze jádra) upřednostní 10.0.0.1. Řešením proto je:

192.168.0.1/24
192.168.0.1/32
10.0.0.1/24
10.0.0.2/32

Tím dáte systému jasně na srozuměnou, které adresy jsou hlavní.

BTW i na FreeBSD funguje nastavení masek i pro sekundární IP adresy, ale nedoporučuje se to. V Linuxu toto není nikde moc zdokumentované, spíš se předpokládá, že admin rozumí obecné síťařině.

[Michal Kubeček]

Dobrá, pokusím se ty polopravdy trochu uvést na pravou míru.

Má to několik pozitivních dopadů. Maska na druhotných IP stejného subnetu víceméně nedává smysl. První definice nastaví interface routu, která už při dalších IP adresách není potřeba nastavovat. (Např. na broadcasty bude vždy odpovídat ta prvotní IP adresa, takže i z tohoto důvodu je maska zbytečná). Linux si s tímto sice umí poradit, ale proč spoléhat na automagii, když se to dá nastavit správně?

Především proto, že to není žádná automagie a proto, že když to nastavíte správně, funguje to zcela deterministicky a v souladu s dokumentací. O primární a sekundárních adresách má smysl mluvit pouze v případě, že se jedná o adresy se stejným přiřazeným rozsahem - a to pro každý z těch rozsahů zvlášť. Takže ve vašem příkladu

192.168.0.1/24
192.168.0.2/24
10.0.0.1/24
10.0.0.2/24

jsou (pokud je přidáte v tomto pořadí) adresy 192.168.0.1 a 10.0.0.1 primární a ty zbylé dvě sekundární, což si můžete snadno ověřit podle příznaku secondary ve výstupu "ip addr show". Proto skončíte se dvěma automatickými routami, které se přidají spolu s primárními adresami, zatímco při přidání sekundární adresy se žádná routa nepřidává. Žádná magie...

Pokud ovšem adresy nemají stejný rozsah, pak mezi sebou žádný vztah primární/sekundární nemají a routa se přidává pro každou z nich. (Dokonce můžu přidat dvakrát stejnou adresu se dvěma různými délkami prefixu.) Viz např.

Kód: [Vybrat]

lion:~ # ip link add dummy1 type dummy
lion:~ # ip link set dummy1 up
lion:~ # ip addr add 172.17.1.1/24 brd + dev dummy1
lion:~ # ip addr add 172.17.1.2/24 brd + dev dummy1
lion:~ # ip -4 addr show dev dummy1
23: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 172.17.1.1/24 brd 172.17.1.255 scope global dummy1
       valid_lft forever preferred_lft forever
    inet 172.17.1.2/24 brd 172.17.1.255 scope global secondary dummy1
       valid_lft forever preferred_lft forever
lion:~ # ip route show dev dummy1
172.17.1.0/24 proto kernel scope link src 172.17.1.1

lion:~ # ip addr flush dev dummy1
lion:~ # ip addr add 172.17.1.1/24 brd + dev dummy1
lion:~ # ip addr add 172.17.1.2/26 brd + dev dummy1
lion:~ # ip -4 addr show dev dummy1
23: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 172.17.1.1/24 brd 172.17.1.255 scope global dummy1
       valid_lft forever preferred_lft forever
    inet 172.17.1.2/26 brd 172.17.1.63 scope global dummy1
       valid_lft forever preferred_lft forever
lion:~ # ip route show dev dummy1
172.17.1.0/26 proto kernel scope link src 172.17.1.2
172.17.1.0/24 proto kernel scope link src 172.17.1.1


Dalším důvodem je prevence chyb administrátora. Kdyby v důsledku nějaké chyby vyrušil primární IP adresu, tak s maskou /32 nenaskočí na její místo; většinou je vhodnější, aby systém přestal odpovídat, než aby z ničeho nic fungoval nepředpokladatelně.

Právě proto existuje /proc/sys/net/ipv4/conf/*/promote_secondaries, abyste si mohl (globálně nebo per interface) zvolit, jaké chování chcete, a nemusel vymýšlet podivné triky, které zamlží, kam která adresa vlastně patří. Buď se s primární adresou odstraní i všechny k ní patřící sekundární nebo (default) se primární stane další v pořadí. Ani v jednom případě nic "nepředpokladatelného", všechno je krásně deterministické a jasně zdokumentované. A obě varianty jsou lepší, než když vám tam zůstane viset druhá adresa s prefixem /32, takže něco bude fungovat dál a něco ne.

Ale co v případě subnetu 10.0.0.0/24? Tam jsou obě adresy v rovnocenné pozici a nelze spoléhat na to, že každá distribuce (a ostatně i každá verze jádra) upřednostní 10.0.0.1.

Proč si před tím, než něco takového napíšete, neověříte, jak se ten systém opravdu chová?

spíš se předpokládá, že admin rozumí obecné síťařině.

Jedna z mála věcí, se kterými ve vašem příspěvku souhlasím.