Dotaz: uBuntu a dva GLAN porty

[wagi]

Dobrý den (ahoj),

zprovoznil jsem si pod uBuntu 16 vzdálený fileserver, na kterém běží jak Apache WebDAV, tak i pure-ftpd. Deska má 2x GLAN porty, IP adresy oboum ethernetům příděluji pomocí rezervace a MAC na routeru (Mikrotik) a na routeru běží i firewall, takže na uBuntu je FW vypnutý.

Dotaz zní, je technicky možné tyto dvě služby rozdělit tak, aby měly každá svúj GLAN port pro sebe?

Děkuji všem guru za případnou reakci.

Odpovědi

[bigBRAMBOR]

tak jestli ma kazda karta svoji IP, muzes kazdou sluzbu nechat poslouchat jenom na jednom rozhraní.

nebo sitovky spoj do teamu a nastav tomu jednu IP, zatez se bude rozdelovat sama. ale nejsem si jistý s podporou na mikrotiku

[wagi]

Díky za reakci,

zkoušel jsem ručně služby donutit poslouchat svojí IP. u Apache WebDAV je to v /etc/apache2/ports.conf

Listen ip:port

a v pure-ftpd /etc/pure-ftpd/conf/Bind (zkoušel jsem i ForcePassiveIP)

ip,port

nicméně toto obě služby ignorují a čuchají si z obou ip náhodně, což je u portforwardu nedobře :)

O teamu síťovek jsem nevěděl, takže díky za navedení a u mikrotiku to ověřím.

[Filip Jirsák]

čuchají si z obou ip náhodně

Nerozumím, co si mám pod tímhle představit.

Jinak tou konfigurací, na jaké IP adrese budou služby naslouchat, ovlivníte to, přes kterou IP adresu budou ty služby přijímat spojení. Nezabráníte tomu, aby někdo poslal požadavek na spojení na druhou IP adresu (ale tam nic nebude naslouchat, takže se spojení nenaváže), a také tím neovlivníte, z jaké IP adresy se budou navazovat odchozí spojení z toho serveru (s výjimkou datových spojení FTP, která by se měla navazovat ze stejné IP adresy, na jakou je navázáno řídící spojení – ale to by si měl server zajistit sám). Ve vašem popisu nic o odchozích spojeních nepíšete, takže by vám to asi nemělo vadit, připomínám to jen pro jistotu.

[wagi]

Je to přesně tak jak píšete. Celou dobu jsem se zaobíral příchozím spojením. Já se musím naučit, jak donutit službu, aby odpověděla na ip ze které přišel požadavek.

Například ten webdav poslouchá na druhé ip, ale odpovídá na první. V podstatě všechny ostatní služby odpovídají jen na tu první IP (SSH, VNC atp.)

[1john2]

jak vypada routing table ip route show?

Nicmene pro prichozi tcp spojeni nedava smysl aby stroj odpovidal z jine IP nez na jakou bylo navazano spojeni.

[wagi]

default via 192.168.2.254 dev enp1s0f0 proto static metric 100 default via 192.168.2.254 dev enp1s0f1 proto static metric 101 169.254.0.0/16 dev enp1s0f0 scope link metric 1000 192.168.2.0/24 dev enp1s0f0 proto kernel scope link src 192.168.2.4 metric 100 192.168.2.0/24 dev enp1s0f1 proto kernel scope link src 192.168.2.44 metric 101 root@BOTICKA-SRV4:/home/wagicb#

a ještě jsem teď narazil na poznatek, služby mi fungují z venku (portforwardem) na tu ip, resp. ethernet, který vidím z těch dvou jako výchozí.

[wagi]

default via 192.168.2.254 dev enp1s0f0 proto static metric 100 default via 192.168.2.254 dev enp1s0f1 proto static metric 101

169.254.0.0/16 dev enp1s0f0 scope link metric 1000

192.168.2.0/24 dev enp1s0f0 proto kernel scope link src 192.168.2.4 metric 100

192.168.2.0/24 dev enp1s0f1 proto kernel scope link src 192.168.2.44 metric 101

omlouvám se, špatně jsem to sem vložil

[bigBRAMBOR]

