Konfigurálja az ssh - Linux fórum - linux360 alkalmazást
nyílt forráskódú és nyitott elmék
konfigurálja az ssh-t
üzenet valakitől colombo »2006. november 8., 09:25
üzenet valakitől csdexter »2006. november 8., 09:51
/ sbin/iptables -t nat -A PREROUTING -s $ ip_permise -d $ ip_extern_router -m tcp -p tcp --dport $ port_exterior -j DNAT - to-destination $ ip_server_intern: 22
És 1000-szer elmondták
üzenet valakitől colombo »2006. november 8. 10:58
üzenet valakitől csdexter »2006. november 8., 12:06
Sine amicitia, vitam esse nullam.
üzenet valakitől Nevrax »2006. november 10. 02:31
iptables -t nat = CACA
Hagyja abba a NAT használatát Linux alatt. hogy nem jó. Nem akarok. és nem szükséges itt tartani a tűzfalak elméletét. Ha elhiszed, akkor rendben van, ha nem. megint jó
Olyan egyszerű művelethez, mint egy hülye port-továbbítás, egy egyszerű programot ajánlok, amely egy bizonyos IP-n, egy adott porton hallgat, és forgalmat küld egy adott IP-re egy adott portra.
PS: Hol vannak a régi szép idők, amikor az emberek nem kigúnyolták magukat ilyen erőforrásokkal. magasság. DNAT egy egyszerű portfólióhoz.
üzenet valakitől csdexter »2006. november 10. 10:39
Nem \ s \ h \ i \ t? Ugyan, ez nagyszerű volt, főleg az indoklás
Sine amicitia, vitam esse nullam.
üzenet valakitől bsabin »2006. november 10. 18:21
üzenet valakitől bűn »2006. november 11. 17:28
üzenet valakitől tiger_eye »2006. november 11. 19:52
üzenet valakitől Nevrax »2006. november 11. 22:44
bűn, megérteni, hogy minden, amit ezen a fórumon írok, aberrációk?
ha valami kapcsolódik ehhez a szálhoz, kérlek, mondd el, hogy mi nem ok.
üzenet valakitől bűn »2006. november 12. 14:52
egy kapcsolatkövető kapcsolat kevesebb, mint 300 bájt memóriát fogyaszt. az átirányítóval ellátott megoldás tz-szer több memóriát emészt fel.
hogyan jutottál arra a következtetésre, hogy a NAT-ot linuxon csinálni rossz dolog? ha nem bánod, mondd el, milyen tűzfalelméletet tudsz ?
üzenet valakitől Nevrax »2006. november 12. 17:30
Azt javaslom, kezdjük azzal, hogy megnyugszunk
Nem akarok végtelen vitát kiváltani ebben a témában, ezért _próbálok_ a lehető legrövidebb lenni.
Helytelen. Az érvelésed gyerekes és megalapozatlan, mert valószínűleg nem tudod, mi történik valójában. Miért csak a kapcsolat által elfogyasztott memóriáról beszél? Miért nem beszélsz más érintett erőforrásokról, hogy ilyen kapcsolat legyen? Miért nem mondja meg, hogy milyen előadások vannak a két megoldás között? Miért nem magyarázza el a kockázatokat?
Táblázat nat követni kell a kapcsolatokat. Ez a követés egy hash-on alapul, amely nem cserélhető memóriát foglal el. Van ötleted arról, hogy milyen könnyen érheted el a hash maximális határát? Gondolom, tudod, mi következik!
a átirányító újra felhasználja ugyanazt a puffert, amelyet a kapcsolat megszűnésekor kiad. Valószínűleg most már jobban meg fogja érteni, miért nem lehet 10 MB átvitelt végrehajtani NAT alatt az iptables segítségével. Célszerű megválaszolni a reagálási időt és a csomagonként/másodpercenként nagy számban felhasznált erőforrásokat.?
Sokéves munka, tanulmányok és gyakorlat után jutottam erre a következtetésre. Nagyon bonyolult megoldásokat dolgoztunk ki a NAT-on alapuló Linux alatt. Ha azt mondom, hogy összetett, akkor hatalmas tömböket értek, több ezer szabály segítségével több ezer más iptables szabály létrehozásához. Jelenleg ez a rendszer képes kezelni olyan egyszerű szabályokat, mint a SNAT/DNAT, valamint a NAT tucatnyi szolgáltatáshoz, például a pptp, gre, ftp, irc stb.
Ahhoz, hogy egy ilyen rendszer megfelelően működjön, olyan optimalizálásokra van szükség, mint a hash, notrack, pps limit stb. Ha figyelembe vesszük a szabályok különböző kritériumok szerinti csoportosításának szükségességét, nyilvánvalóan megnő a rendszeradminisztráció bonyolultsága.
A megoldás fejlesztése és optimalizálása idővel megtörtént, mindig beszámolt nekem arról, hogyan fejlesztették az iptables projektet a www.netfilter.org oldalon. .
Ennyi év után azt hiszem, van elég érvem a következők támogatásához:
NE használjon iptables -t nat Linux alatt. A nyers, a mangrove vagy a szűrő táblák problémamentesen használhatók.
Az iptables -t nat még olyan egyszerű szabályoknál sem érdemes használni, mint az SNAT az IP-n vagy a port 'átirányítás'. Ha a halottaknál akarsz maradni a házban. ez az.
Ésszerű felismerni, hogy egy ilyen témának nincs helye ezen a fórumon. Ehelyett adhatok néhány ötletet.
A tűzfal „meghatározása”, ahogy látom, a következő lenne: A tűzfal az elvont erőforrások kezelésének összetett rendszere annak érdekében, hogy jól definiált végleges szabályok legyenek alávetve.
Általánosságban sok a zavar a tűzfalak és az iptables között, és a NAT csak egy _kisebb_ része annak, amit a tűzfal valójában jelent. A NAT viszont többféle. A végső céltól függően a megfelelő NAT-t kell választani.
A tűzfal másik nagyon fontos aspektusa a DoS típusú támadások, ahol (és fáj a szívemnek) a NAT a Linuxban hatalmas problémákat okozhat. Csak akkor használd a NAT-ot, ha ügyes vagy, és tudod, hogyan kell irányítani.
Körülbelül a NAT a Linux-ban.
Megjegyzés: ha valaki tisztázást szeretne, szívesen ajánlhatok tanácsadási órákat, nyilvánvalóan térítés ellenében. Jogom felajánlani vagy nem indokolni az általam támogatott ötleteket.
üzenet valakitől mali »2006. november 12. 21:26
pontosan ezt akarja. ha a szállítmányozó cserélni kezd, akkor a teljesítmény valóban folytatódott ****.
van egy ötleted, hogy mennyire könnyen beállíthatod a határt, ha az valóban problémává válik?
nem tud? korlátozás van érvényben hangerő adatok (MB)? ha létezik, akkor csak benned létezhet. amellett, hogy megértse, hogy az átirányító támogatja a port aktív csatlakozási részét?!
netfilter NAT nincs szükség pufferre mert ne másolj adat. csak egy minimális információra van szüksége a kapcsolat nyomon követéséhez. Találd ki? egy átirányítónak is követnie kell a kapcsolatot, és ehhez sokkal több erőforrást használ (még akkor is, ha nem veszi észre).
te vagy a csúcs. panaszkodik a NAT netfilter rezsire, de "ajánl" felhasználói tér megoldást?! "elfelejtett" néhány apró részletet:
1) A felhasználói terület átirányítóhoz társított erőforrások nagyon drágább, mint amit az iptables használ a conntrackhez: folyamat, socketek, fájlleírók, másolási puffer stb.
2) A netfilter végrehajtja a nulla másolatú NAT-ot, míg a megoldás 2x hiába másolja az adatokat: kernel skb -> buffer userspace, buffer userspace -> kernel skb
3) az átirányító az adatokat a teljes TCP/IP-veremen keresztül kényszeríti (2-szer), miközben a NAT a lehető legalacsonyabb szinten működik, és még egyszer sem gyakorolja a teljes veremet.
4) a felhasználói tér átirányítója látens ütemezést vezet be.
ráadásul az Ön által javasolt átirányító nem egyenértékű a DNAT-mal, mert módosítja a csomagok forrását (a szerver úgy látja, hogy az átirányítótól érkeznek, nem az ügyféltől, az átirányítás nem átlátszó). az alkalmazástól függően ez nagy problémákat okozhat (az ssh konkrét példán: csak meggyilkoltad a gazdagép-alapú hitelesítést).
Azt hiszem, nem érted, hogy mi történik valójában: a netfilter NAT az átirányító (sokkal) optimalizált verziója
a netfilter/conntrack skálázhatósági kérdései jól ismertek, és előfordulhat olyan szélsőséges szkennelés, amelyben egy buta felhasználói tér-átirányító megveri a szabályokhoz ragaszkodó netfiltert. de általánosítani az "iptables -t nat = CACA" kifejezésre idiótaság, mert az esetek 99% -ában fejjel lefelé fordult a helyzet: az átirányítónak nemcsak sokkal több erőforrásra van szüksége a kapcsolat nyomon követéséhez, hanem ha megpróbálja méretezni a netfilterrel azonos szinten sokkal nagyobb problémákkal jársz.
üzenet valakitől Nevrax »2006. november 13., 01:00
mali, örülök a bemutatott részleteknek. Így mások megtudhatják egyes dolgok működését. Jó volt, ha készített egy kis dokumentációt
Kár, hogy semmi köze ahhoz, amit ott mondok. Józan ész volt, hogy elolvastam az előző bejegyzéseket is. Ha mégis úgy döntöttél, hogy kommentálod a bejegyzésemet, miért nem tetted meg többet _figyelem_?
_Három_ választ adtam _három_ bűnmegállapításra. Az átirányítót nem az _all_ NAT helyettesítésére szolgáló megoldásként, hanem egy _szimpla_ port elhagyásának alternatívájaként mutattuk be!
Ha nincs szükségem átlátható átirányításra vagy gazdagép alapú hitelesítésre, vagy bármilyen más csodára, van valami probléma? Mondta valaki, hogy skálázható megoldást szeretne? Ezzel a megoldással kapcsolatban mondtam, hogy összetettebb, mint a NAT? Legyen óvatosabb kérem!
Fentebb egy komplex rendszert mutattam be. Ha nem volt egyértelműen megértve, akkor ismétlem, a rendszer 100% -osan működik_ a netfilter alapján. Olyan optimalizálásokat is meghatároztam, mint a hash, notrack, pps limit stb. Ezzel a megoldással kapcsolatban mondtam valamit az átirányítóról? Legyen óvatosabb kérem!
Úgy tűnik, józan ész, hogy a világ tudja, hogy vannak alternatívák. Segítsen nekik jobban megérteni, mi a végső céljuk, hogy a megfelelő megoldást választhassák.
Miért tölted be a fejüket iptable-vel, amikor valójában hülye átirányítást akarnak?
Miért nem mondja el nekik, hogy nagy problémáik lehetnek a nat táblával, ha nem tudják, hogyan állítsák összefüggésbe a nyers, a mangrove vagy a szűrővel? Gondolod, hogy egy egyszerű átirányítást kérő személy is tudja, hogyan kell figyelni az ellentámadását?
A netszűrőben lévő NAT-ot nagy időpazarlásnak tartom az életemben. Tanulhattam volna valami _hasznosabbat_, ha időben helyesen vezetnek.
Pontosan ezt csinálom. „hangoztassa” a véleményeket, mert Véleménycserét akarok és nem érvet! Gyakran az őrzött ember véleménye sokkal értékesebb, mint egy tankönyv több száz oldala.
Nagyra értékelem azt, akinek jó akarata van elmondani, milyen véleménye van egy témáról, bármi is legyen az. Ez nem azt jelenti, hogy meg kell tennie ... hogy érveket adjon nekem.