Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: Navsteva 12. 08. 2018, 21:31:42
-
Zdar!
Provozuji svůj Linuxový firewall už nějaký ten pátek, ale teď mám problém a nejsem si úplně jistý, co s tím.
Vnější IP je veřejná, vnitřní síť 10.0.0.0/24
Aby zařízení mohly ven, je nastavené pravidlo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Funguje to, zařízení můžou do internetu.
Jenže vždycky na chvilku potřebuji do internetu vystrčit jedno zařízení, mám nakonfigurovaný DNAT.
iptables -t nat -A PREROUTING -p tcp --dport 3389 -j DNAT --to-destination 10.0.0.2:3389
Tj, co přijde na místní port, posunu na 10.0.0.2:3389, to funguje.
Funguje to, ale divně, pořád to vyhazuje chyby o nezabezpečeném spojení.
Myslím, že bych měl upravovat ještě odchozí pakety, nastavit SNAT.
Jenže jak?
Nějak takhle?
iptables -t nat -A POSTROUTING -p tcp -d 10.0.0.2 --dport 3389 -j SNAT --to-source MojeVeřejnáIP?
Nebo tam mám uvést přímo adaptér? (Jak?)
Nebo se o to nemusím starat, protože je zapnutá Maškaráda?
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Jsem z toho vážně zmatený. :o
Já se tím nakonec prokoušu, ale kdybyste mě chtěli popostrčit, budu rád.
-
Funguje to, ale divně, pořád to vyhazuje chyby o nezabezpečeném spojení.
Co vyhazuje chyby o nezabezpečeném spojení? Webový prohlížeč? Pak to s NATem vůbec nijak nesouvisí – buď tím prohlížečem přistupujete přes HTTP (nešifrovaný protokol), nebo sice používáte HTTPS, ale je v něm něco špatně – slabá šifra, nedůvěryhodný certifikát, nějaké soubory (styly, skripty, obrázky) se stahují přes HTTP.
-
Co vyhazuje chyby o nezabezpečeném spojení? Webový prohlížeč?
Forwarduje port 3389, takže předpokládám, že remote desktop. Ale problém bude v tomtéž - je potřeba zjistit, jak daný rdesktop klient ověřuje identitu protistrany, a opravit to.
-
Pane Jirsáku, prosím, realizujte se někde jinde.
Všem ostatním se omlouvám, nemám s tímto pánem vůbec dobrou zkušenost.
Jinak se samozřejmě jedná o RDP a jsem dost přesvědčený, že je to chybějícím SNATem, který bohužel neumím nastavit.
-
Ale problém bude v tomtéž
Není, pokud použiji krabičku od ASUSu nebo se připojím přímo, spojení funguje korektně.
-
Když to máte těžké, když jste nenapsal ani jakého RDP klienta a server používáte a o jakou „chybu zabezpečení“ jde.
Není, pokud použiji krabičku od ASUSu nebo se připojím přímo, spojení funguje korektně.
Třeba si to pamatuje IP adresu. RDP neznám, ale pokud bych předpokládal, že to funguje stejně jako SSH, tak to si do known_hosts ukládá mapování klíčů a adres. A pokud to naopak používá PKI, tak v certifikátu bude adresa/hostname, který při DNATování máte nejspíš jinou.
-
Jinak se samozřejmě jedná o RDP a jsem dost přesvědčený, že je to chybějícím SNATem
Já jsem zase dost přesvědčený, že RDP vytvoří TCP spojení, a co je pod tím, je mu úplně fuk.
-
Bez bližšího info o chybě je to hádání z křišťálové koule.
Jeden z odhadů ... netýká se to žádného z NATů, ale přímo RDP (vlastnost). Hledat něco na styl:
https://social.technet.microsoft.com/Forums/windowsserver/en-US/f843bcd7-8a97-4c9f-9310-c6220a343544/remote-desktop-connection-rdcrdp-security-warning (Byť se popisuje info pro XP, u W7 to občas řvalo také, imho obecný problém. )
https://blogs.technet.microsoft.com/askpfeplat/2017/12/18/remote-desktop-connection-rdp-certificate-warnings/
-
S NATem to nemá nic společného a bez AD/CA/GPO a dalšího značného voseru tomu nebude nikdy jinak.
-
A ještě bych dodal, že již značnou dobu se používá TCP i UDP současně.
-
Z druhého výše uvedeného odkazu: "Let’s be clear on one thing: The warning messages / pop-ups that end users see connecting via RDP are a GOOD THING. Microsoft wants you to be warned if there’s a potential risk of a compromise."
Další věc: vystavit do internetu službu remote desktop na standardním portu je pozvánkou pro pokusy o útok, dále tím říkáte: tady mám Windows, pojďte to zkusit hacknout.
Nejlepší je použít VPN a když to nejde, tak aspoň službu (zvenku) provozovat na jiném čísle portu, a to dost vysokém - tím se zbavíte aspoň script kiddies. Cílenému útoku na vás pomůže jen ta VPN.
-
Pane Jirsáku, prosím, realizujte se někde jinde.
Všem ostatním se omlouvám, nemám s tímto pánem vůbec dobrou zkušenost.
Jinak se samozřejmě jedná o RDP a jsem dost přesvědčený, že je to chybějícím SNATem, který bohužel neumím nastavit.
Váš problém je, že se upnete na nesmysl, ke kterému jste dospěl bůhvíjak, a nenecháte si poradit od zkušenějších. A to se týká obou vašich problémů. Ale když jste přesvědčený, tak jste přesvědčený, já vás o opaku přesvědčovat nebudu.
-
a nenecháte si poradit od zkušenějších
A to myslíš jako sebe jo ;D ;D ;D
Ty chceš zabít půlku Fóra, smát se v horku, to je o infarkt ;D
-
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Vážně nejsem expert na IPtables, ale pokud je nastavená maškaráda na výstupu, nemusíš dělat SNAT.
-
...
Další věc: vystavit do internetu službu remote desktop na standardním portu je pozvánkou pro pokusy o útok, ...
heh ... utok na libovolnej nestandardni port ti prijde pozdejs presne o tech par vterin co trva proscanovat vsechny porty. Zato se z mnoha korporatnich siti na nestandardni port nepripojis vubec.
Váš problém je, že se upnete na nesmysl, ke kterému jste dospěl bůhvíjak, a nenecháte si poradit od zkušenějších. A to se týká obou vašich problémů. Ale když jste přesvědčený, tak jste přesvědčený, já vás o opaku přesvědčovat nebudu.
Zavri hubu jirsaku, zvanis picoviny o vecech o kterych viz hovno coz se nalezite projevilo, kdyz picujes o http pricemz jde o rdp.
...
Kristalova koule ju? Tyhle pindy o zabezpeceni widle picujou, pokud se z w7+ pripojujes na XPlike widle (trebas i 2k3 server) NEBO ... nemas zaskrtnuto v nastaveni RDP pouzivat zabezpeceni na sitovy vrstve. Pokud na ne lezes z XP like systemu, tak to samo nepinda nic. Samo pokud tohle nastavis na strane serveru, tak se na nej z XP uz nepripojis.
A priste se nauc napsat doslova to co ti to hlasi, protoze bez ty hlasky vime kulovy.
-
Hele, ty tomu rozumíš, musí dávat SNAT když používá maškarádu na kompletní výstup nebo nemusí?
To je asi tak jediné, co se mu na to dá napsat. Mimo to, samotného mě to zajímá.
-
Hele, ty tomu rozumíš, musí dávat SNAT když používá maškarádu na kompletní výstup nebo nemusí?
To je asi tak jediné, co se mu na to dá napsat. Mimo to, samotného mě to zajímá.
Jéčko že by něčemu rozumělo?
Maškaráda je druh SNATu – SNAT obecně mění zdrojovou IP adresu, maškaráda mění zdrojovou IP adresu konkrétně na IP adresu rozhraní, kterým paket odejde. Takže když používá maškarádu, používá SNAT.
S problémem nezabezpečeného spojení to vůbec nijak nesouvisí, protože SNAT i DNAT mění jen IP adresy paketů. Chybná konfigurace SNATu nebo DNATu může způsobit, že se spojení naváže se špatným serverem nebo se nenaváže vůbec. Když se ale TCP/IP spojení podaří navázat, nemají příslušná zařízení jak zjistit, že je mezi nimi NAT, pokud si nepředávají přímo IP adresy. Pokud by si předávala přímo IP adresy, asi by to bylo opět kvůli navázání jiného spojení (jako to dělá třeba FTP), ale určitě by to nevedlo na hlášku o nezabezpečeném spojení.
-
Hele, ty tomu rozumíš, musí dávat SNAT když používá maškarádu na kompletní výstup nebo nemusí?
To je asi tak jediné, co se mu na to dá napsat. Mimo to, samotného mě to zajímá.
SNAT === ta maskarada.
-A POSTROUTING -s $IN -o eth0 -j SNAT --to-source $OUT
Tohle je priklad jak prelozit interni adresu na externi (trebas mas vic externich, a chces pridelovat ruzny). Maskarada nedela nic jinyho, nez ze veme existujici IPcko (ktery se muze menit) na pozici $OUT. Je to jen specialni pripad tohoto, urcenej pro spojeni s dynamickou IP.
Beznej natujici router dela prave jen tohle = zvenku se ("legalne") pripojit nejde (== jde, snadno, ale ne pomoci standardni funcionality), odchozi komunikaci si zapisuje (port + ip) a odpovedi predava na spravnej stroj uvnitr. Coz u nekterych krabek muze vist az k vycerpani veskery rameti - trebas pokud pouzivas torrent, kterej muze generovat tisice konexi.
Mno a prave pokud chces, aby se slo pripojit zvenku, potrebujes jeste dnat ... kterej forwardne port ... a pak jeste bambiliardu polonefunkcnich helperu, protoze hromada aplikaci ocekava, ze ten defaultni port slouzi jen k navazani spojeni ktery se pak odmigruje jinam. Proto je NAT zlo, ktery je treba potirat a nicit kdekoli se vyskytne.
-
Maškaráda je druh SNATu – SNAT obecně mění zdrojovou IP adresu, maškaráda mění zdrojovou IP adresu konkrétně na IP adresu rozhraní, kterým paket odejde. Takže když používá maškarádu, používá SNAT.
Jenom ještě doplním, že Linuxový NAT se konfiguruje z pohledu toho, kdo navazuje spojení. Technicky, když máte klasickou síť s privátními adresami za NATem a chcete, aby zařízení z té sítě měla přístup do internetu, musíte u paketu, který odchází z té sítě, změnit zdrojovou IP adresu (což je SNAT – source NAT), ale když z internetu přijde odpověď, musí se adekvátně upravit cílová IP adresa, aby se paket dostal v privátní síti k počítači, který poslal požadavek. Technicky se tedy na tom paketu, který přijde jako odpověď, dělá DNAT (destination NAT).
V Linuxu (iptables) se to ale konfiguruje jenom pro ty odchozí pakety jako SNAT (případně jako specifický případ SNATu – maškaráda), a jádro už samo ví, že pro příchozí pakety musí udělat inverzí operaci. Stejné je to pro DNAT – konfiguruje se jen pro odchozí pakety, ale jádro opět ví, že pro příchozí pakety musí udělat inverzní operaci a u příchozích paketů mění inverzně zdrojovou IP adresu.
-
Jedeš?!!!
Kolik lidí ti tu řeklo, abys dal pokoj?
-
v tomto konkretnom pripade by ti to fungovalo aj bez maskarady (z vonku) a aj bez SNATU (co je vlastne maskarada), vzhladom na to, ze prichadzajuci paket presmerujes na vnutornu(cielovu) adresu (zdrojova adresa sa nezmeni), a naspat pojde paket podla default routy smerom von.. Cize toto nie je Tvoj problem. Ak mas problem s divnymi hlaskami tak je za tym nieco ine,.
-
a aj bez SNATU (co je vlastne maskarada)
To si moc nemyslím.
Jak by ten firewall věděl, kam má ten provoz forwardovat? Tj. DNAT potřebuje.
A do internetu nemůžeš pouštět nic s odchozí adresou 192.168./10.0./172.0/ atd. proto je SNAT taky potřeba.
SNAT === ta maskarada.
-A POSTROUTING -s $IN -o eth0 -j SNAT --to-source $OUT
Hele, proč se používá SNAT ručně nastavená pravidla místo kratšího:
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Aby pravidla byla jasnější a bylo to přehlednější?
Nebo pro to jsou bezpečnostní důvody?
-
Z internetu pride paket zdroj: nejaka_verejnaIP a ciel jeho_verejna_IP:3389..
Pomocou DNAT zmeni ciel na jeho_vnutorna_IP .. Cize paket, ktory pride k serveru ma tvar nejaka_verejnaIP -> jeho_vnutorna_IP:3389... Server odpovie s adresou jeho_vnutorna_IP:3389 -> nejaka_verejnaIP.. Lenze on uz vnutrornu siet zamaskovanu ma..
Zrejme nejak v tvare -A POSTROUTING -o interface_smerom_do_netu -j MASQUERADE
...Toto pravidlo tam ma uz davno pokial chce aby servery z vnutornej siete mali pristup do netu. Cize paket pojde jednoducho default routou smerom von.. Vnutorna IP sa zamaskuje za vonkajsiu routerovsku.. Ak to ma takto, tak musi len nastavit DNAT.. Ziaden SNAT tam dorabat nemusi (pretoze ho uz ma)..
-
Tak to promiň, nebylo zřejmé, že to vztahuješ na jeho defaultní konfiguraci.
-
A do internetu nemůžeš pouštět nic s odchozí adresou 192.168./10.0./172.0/ atd. proto je SNAT taky potřeba.
Jedině pokud ten server, kam se z venku připojuje, chce také navazovat komunikaci do internetu. K tomu, aby byl jen dostupný z internetu (třeba jako SSH server nebo jako HTTPS server) je potřeba nakonfigurovat jenom ten DNAT, protože (jak jsem vysvětloval výše) u paketů v opačném směru dělá linuxové jádro inverzní operaci k SNATu/DNATu samo automaticky.
Stručně řečeno, když potřebujete z privátní sítě na internet, potřebujete jen SNAT. Když naopak chcete přesměrovat veřejnou IP adresu do vnitřní sítě, potřebujete jen DNAT. Pokud chcete, aby ten server byl pod tou veřejnou IP adresou dostupný i z té vnitřní sítě, potřebujete DNAT i SNAT – SNAT proto, aby se paket od serveru vrátil na router/NAT, který provede tu inverzní operaci k DANTu. Bez SNATu odpoví server přímo klientovi v privátní síti, jenže jako odchozí uvede svou privátní IP adresu, zatímco klient navazoval spojení s veřejnou IP adresou. Tím pádem klient dostane odpověď na navázání spojení, které ale nenavazoval (nesedí IP adresa) a paket zahodí jako neplatný.
Ziaden SNAT tam dorabat nemusi (pretoze ho uz ma)..
Nikoli, pro příchozí komunikaci tam žádný SNAT nastavovat nemusí proto, že inverzní operaci k SNATu/DNATu dělá linuxové jádro automaticky. To, že tam má SNAT/maškarádu nemá na příchozí komunikaci na ten server žádný vliv – je to potřeba jenom proto, aby ten server samotný mohl navazovat spojení do internetu (např. kvůli DNS nebo aktualizacím). Kdyby tam SNAT/maškarádu neměl a měl tam jenom DNAT, pořád se z venku na ten počítač připojí.
Když v iptables konfigurujete SNAT, nakonfigurujete změnu zdrojové IP adresy u odchozích paketů a změnu cílové IP adresy u příchozích paketů. Když v iptables nakonfigurujete DNAT, nakonfigurujete změnu cílové IP adresy u příchozích paketů a změnu zdrojové IP adresy u odchozích paketů (směr příchozí/odchozí je z pohledu toho počítače v privátní síti).
-
Hele, proč se používá SNAT ručně nastavená pravidla místo kratšího:
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Aby pravidla byla jasnější a bylo to přehlednější?
Nebo pro to jsou bezpečnostní důvody?
Protože u maškarády vybírá odchozí IP adresu jádro. Pokud máte na odchozím rozhraní jedinou IP adresu, je to jedno. Pokud jich tam ale máte víc, typicky chcete určit, za kterou IP adresou bude ta maškaráda schovaná. Třeba síť uživatelských PC schováte za jednu IP adresu, ale server schováte za jinou, protože nechcete, aby se ta IP adresa serveru dostala na blacklist, pokud bude nějaké uživatelské PC škodit a třeba rozesílat spam.
-
v tomto konkretnom pripade by ti to fungovalo aj bez maskarady (z vonku) a aj bez SNATU (co je vlastne maskarada), vzhladom na to, ze prichadzajuci paket presmerujes na vnutornu(cielovu) adresu (zdrojova adresa sa nezmeni), a naspat pojde paket podla default routy smerom von.. Cize toto nie je Tvoj problem. Ak mas problem s divnymi hlaskami tak je za tym nieco ine,.
Ne, tak to by opravdu nefugovalo ...
Boze lidi, nez neco napise tak si o tom neco zjistete ...
NAT dela presne toto:
Paket src=X, dst=Y ... prijde z interni site. Tzn X je PRIVATNI IP, Y je VEREJNA IP
Nat PREPISE src=K ... kde K je VEREJNA IP natujici krabky.
Cil (Y) tedy dostane paket src=K, dst=Y. Odpoved vraci v podobe paketu src=Y, dst=K
Tudiz neodpovida vlastne X, ale K. Kdyz paket dorazi K, tak ten ale VI (=ma ulozeno v nat tabulce) ze muze dojit odpoved od Y, a tudiz opet zmeni tentokrat na paket src=Y, dst=!!X!! ... a tenhle paket normalne odroutuje = protoze vi ze na internim rozhrani ma ten privatni rozsah, posle to prave tam.
A presne na tomhle je zalozenej i princip jak projit NATem zvenku dovnitr. KAZDEJ router odroutuje paket, pro kterej zna cestu. Pokud tudiz na K prijde paket s dst X, tak se nebude natovat (neodpovida ocekavany odpovedi) ale bude se routovat = doruci se. Takovej paket by sice hypoteticky nemel dorazit, protoze hypoteticky by kazdej router na internetu mel privatni rozsahy at uz v src nebo dst zahazovat. Ale spousta z nich to nedela.
Bonusem tu pak jeste je sourcerouting = do paketu se daj vymenovat routery(IPcka) pres ktery ma paket putovat. U NATu staci vyjmenovat dve - verejnou adresu natu a cilovou privatni adresu. 99% soho krabek tohle doruci.
Proto je velice podstatny mit spravne nastavenej firewall, kterej presne tohle znemozni. A proto kazdej, kdo tu breci jak nutne potrebuje nat aby ochranil svoji sit je nebetycnej kokot. Protoze prave kvuli tem zmenam adres v prubehu dorucovani paketu neni vubec jednoduchy (=je to hromada pravidel ktery sou vlastne nadbytecny) ten firewall nakonfigurovat spravne. Narozdil od situace, kdy jsou na obou stranach verejny rozsahy, a tudiz se da jednoduse rict, ze se nemaji dorucovat pakety do rozsahu vnitrni site.
...
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Aby pravidla byla jasnější a bylo to přehlednější?
Nebo pro to jsou bezpečnostní důvody?
Ne kazdej chce aby se mu IPcka menila jak si router zrovna usmysli, a nekteri maji verejnych IPcek vic, a ruzny adresy maji ruzny ucely. Maskarada navic historicky mela ponekud jiny (a velmi neprijemny) vlastnosti. Zcela bezne muzes mit trebas od ISPka pridelenou krome verejny jeste privatni adresy a na ty rozhodne nic natovat nechces.
Nekdy se bez toho bohuzel neobejdes.
-
Najlepsie nastartovat virtualky, tcpdump a overit si to osobne.. :D
-
Tak som si to checkol, ospravedlnujem sa..Ano treba robit aj SNAT/MASQUERADE na odchadzajucom interfacy smerom do vnutornej siete.. Povodne MASQUERADE pravidlo sa aplikuje na nove spojenia smerom zvnutra, cize toto spojenie nijako neovplyvni..
Cize aby to fungovalo musis robit na routri v PREROUTINGu DNAT na vnutornu IP a nasledne v POSTROUTINGU SNAT alebo MASQUERADE.
-
Tak som si to checkol, ospravedlnujem sa..Ano treba robit aj SNAT/MASQUERADE na odchadzajucom interfacy smerom do vnutornej siete.. Povodne MASQUERADE pravidlo sa aplikuje na nove spojenia smerom zvnutra, cize toto spojenie nijako neovplyvni..
Ano, tak je to správně. O přepsání cílové adresy paketu, který je odpovědí na paket, na kterém byl proveden DNAT, se postará samotné jádro. Jedině to má totiž dostatek informací.
Cize aby to fungovalo musis robit na routri v PREROUTINGu DNAT na vnutornu IP a nasledne v POSTROUTINGU SNAT alebo MASQUERADE.
Nesmysl. Výše jsem to vysvětloval, vyzkoušejte si to. Na to, abyste dělal reverzní NAT, nemáte k dispozici potřebné informace. Když jádro dělá SNAT, mění zdrojovou IP adresu, ale také může změnit zdrojový port! Představte si, že máte v privátní síti dva počítače, které se oba rozhodnou přes váš NAT (SNAT, maškarádu) připojit pomocí HTTPS protokolu na portu 443 na server 1.1.1.1. Cílová dvojice adresa:port tedy bude v obou případech 1.1.1.1:443, zdrojová IP adresa bude po SNATu veřejná IP adresa routeru – ale čtveřice zdrojové a cílové IP adresy a portů identifikuje TCP/IP spojení, nemohou zároveň existovat dvě spojení, která budou mít tyto údaje stejné. Takže SNATu nezbývá, než jeden z těch odchozích portů změnit. Kdybyste pak u příchozích paketů dělal DNAT ručně, jak byste věděl, který port patří kterému počítači v privátní síti?
Takže když děláte SNAT nebo maškarádu, definujete jen pravidla pro odchozí pakety a jádro samo automaticky aplikuje reverzní pravidla na příchozí pakety (a případně samo mění port podle toho,jak ho změnilo u odchozího paketu). No a DNAT se chová úplně stejně, například protože by bylo nesmyslné, aby se to pro DNAT chovalo jinak, než pro SNAT.
-
Ano chapeme sa... V tomto konkretnom pripade sa SNAT/MASQUERADE robit nemusi.. Avsak pri zariadeniach so zlozitejsim routingom a zlozitejsej topologii siete by som ho odporucal robit (ak nevadi, ze stratime informaciu o zdrojovej IP povodneho paketu), pretoze sa lahko moze stat, ze odpoved na presmerovany paket pomocou DNAT sa bude vracat inou cestou a teda bude zahodeny reverse path filteringom. Chce to proste trochu premyslat a mat urcite skusenosti. Ja sietarinu uz dlhsie nerobim, takze sa ospravedlnujem ze moje odpovede boli zbrkle a nepresne ;)
-
Avsak pri zariadeniach so zlozitejsim routingom a zlozitejsej topologii siete by som ho odporucal robit (ak nevadi, ze stratime informaciu o zdrojovej IP povodneho paketu), pretoze sa lahko moze stat, ze odpoved na presmerovany paket pomocou DNAT sa bude vracat inou cestou a teda bude zahodeny reverse path filteringom.
Já bych spíš doporučil do routování složitějších topologií se pouštět teprve tehdy, až bude mít nějaké znalosti o sítích. A pak bude i sám schopen posoudit, zda tam ten SNAT musí být, nebo tam být nemá. Dávat někam preventivně NAT je akorát cesta do pekel, protože to zbytečně komplikuje návrh sítě a také samotný provoz, protože ten NAT se obvykle stane úzkým hrdlem. Někdy opravdu vyjde přidání SNATu k DNATu jako nejlepší řešení, to nepopírám, ale chce to k tomu přistupovat s rozmyslem. Dnes si spousta „síťařů“ nedovede síť bez NATů představit, a zapomínají při tom na to, že NAT je jenom dost ošklivý hack pro řešení nedostatku veřejných IPv4 adres.
-
Ano chapeme sa... V tomto konkretnom pripade sa SNAT/MASQUERADE robit nemusi.. Avsak pri zariadeniach so zlozitejsim routingom a zlozitejsej topologii siete by som ho odporucal robit (ak nevadi, ze stratime informaciu o zdrojovej IP povodneho paketu), pretoze sa lahko moze stat, ze odpoved na presmerovany paket pomocou DNAT sa bude vracat inou cestou a teda bude zahodeny reverse path filteringom. Chce to proste trochu premyslat a mat urcite skusenosti. Ja sietarinu uz dlhsie nerobim, takze sa ospravedlnujem ze moje odpovede boli zbrkle a nepresne ;)
To je zas odpoved, snad routing je od toho, aby se nepouzival NAT. Toho kdo pouzije ve vnitrni siti NAT (coz nema nikdy, krome nekterych serveru - i tady bych strilel za to) tak zaslouzi povesit. Co to tam ma co delat? Navic nemyslim si, ze kdyz se nekdo nevyzna v siti, tak bude mit nekde zapnuty RP filtr (myslim, ze to ani defaultne nema zadny router).
Navic tim ze se takto nevhodne pouzije NAT a bude nekde z nejakyho duvodu udelany nesmyetricky routing (zas nekde muze byt umysl, ale neni to zas idealni reseni), tak se s nim nikdo nedomluvi.
-
Navic nemyslim si, ze kdyz se nekdo nevyzna v siti, tak bude mit nekde zapnuty RP filtr (myslim, ze to ani defaultne nema zadny router).
Navíc pokud se někde dělá NAT a paket se bude vracet jinou cestou (třeba přímo), tak nebude problémem ani tak RP filtr, jako hlavně to, že paket má změněné adresy, tudíž nezapadne do existujícího spojení a bude zahozen jako nevalidní. Fungovat to bude maximálně u jednoduchých protokolů jako ICMP nebo některých jednoduchých a nezabezpečených UDP protokolů, kde se neřeší, kdo odpověď poslal.