ty mas obe sitovky ve stejnem subnetu? pak nevim jak ovlivnit jakou adresou odpoví, obe dve mu dávají stejný smysl, respektive by se mel asi ridit metrikou routy. V tom pripade bych asi radsi udelal team(bond) - koukal jsem na mikrotik a snad to umí.

[Filip Jirsák]

Musí odpovídat adresou, na kterou přišel požadavek, jinak se nenaváže TCP/IP spojení.

[bigBRAMBOR]

pokud tam ma nat, jestli jsem to nekde z popisu pochopil, ze ano, muze to dostat klient pod stejnou adresou, kdyz server odpoví z jiné a spojení se naváže. Pokud vypne kontrolu na invalid pakety, myslim ze se to navaze taky.

[Filip Jirsák]

Server nemůže odpovědět z jiné IP adresy, tak to prostě v jádru není implementováno. Server přijímá příchozí spojení voláním accept(), to v jádru v důsledku vede k vygenerování odpovědního paketu – a funkce accept() nemá žádný parametr, kterým by volající mohl nastavit IP adresu, pod kterou se odpoví. Tu adresu nastavuje jádro a nastavuje tam adresu, na kterou přišel požadavek – nemá žádný smysl, aby tam jádro dávalo cokoli jiného.

NAT v tom může způsobit problém jedině tak, že odpovědní paket nepřiřadí správně k příchozímu spojení a nezmění v něm správně adresy. To by ten NAT ale musel být hodně divně nakonfigurovaný. Nejčastěji se to děje tehdy, pokud klient je ve stejné síti jako server, dělá se jen DNAT a server tedy odpoví klientovi přímo, nikoli přes NAT – takže NAT ani nemá možnost ten odpovědní paket upravit.

[bigBRAMBOR]

jiste ze muze, pokud budes mit server, dve IP adresy, kazda z jineho rozsahu, rozsah A a rozsah B, klient v rozsahu A. Nicmene se zepta na sluzbu pres router a zepta se na adresu serveru z rozsahu B. Pokud neni na routeru NAT, dostane server dotaz z IP z rozsahu A, do kterého má ale přímou cestu, a pokud nemá nastavenou žádnou routu, odpoví klientovi pres rozsah A, pres B to pro nej nedava smysl. Klientovi prijde ale odpoved z jine IP nez na jakou poslal dotaz a vyhodi paket jak INVALID. Zkousel jsem to kdysi na RHEL6.x.

NAT tam ani nemusí být, jako v tvém příkladě.

[vencour]

Zvážil jste nastavené reverse path filtery po cestě? Případně nějaké firewally mezi oběma servery?
Ona to neni zas taková sranda a docela čumim, kolik ajťáků v tom plave.

[bigBRAMBOR]

ja jsem nic nezvazoval, puvodni dotaz není můj, ani na popisovanou situaci by zadny vliv nemel, vsechny packety jsou ze spravnych IP na spravne

[Filip Jirsák]

Motáte dohromady různé věci. V tom vašem příkladu tedy klient s IP adresou Ac z rozsahu A pošle paket navazující TCP/IP spojení na IP adresu serveru z rozsahu Bs, server má ještě druhou IP adresu As. Nebo-li server dostane paket navazující TCP/IP spojení, který má jako adresu odesílatele uvedeno Ac a jako adresu příjemce Bs. Když server spojení přijme, vytvoří odpovědní paket, ve kterém jsou položky odesílatel a adresát prohozené oproti příchozímu paketu (IP adresa i port), tedy odesílatel je Bs a adresát je Ac. Neexistuje žádná možnost, jak by se ta adresa odesílatele mohla změnit (bavíme se o standardní implementaci TCP/IP, ne o UDP nebo o nějaké uživatelské implementaci TCP/IP nad raw sockety). Routování se v tu chvíli vůbec neuvažuje, je na to příliš brzo, teprve vzniká odpovědní paket. A s nic složitějšího s adresami a porty, než je jejich prohození, se tam nedělá, protože by to nedávalo smysl – jediný paket, který klient přijme, je ten s prohozenými adresami. Teprve tenhle paket s odesílatelem Bs a adresátem Ac vstupuje do standardního routování a ve vámi uvedeném případě normálně dorazí na klienta a může se pokračovat v navazování spojení.

