Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: aidam 18. 09. 2018, 13:26:58
-
Mám router Teltonika RUT230 nastavený jako OpenVPN server. LAN rozsah je 172.16.10.0/24 a router má IP adresu 172.16.10.1 Po připojení k OpenVPN serveru mi funguje ping na zařízení v LAN serveru, která mají vyplněnu gateway. Jsou tam i zařízení, která gateway vyplněnou nemají. Je možné přidat do routeru pravidlo (IPTABLES), které by definovalo výchozí gateway? Tak aby odpověď na ping na zařízení byla bez definované gateway byla nasměrovaná do bránu routeru?
-
Ne, protoze to zarizeni nekomunikuje primo s routerem, urcite tam je nejaky switch mezi tim. Co by slo pouzit, last-resort IP na switchi.
-
původní router, co tam používali takto fungoval. Jen v té Teltonice to není defaultně povoleno a nevím jak to povolit. Zřejmě to musí jít přes iptables.
-
Ahoj, na routri mozes urobit SNAT pravidlo, takze ping so source IP z ineho subnetu bude mat prelozenu source IP na 172.16.10.1 a zariadenie v sieti 172.16.10.0/24 odpovie bez nutnosti mat nastavenu GW.
takto nejako by to malo vyzerat, len to treba upravit v zavislosti co vsetko chces NATovat
iptables -t nat -A POSTROUTING -i ethX -o ethX -j SNAT --to 172.16.10.1
-
ahoj,
diky za odpoved. Asi mam trochu jiny problem. Podle me, ping mi pres pripojenou vpn do site 172.16.10.0/24 projde, ale odpoved od zarizeni, ktere nema nastavenou GW, tak nevi kam se odeslat.
Tady je log z WireSharku
9 3.018075 10.0.5.6 172.16.10.10 ICMP 74 Echo (ping) request id=0x0001, seq=2383/20233, ttl=128 (reply in 10)
10 3.060095 172.16.10.10 10.0.5.6 ICMP 74 Echo (ping) reply id=0x0001, seq=2383/20233, ttl=29 (request in 9)
11 4.768100 10.0.5.6 172.16.10.20 ICMP 74 Echo (ping) request id=0x0001, seq=2384/20489, ttl=128 (no response found!)
Radky 9 a 10 jsou ping na zarizeni s nastavenou GW a radek 11 je bez odpovedi ze zarizeni bez nast. GW.
-
Ano a presne to by ti vyriesil SNAT. V riadku 11 by si po NATe mal:
11 4.768100 172.16.10.1 172.16.10.20 ICMP 74 Echo (ping) request id=0x0001, seq=2384/20489, ttl=128
tym padom by zariadenie vedelo odpovedat - odpoved by dosla na tvoj router ten by to "odNAToval" a poslal na povodny source.
-
Tak přesně tohle by SNATem nevyřešil. Toto bude zase dlouhý příběh, protože se do sítí montují lidi, kteří jim nerozumí a další podobní těm ubožákům ještě radí. Pokud neexistuje routing pravidlo (a default GW je taky routing pravidlo), ale adresa spadá do rozsahuj IP/netmask nějakého rozhraní, vygeneruje se ARP dotaz. Pokud na ten dotaz něco odpoví, zavede se ARP pravidlo, pokud ne, prohlásí se cíl za nedostupný (ARP nekompletní).
Tady je otázka, PROČ některé stroje nemají nastavenu default GW, nebo obecně routing pro VPN na daném přístupovém bodě. Připadá mi to jako opravdu velká hloupost.
Řešení pochopitelně existuje. Na stroji, na kterém běží VPN, se udělá ARP proxy pro rozsah na druhé straně té VPN, protože VPN podrozsah spadá do rozsahu v přídělu těch zařízení bez GW (nebo se to tak dá alespoň zařídit), tak to takhle půjde, protože ty stroje bez DG vyprodukují ARP request, na který dostanou reply z ARP proxy, čímž se ten packet na eth vrstvě nasměruje na VPN.. Nicméně řešení je to opravdu zvláště špatné, je to takříkajíc jak posrat se v kině. Bohužel každý protějšek pro takové zařízení vyprodukuje zápis v ARP tabulce, která tím pádem velice rychle dojde, neb adresní prostor "za vpn" může být dost velký, tudíž těch ARP requestů bude v síti lítat jak Pačínkovejch (ARP tabulka odhazuje nejdéle nepoužité záznamy). A na ARP request reaguje každá mašina ve stejném okruhu (lépe řečeno, reaguje jen ta VPN, ale zpracovává ten packet každá mašina), což u LAN může být opravdu velký výkonový problém pokud je tam těch zařízení bez GW opravdu hodně, alternativně komunikují se spoustou protějšků a mají opravdu malou ARP tabulku.
Tato věc je v IPv4 udělaná opravdu hodně špatně. V IPv6 by stačilo, aby ta VPN brána poslala RA a bylo by zkonfigurováno. Default GW to v IPv4 řeší pouze v situaci, kdy ta VPN běží na stroji, který zároveň zprostředkovává přístup do Internetu. Ve všech ostatních případech se pak na každé mašině musí konfigurovat routing (strašná věc), nebo se použije proxyARP (ještě horší), nebo se vytvoří separátní LAN pro VPN, nejspíše pomocí 802.1q, což je už opravdu hodně velká divočina.(I v IPv4 se zkonfigurovanou DG existuje způsob, jak z GW učit zařízení routing pro určité cíle, ale do toho tu nemínim zabíhat)
Takže zásadní otázka. PROČ jsou v síti mašiny, který nemají default GW?? Jaký to má důvod? Nejspíš se to musí řešit na dost jiném místě. Totiž default GW používají i zařízení s úplně nejprimitivnějším TCP/IP stackem. Pokud se totiž zadá její MAC namísto IP, nemusíte implementovat ARP. A to na systému s pár kB paměti opravdu znamená hodně. Čili nedovedu si představit krám, který by to neuměl. Cosi mi říká, že to dělá proto, aby ta zařízení takzvaně "nemohla na net", ale mohla do lokální sítě a teď je najednou potřeba, aby to prošlo do VPN...přičemž mezi normálními lidmi se takový provoz odfiltruje na gatewayi a normálně se tomu DG nastaví, že. A pak se to řeší, ano, jedním jednoduchým pravidlem v iptables...namísto takovýho porodu ježka bodlinama napřed... Prostě za tou komplikovanou situací cítím nějaký nesmyslnou implementaci acl.
-
děkuji za vyčerpávající odpověď. Situace je taková, že u těch strojů možnost nastavení GW je, ale není úplně jednoduché stroje odstavit a mít možnost restartovat řídicí systém. Z tohoto důvodu mne zajímá alternativa, jak nastavit tu výchozí GW alespoň dočasně, než bude možnost stroje restartovat? Bohužel nejsem síťař, mám základní síťové znalosti, proto jsem se zde dotázal. Případně jak udělat routing pro VPN, jakým pravidlem?
-
Tak přesně tohle by SNATem nevyřešil.
tak v pripade routovanej vpn by to s-nat vyriesil...
-
Nastav si tam ten SNAT, aby ti všechny src IP z VPN rozsahu maskaradoval na LAN ip routeru.
-
tak ten SNAT to vyresil, aspon docasne nez doplnim GW do zarizeni. diky za pomoc
-
Tady je otázka, PROČ některé stroje nemají nastavenu default GW, nebo obecně routing pro VPN na daném přístupovém bodě. Připadá mi to jako opravdu velká hloupost.
Zrovna tady za to mohly jakési provozní důvody, ale zažil jsem i historická zařízení, kde autor před 25 lety prostě rozhodl, že to přes IP sice komunikuje, ale jenom po lokálním ethernetu a basta. Default route to neumí. Nebo je to bug, který ale "nikdy nikomu nevadil"(TM) a novější firmware není. V "průmyslu" dost často narazíte na historické hrůzy na které se nesahá, protože se na ně nesahá. Někdy jsou to boxy dost zvučných značek. A pro trochu komfortu šel bys světa kraj.
-
Takže zásadní otázka. PROČ jsou v síti mašiny, který nemají default GW?? Jaký to má důvod?
Pokud mate sit zakruhovanou s dynamickym routingem, tak je docela dobre aby zarizeni nemelo nastavenou default GW, nybrz posilalo REPLY packety na MAC ze ktere prisel REQUEST.
-
situace u me je takova, ze jsme meli jeden router, ktery fungoval bez default GW u stroju a nyni byl nahrazen jinym a ten default branu z defaultni konfiguraci nemel. Takze to vyresilo dodatecne pravidlo pro SNAT. Bylo to i rychlejsi nez do vsech stroju GW doplnovat:-)
-
Takze to vyresilo dodatecne pravidlo pro SNAT. Bylo to i rychlejsi nez do vsech stroju GW doplnovat:-)
Prase! ::)
-
Takze to vyresilo dodatecne pravidlo pro SNAT. Bylo to i rychlejsi nez do vsech stroju GW doplnovat:-)
Prase! ::)
To ses na nej jeste slusnej...
-
spíš bych ocenil vysvětlení, proč je SNAT špatně. Zda jsou nějaká rizika tohoto řešení apod., když už je to taková "prasárna".
-
spíš bych ocenil vysvětlení, proč je SNAT špatně. Zda jsou nějaká rizika tohoto řešení apod., když už je to taková "prasárna".
Arogantne commenty si nevsimaj. Problem je hlavne strata transparentnosti, na DST uz nevidis aky bol realny SRC... Ale zalezi od case od caseu, ci je to problem, alebo nie.
-
spíš bych ocenil vysvětlení, proč je SNAT špatně. Zda jsou nějaká rizika tohoto řešení apod., když už je to taková "prasárna".
Arogantne commenty si nevsimaj. Problem je hlavne strata transparentnosti, na DST uz nevidis aky bol realny SRC... Ale zalezi od case od caseu, ci je to problem, alebo nie.
Problem je predevsim v tom, ze to nebude fungovat, a to tak ze vubec ne. Ale neni nad to vymejslet cypoviny misto konfigurace zcela funkcni a standardni ze?
-
spíš bych ocenil vysvětlení, proč je SNAT špatně. Zda jsou nějaká rizika tohoto řešení apod., když už je to taková "prasárna".
Arogantne commenty si nevsimaj. Problem je hlavne strata transparentnosti, na DST uz nevidis aky bol realny SRC... Ale zalezi od case od caseu, ci je to problem, alebo nie.
Problem je predevsim v tom, ze to nebude fungovat, a to tak ze vubec ne. Ale neni nad to vymejslet cypoviny misto konfigurace zcela funkcni a standardni ze?
Preco by to nefungovalo? Ak nemas nastavene default route, tak funguje len komunikacia do lokalnych subnetov. Ak mas interface eth0 a na nom nejaku a.b.c.x/24 siet, system ti bude generovat arp requesty na pre ipcky z danej siete...
Ak je VPN server povedzme 192.168.1.100/24, tvoje zariadenie bez def. routy je 192.168.1.200/24, tak SNATovana komunikacia z 192.168.1.100/24 BUDE fungovat... Pretoze ak je aj na opacnom konci ina, povedzme 10.10.10.0/24 siet, VPN server bude vsetku komunikaciu z toho subnetu SNATovat na svoju 192.168.1.200.
Co je na tom tak nepochopitelne?