Kontrola konfigurace IP adres

[scientific]

Ahoj všem, prosím někoho zkušenějšího o kontrolu konfigurace. Funguje mi to, ale údajně není vhodné používat takto vygenerované routy. Jak by to prosím mělo být správně? Přikládám i konfiguraci eth0. Zřejmě bych se měl zbavit příznaku noprefixroute. Prosím nenuťte mě měnit formu konfigurace. nerad bych to řešil přes virtuální eth jako eth0:1,eth0:2 apod.

Díky všem za tipy.

Kód: [Vybrat]

[root@server ~]# ip route
default via 178.***.**.65 dev eth0 proto static metric 100
83.***.**.128/25 dev eth0 proto kernel scope link src 83.***.**.250 metric 100
83.***.**.128/25 dev eth0 proto kernel scope link src 83.***.**.155 metric 100
83.***.**.128/25 dev eth0 proto kernel scope link src 83.***.**.211 metric 100
85.***.**.64/26 dev eth0 proto kernel scope link src 85.***.**.108 metric 100
85.***.**.64/26 dev eth0 proto kernel scope link src 85.***.**.81 metric 100
85.***.**.64/26 dev eth0 proto kernel scope link src 85.***.**.112 metric 100
89.***.**.128/25 dev eth0 proto kernel scope link src 89.***.**.234 metric 100
89.***.**.128/25 dev eth0 proto kernel scope link src 89.***.**.223 metric 100
89.***.**.128/25 dev eth0 proto kernel scope link src 89.***.**.160 metric 100
149.***.**.128/26 dev eth0 proto kernel scope link src 149.***.**.184 metric 100
149.***.**.128/26 dev eth0 proto kernel scope link src 149.***.**.176 metric 100
149.***.**.128/26 dev eth0 proto kernel scope link src 149.***.**.157 metric 100
178.***.**.64/26 dev eth0 proto kernel scope link src 178.***.**.121 metric 100
178.***.**.64/26 dev eth0 proto kernel scope link src 178.***.**.116 metric 100
178.***.**.64/26 dev eth0 proto kernel scope link src 178.***.**.108 metric 100
178.***.**.64/26 dev eth0 proto kernel scope link src 178.***.**.96 metric 100


Kód: [Vybrat]