Problém by nastal, pokud by router mezi A a B dělal DNAT, protože pak se změní cílová adresa serveru, server ale odpoví přímo Ac (protože je v síti A), odpovědí paket tedy nepůjde přes NAT a klient dostane „odpověď“ s jinou zdrojovou IP adresou, než kam posílal požadavek. To byl zřejmě ten případ, který popisujete.

[bigBRAMBOR]

ja jsem nikde nepsal ze se zmeni IP odesilatele v paketu, vznikne packet s cílovou adresou a vstupuje do routování. Kudy ho to na clienta naroutuje? O tom ze z dotazu predpokladam ze je tan NAT pisu o nekolik prispevku výše.

[bigBRAMBOR]

nicméně paket má cilovou adresu a jde do routovani, podle ceho si vybere cestu ke klientovi? Pres router kdyz má klienta na stejnem subnetu? proto jsem psal ze tam snad ani NAT byt nemusi, musim si to vyzkouset.

[Filip Jirsák]

nicméně paket má cilovou adresu a jde do routovani, podle ceho si vybere cestu ke klientovi?

Pokud nejsou nastavena pravidla pro výběr routovacích tabulek a použije se routovací tabulka ve výchozím nastavení, odpoví server přímo, protože bude v routovací tabulce specifický záznam pro subnet s klientem.

Píšete tedy o situaci, kdy klient i server jsou na stejném subnetu, ale server má ještě jinou IP adresu (třeba veřejnou)? Klient naváže (přes router ale bez NATu) spojení na tu IP adresu serveru z jiného rozsahu, server odpovídá z té své (veřejné) IP adresy z jiného rozsahu, ale odpovídá na klientovu IP adresu ze stejného rozsahu, takže paket pošle přímo. Klient paket příjme, protože odpovídá paketu, kterým navazoval spojení – a spojení se tedy normálně naváže a komunikace funguje. Není to úplně typická situace, protože pakety v jednom směru jdou jinou cestou, než pakety v opačném směru, ale není to nic špatného – internet má přesně takhle fungovat. Rozbilo by se to jedině tehdy, pokud by někde cestou bylo nějaké sledování spojení (které by vidělo jen polovinu toho spojení), nebo pokud by na tom serveru byl filtr, který by kontroloval, že odpovědní pakety odcházejí stejným rozhraním, kterým přišel požadavek.

[Filip Jirsák]

ja jsem nikde nepsal ze se zmeni IP odesilatele v paketu, vznikne packet s cílovou adresou a vstupuje do routování.

Vznikne paket s cílovou adresou (původní zdrojovou adresou paketu, který zahajoval spojení) a se zdrojovou adresou, na kterou přišel požadavek (původní cílovou adresou paketu, který navazoval spojení). Pokud v cestě není žádný NAT, jsou to přesně ty adresy (a porty), na které klient navazoval spojení (akorát jsou prohozené), takže klient pozná, ke kterému spojení paket patří a pokračuje v navazování spojení.

Vy jste ale původně psal o případu, kdy klientovi přijde jako „odpověď“ paket s jinou zdrojovou IP adresou, než kam původně posílal klient požadavek na zahájení spojení. A takový případ může nastat jedině tehdy, pokud je v cestě (špatně nakonfigurovaný) NAT, který tu IP adresu změní (ale jenom v jednom směru putování paketu).

[Michal Kubeček]

A takový případ může nastat jedině tehdy, pokud je v cestě (špatně nakonfigurovaný) NAT, který tu IP adresu změní (ale jenom v jednom směru putování paketu).

V praxi je mnohem častější situace, kdy ten NAT sice není špatně nakonfigurovaný, ale paket v opačném směru z nějakého důvodu nejde přes něj.

[Filip Jirsák]

To zahrnuji pod špatně nakonfigurovaný NAT. Pokud je topologie a konfigurace sítě taková, že by se paket mohl vrátit jinudy, než přes NATující router, musí se změnit i zdrojová IP adresa tak, aby na router přišla i odpověď.

[Filip Jirsák]

Například ten webdav poslouchá na druhé ip, ale odpovídá na první

To není možné (pokud „odpovědí“ myslíte odpovědní pakety TCP/IP spojení). Když přijde paket s požadavkem na otevření TCP/IP spojení, musí paket, který na to odpovídá, mít jako odesílající adresu nastavenou tu IP adresu, na kterou přišel požadavek. Jinak by se TCP/IP spojení vůbec nenavázalo. A běžným způsobem to ani nejde změnit, aplikace pouze přijme spojení, ale příslušné IP adresy v paketu nastavuje přímo OS.

Něco jiného je, když aplikace sama navazuje spojení, tam si může zdrojovou IP adresu určit.

V podstatě všechny ostatní služby odpovídají jen na tu první IP (SSH, VNC atp.)

Naslouchají na obou IP adresách, ale komunikaci se podaří navázat jen při navázání spojení na jednu z nich? To by mohl ovlivnit ještě firewall nebo špatná konfigurace sítě.

[wagi]

Vypadá to, že na straně serveru to celou dobu šlo jak má. Bude to někde nedobře v routeru - firewall/nat nejspíše.

Prostě vytáhnu fyzicky kabel, kterej obrazně patří k Apachi - přestane jít webdav, vytáhnu kabel, ze kterýho volám ftp, spadne ftp. Skutečně se v lokální síti služba vrátí tam, odkud je na ní požadavek.

Děkuji všem a hlavně Vám, díky Vaší správné teorii, jsem se nemotal v kruhu a došel k příčině. Budu pokračovat v routeru a tam už to jistí gůgl.

[Michal Kubeček]

Co se týká zdrojové adresy, tak máte sice pravdu, server v odpovědi použije tu adresu, na kterou bylo navázáno spojení, ale to ještě neznamená, že odpověď odejde přes stejné síťové rozhraní. A v tom okamžiku se může dít ledacos, zejména pokud bude někde zapnutý reverse path filter (což má bohužel většina distribucí jako default).

[Filip Jirsák]

Ano, ale filtr může způsobit jedině to, že odpověď nepřijde vůbec, nikoli to, že přijde s jinou adresou. Odpověď s jinou adresou může „zařídit“ jenom nějaký NAT.

Psal jsem konkrétně o případu, o kterém je dotaz, tedy TCP/IP spojení a obě rozhraní vedoucí do téže sítě. Obecně je to samozřejmě složitější, komplikuje se to např. pokud by rozhraní vedla do různých sítí, nebo v případě UDP může „odpověď“ být odeslána z jiné adresy (protože síťově to není žádná odpověď, ale jen obyčejný paket zcela nezávislý na původním dotazu – „požadavek“ a „odpověď“ z toho může udělat až protokol na vyšší vrstvě).

[one]

Proc, abys vytezil vetsi propustnost? Co radeji bonding a udelat ze dvou 1G portu, jeden sdruzeny 2G?

[Sinuhet]

Tam narazí na ten Mikrotik (předpokládám nějaký levnější), který to sice umí, ale celková propustnost bude omezená na 1Gbit, protože mezi CPU a switchem je pouze 1Gbit, a jede to softwarově (ten switch chip to neumí).

Takže ve výsledku si ještě ublíží, protože z 1Gbit full-duplex získá 1Gbit half-duplex...

[motyq]

A co tak, kdyz uz tam mate funkcni webdav, se na cele plesnive prehistoricke ftp vybodnout? Necht se podobne historicke protokoly vezmou za rucicku a odejdou chcipnout do minuleho stoleti, smtp by mohly vzit s sebou. Coz uznavam, vas problem zcela neresi

[nic]

Víš jak, třeba proto, že je někdo konzerva a "má rád to svoje", nebo třeba proto že někdo prostě nevěří webovým prohlížečům (obzvlášť těm googlovským co nabonzujou i to co nevědí) - důvody zkrátka jsou, a na domácí malé síti nějaký ftp nemusí zas tak vadit, ne?

[Peter Golis]

Protokol WebDAV ale funguje aj bez prehliadača, a aj bez Google.

Mne osobne FTP vadilo už v minulom tisícročí, a riešil som to už vtedy cez ssh. Nielen kvôli možnosti odpočúvania, ale kvôli synchronizácii obsahu súborov a aj metadát. Strata dátumov pri uploade na FTP, napríklad pri fotkách z dovolenky, predĺži ich hľadanie o značnú dobu.

[bla.bla]

potrebujes dve routovacie tabulky, kedze mas jednu default GW pre obe IPcky

https://serverfault.com/questions/524054/simple-multihomed-linux-server-issue

toto by ta malo naviest na spravnu stopu :) GL