[root@server ~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 56:6f:83:3a:00:14 brd ff:ff:ff:ff:ff:ff
    inet 178.***.**.121/26 brd 178.***.**.127 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet 149.***.**.184/26 brd 149.***.**.191 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet 89.***.**.234/25 brd 89.***.**.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet 85.***.**.108/26 brd 85.***.**.127 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet 83.***.**.250/25 brd 83.***.**.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet 178.***.**.116/26 brd 178.***.**.127 scope global secondary noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet 149.***.**.176/26 brd 149.***.**.191 scope global secondary noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet 178.***.**.108/26 brd 178.***.**.127 scope global secondary noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet 89.***.**.223/25 brd 89.***.**.255 scope global secondary noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet 85.***.**.81/26 brd 85.***.**.127 scope global secondary noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet 83.***.**.155/25 brd 83.***.**.255 scope global secondary noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet 149.***.**.157/26 brd 149.***.**.191 scope global secondary noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet 178.***.**.96/26 brd 178.***.**.127 scope global secondary noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet 89.***.**.160/25 brd 89.***.**.255 scope global secondary noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet 85.***.**.112/26 brd 85.***.**.127 scope global secondary noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet 83.***.**.211/25 brd 83.***.**.255 scope global secondary noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::546f:83ff:fe3a:14/64 scope link noprefixroute
       valid_lft forever preferred_lft forever


Kód: [Vybrat]

[root@server ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE="eth0"
BOOTPROTO="static"
DNS1="8.8.8.8"
IPV6INIT="yes"
MTU="1500"
NM_CONTROLLED="yes"
ONBOOT="yes"
TYPE="Ethernet"

IPADDR0="178.***.**.121"
NETMASK0="255.255.255.192"
GATEWAY0="178.***.**.65"

IPADDR1="149.***.**.184"
NETMASK1="255.255.255.192"
GATEWAY1="149.***.**.129"

IPADDR2="178.***.**.116"
NETMASK2="255.255.255.192"
GATEWAY2="178.***.**.65"

IPADDR3="89.***.**.234"
NETMASK3="255.255.255.128"
GATEWAY3="89.***.**.129"

IPADDR4="85.***.**.108"
NETMASK4="255.255.255.192"
GATEWAY4="85.***.**.65"

IPADDR5="83.***.**.250"
NETMASK5="255.255.255.128"
GATEWAY5="83.***.**.129"

IPADDR6="149.***.**.176"
NETMASK6="255.255.255.192"
GATEWAY6="149.***.**.129"

IPADDR7="178.***.**.108"
NETMASK7="255.255.255.192"
GATEWAY7="178.***.**.65"

IPADDR8="89.***.**.223"
NETMASK8="255.255.255.128"
GATEWAY8="89.***.**.129"

IPADDR9="85.***.**.81"
NETMASK9="255.255.255.192"
GATEWAY9="85.***.**.65"

IPADDR10="83.***.**.155"
NETMASK10="255.255.255.128"
GATEWAY10="83.***.**.129"

IPADDR11="149.***.**.157"
NETMASK11="255.255.255.192"
GATEWAY11="149.***.**.129"

IPADDR12="178.***.**.96"
NETMASK12="255.255.255.192"
GATEWAY12="178.***.**.65"

IPADDR13="89.***.**.160"
NETMASK13="255.255.255.128"
GATEWAY13="89.***.**.129"

IPADDR14="85.***.**.112"
NETMASK14="255.255.255.192"
GATEWAY14="85.***.**.65"

IPADDR15="83.***.**.211"
NETMASK15="255.255.255.128"
GATEWAY15="83.***.**.129"

[root@server ~]#


[Reklama]

[IDontCare]

Ehm, co to ma sakra jako byt? Mas 16 statickych verejnych IP na jednom rozhrani? WTF? To je nejaka testovaci konfigurace v labu?

[Radek Zajíc]

Zkuste nejdriv popsat, ceho chcete dosahnout. Ty adresy a routy, navic takhle brutalne vymaskovane, nedavaji samy o sobe moc smysl.

[scientific]

To je přesně to čeho chci dosáhnout, aby ty routy dávali smysl. Jsou tedy brutálně vymaskované, jaké je řešení? Jakým způsobem provést demaskování, aby ty routy dávali lepší logiku a nebyly "zbytečně přehnaně vymaskované". Že by upravit masku, aby wildcard byla co nejmenší, zmenšit CIDR, ale spočítat to už dávno neumím, možná mám jen všude našoupat masky odpovídající CIDR /30?

[Death Walker]

Mas medzi providerom a tymto zariadenim nejaky router ktory by ti delil pridelene subnety na mensie?

Ak ano tak pouzi masky podla toho routru.

Ak nie tak pouzi masky podla subnetu ktory ti priradil provider...

[Reklama]

[IDontCare]

To je přesně to čeho chci dosáhnout, aby ty routy dávali smysl. Jsou tedy brutálně vymaskované, jaké je řešení? Jakým způsobem provést demaskování, aby ty routy dávali lepší logiku a nebyly "zbytečně přehnaně vymaskované". Že by upravit masku, aby wildcard byla co nejmenší, zmenšit CIDR, ale spočítat to už dávno neumím, možná mám jen všude našoupat masky odpovídající CIDR /30?

Vsechno to tece pres jedno rozhrani => nastavis eth0 jako default route a cely ten nesmysl s maskama muzes zahodit. To je uplne zakladni nepochopeni smyslu routovani.

[Radek Zajíc]

Vymaskovane = prilis mnoho hvezdicek

Ceho chcete dosahnout = proc mate na jednom rozhrani tolik IP adres s tolika ruznymi vychozimi branami? Co to je za prostredi? Jedna se skutecne o ruzne vychozi brany (snad zadny sitar pri smyslech by na jeden L2 segment neposadil pet routeru s ruznymi IP sitemi), nebo jde o jeden router s vice "branovymi" IP adresami?

K cemu slouzi tolik IP adres na rozhrani?
Jaky typ provozu tam tece?

Napriklad pro UDP provoz maji nektere aplikace problem s odpovidanim "ze spravnych" IP adres. Pokud prijde z Internetu UDP request na IP adresu B, ktera je sekundarni, aplikace muze odpovedet z primarni adresy A a cele to nebude fungovat.

Pokud tam ale delate 1:1 NAT nekam dal, asi to vadit nebude.

Proto je dulezite vedet, ceho chcete dosahnout.

[Radek Zajíc]

Pokud nam poslete vypis prikazu arp -n s IP/MAC adresami gatewayi, budeme schopni posoudit, jestli se jedna o jeden nebo vic routeru. Pokud jeden router, mela by skutecne stacit jedna vychozi brana na jeho libovolnou IP adresu.
(Potencialni problemy s vice IP adresami na jednom rozhrani, resp. volbou zdrojove IP v aplikacich, samozrejme zustavaji.)

[Death Walker]

Vymaskovane = prilis mnoho hvezdicek

Tie tam nevadia. Vadili by ak by mal v maske siete /24 a menej.

Ceho chcete dosahnout = proc mate na jednom rozhrani tolik IP adres s tolika ruznymi vychozimi branami? Co to je za prostredi? Jedna se skutecne o ruzne vychozi brany (snad zadny sitar pri smyslech by na jeden L2 segment neposadil pet routeru s ruznymi IP sitemi), nebo jde o jeden router s vice "branovymi" IP adresami?

K cemu slouzi tolik IP adres na rozhrani?
Jaky typ provozu tam tece?

Proste natom servri bezi nieco co ma viacero ip adries. Pred SNI to bol na apache servri bezny jav. Pretoze bez SNI musi mat kazda domena unikatnu ip aby bolo mozne vystavit TLS certifikat. Bohuzial aj dlho po zavedeni SNI, ked sa vam rozny bastardi z hostingov snazili predat ip adresy naviac.

Napriklad pro UDP provoz maji nektere aplikace problem s odpovidanim "ze spravnych" IP adres. Pokud prijde z Internetu UDP request na IP adresu B, ktera je sekundarni, aplikace muze odpovedet z primarni adresy A a cele to nebude fungovat.

Bude to fungovat, v tej route ma atribut SRC ktory urcuje preferovanu adresu paketu ktore stroj odosle.

[Radek Zajíc]

Bude to fungovat, v tej route ma atribut SRC ktory urcuje preferovanu adresu paketu ktore stroj odosle.

Takovou routu tam nevidim. Vidim default routu bez specifikace src a pak radu on-link rout, ktere se vztahuji jen ke komunikaci se stroji v tech samych subnetech.

Problem s vice IP a UDP provozem (odpovedi na prichozi provoz) v jednom systemu je znamy, napr. v OpenVPN kvuli tomu podporuji i alternativni socketove API: https://community.openvpn.net/openvpn/ticket/442

Dalsi potencialni problem je u volby "zdrojove IP" pro provoz iniciovany ze serveru. Protoze default route nema atribut src, kernel si pro odchozi provoz vybere *nejakou* adresu, a muze to byt jina adresa, nez tazatel chce.

Dalsi problem: Pokud je na siti vic nezavislych gatewayi, muze posilani vsech odpovedi skrze jen jednu gateway zpusobit zahazovani provozu kvuli asymetrickemu routingu (konfiguraci gatewayi nezname). Krome

Kód: [Vybrat]

arp -n by se tak hodil i vypis

Kód: [Vybrat]

ip rule prip. jednotlivych routovacich tabulek

Kód: [Vybrat]

ip route show table X (pokud existuji).

Pokud tazatel chce vedet, jestli je jeho konfigurace v poradku, mel by zaroven popsat, k cemu a jak ji pouziva. Coz zatim neudelal.

[Death Walker]

Pokud tazatel chce vedet, jestli je jeho konfigurace v poradku, mel by zaroven popsat, k cemu a jak ji pouziva. Coz zatim neudelal.

Ako pise, ta konfiguracia je funkcna. Ak by boli za tymi hviezdickani rovnake cisla, co asi nebudu, tak by to fungovalo aj tak. Len sa pytal ako to ucesat. Zrejme na to mrkol nejaky iny tajtrlik, ktory robi vsetko spravne a ostatny co to robia nejako odlisne to maju blbo. Nie je nad to komunikovat s ludmi co im ich iq nedopraje dynamicke myslenie a len si idu slepo za tym co nasprtali naspamat.

[scientific]

arp -n u VPS je asi k ničemu ne?

Normálně všechny IP adresy reagují na ping.

Jde prý o to, že v IP route mám 17 řádků (16 IP adres + řádek začínající na "default via"). Tak je to prý špatně, protože tam mám být jen 5 řádků (4 IP rozsahy + řádek začínající na "default via"). Možná nemám každé IP adrese v ifcfg-eth0 konfigurovat gateway, ale mám ji nastavit jen první tři a pak to nějak zaaliasovat. Tím NEMYSLÍM alias pro interface ve stylu eth0:15

Tuší někdo jak na to? Prošel jsem spousty článku, jak přidat více IP adres

[Death Walker]

Tych 5 riadkov by tam bolo ak by ta vps obsluhovala cely subnet. Ak z toho subnetu obsluhuje niekolko adries tak musi vediet ktore adresy obsluhuje a ostatne adresy z toho subnetu smeruje mimo vps.

[Filip Jirsák]

Abychom vám mohli poradit, musíme nejdřív vědět, o co se snažíte. Předpokládám, že jste dostal přidělené nějaké IP adresy spolu s informací, do jaké sítě patří. Případně jste mohl dostat seznam sítí a v každé z nich IP adresy přidělené vašemu VPS. A dále jste dostal informaci o výchozí bráně, případně brány do dalších sítí.

Začněte tím, že sem tyhle údaje vypíšete.

[Death Walker]

Napada ma ale ci ma vobec zmysel radit. To by sme potrebovali vediet ci si tu vps hostujete sam alebo ju mate prenajatu od nejakeho poskytovatela.

Ak ju hostujete sam tak ste zrejme nastavoval siet aj na hoste kde bezi ta siet, plus na niekolkych dalsich miestach aby sa k vps tie pakety dostali. Tu by to nemalo zmysel radit, vedel by ste si s tym poradit sam.

Takze predpokladam ze tu vps mate prenajatu. Potom je zrejme ze poskytovatel vam uz siet nastavil. Inak by sa k vam nedostali pakety.

Ak je spravny predpoklad ze mate tu vps prenajatu, tak je to mudrejsie konzultovat v prvom rade s poskytovatelom. Ak totiz tu konfiguraciu zmenite podla nejakeho miestneho vseumelca (a ze ich tu je), tak vam to prestane fungovat a je mozne ze si zaplatite technika, pretoze sa nedostanete ani na ssh...