Konfigurácia ssh - Linux Fórum - linux360
open-source a otvorené mysle
nakonfigurovať ssh
Správa od colombo »8. novembra 2006 09:25
Správa od csdexter »8. novembra 2006 09:51
/ sbin/iptables -t nat -A PREROUTING -s $ ip_permise -d $ ip_extern_router -m tcp -p tcp --dport $ port_exterior -j DNAT - do cieľa $ ip_server_intern: 22
A bolo to povedané 1000 krát
Správa od colombo »8. novembra 2006 10:58
Správa od csdexter »8. novembra 2006 12:06
Sine amicitia, vitamíny esse nullam.
Správa od Nevrax »10. novembra 2006 02:31
iptables -t nat = CACA
Prestaňte používať NAT v systéme Linux. že to nie je dobré. Nechcem. a nie je potrebné tu držať teóriu brány firewall. Ak mi veríte, je to v poriadku, ak nie. opäť dobre
Pre akciu jednoduchú ako hlúpe presmerovanie portov odporúčam jednoduchý program, ktorý počúva na určitej IP, na určitom porte a odosiela prenos na určitú IP na určitý port.
PS: Kde sú staré dobré časy, keď si ľudia zo seba nerobili srandu týmto spôsobom zdrojov. výška. DNAT pre jednoduchý portfwd.
Správa od csdexter »10. novembra 2006 10:39
Nie \ s \ h \ i \ t?! No tak, to bolo super, hlavne odôvodnenie
Sine amicitia, vitamíny esse nullam.
Správa od bsabin »10. novembra 2006 18:21
Správa od hriech »11. novembra 2006 17:28
Správa od tiger_eye »11. novembra 2006 19:52
Správa od Nevrax »11. novembra 2006 22:44
hriech, aby som pochopil, že všetko, čo napíšem na tomto fóre, sú aberácie?
ak niečo súvisí s týmto vláknom, povedzte mi, čo nie je v poriadku.
Správa od hriech »12. novembra 2006 14:52
pripojenie na sledovanie spojenia spotrebuje menej ako 300 bajtov pamäte. vaše riešenie s presmerovačom spotrebuje tzkrát viac pamäte.
ako si prisiel na to, ze robit NAT na linuxe je zle? Ak vám to neprekáža, povedzte nám, akú teóriu brány firewall poznáte ?
Správa od Nevrax »12. novembra 2006 17:30
Navrhujem, aby sme začali upokojením
Nechcem v tejto veci vyvolávať nekonečné kontroverzie, preto sa pokúsim __ byť čo najkratší.
Nesprávne. Váš argument je detinský a nepodložený, pretože pravdepodobne nepoznáte podrobnosti o tom, čo sa v skutočnosti deje. Prečo hovoríte iba o pamäti spotrebovanej spojením? Prečo nehovoríte o ďalších zapojených zdrojoch, ktoré majú toto spojenie? Prečo nepoviete, aké sú výkony medzi týmito dvoma riešeniami? Prečo nevysvetlíte, aké sú riziká?
Tabuľka nat sledovanie potrieb pre spojenia. Toto sledovanie je založené na haši, ktorý zaberá nevymeniteľnú pamäť. Máte predstavu, ako ľahko dosiahnete maximálnu hranicu tohto hashu? Asi vieš, čo ďalej!
a redirector znovu použije rovnakú vyrovnávaciu pamäť, ktorú uvoľní po ukončení spojenia. Pravdepodobne už lepšie pochopíte, prečo nemôžete mať 10 MB prenos v rámci NAT s iptables. Má tiež zmysel diskutovať o čase odozvy a zdrojoch spotrebovaných vo veľkom množstve na paket za sekundu.?
K tomuto záveru som dospel po mnohých rokoch práce, štúdií a praxe. V systéme Linux sme vyvinuli veľmi komplexné riešenia založené na NAT. Keď poviem zložité, mám na mysli obrovské polia s tisíckami pravidiel používaných na generovanie ďalších niekoľkých tisíc pravidiel iptables. V súčasnosti tento systém dokáže spravovať jednoduché pravidlá ako SNAT/DNAT a NAT pre desiatky služieb ako pptp, gre, ftp, irc atď.
Aby takýto systém fungoval správne, potrebujete optimalizácie, ako je hash, notrack, limit pps atď. Ak vezmeme do úvahy potrebu zoskupiť pravidlá podľa rôznych kritérií, samozrejme sa zvýši zložitosť správy systému.
Vývoj a optimalizácia riešenia prebiehali v priebehu času, pričom mi vždy hlásili, ako bol projekt iptables vyvinutý na www.netfilter.org .
Po všetkých tých rokoch si myslím, že mám dostatok argumentov na podporu nasledujúcich vecí:
V Linuxe NEPOUŽÍVAJTE iptables -t nat. Surové, mangrovové alebo filtračné tabuľky je možné používať bez problémov.
iptables -t nat sa neoplatí používať ani pre jednoduché pravidlá ako SNAT na IP alebo „presmerovanie“ portu. Ak chcete zostať s mŕtvymi v dome. to je všetko.
Je logické si uvedomiť, že takáto téma tu na tomto fóre nemá miesto. Namiesto toho vám môžem dať niekoľko nápadov.
„Definícia“ brány firewall, ako ju vidím, by bola nasledovná: Brána firewall je komplexný systém správy abstraktných zdrojov, aby sa na ňu vzťahovali pravidlá s presne definovaným konečným účelom.
Vo všeobecnosti existuje medzi firewallmi a iptabuľkami veľa nejasností a NAT je iba _small_ časťou toho, čo firewall vlastne znamená. Na druhej strane je NAT niekoľko typov. V závislosti od konečného účelu musí byť zvolený správny typ NAT.
Ďalším veľmi dôležitým aspektom vo firewalle sú útoky typu DoS, kde (a bolí ma to na srdci) NAT v Linuxe môže spôsobiť obrovské problémy. NAT používajte, iba ak ste dobrí v tom, čo robíte a viete, ako to ovládať.
To je asi NAT v Linuxe.
Poznámka: ak niekto chce vysvetlenie, rád ponúknem konzultačné hodiny, samozrejme za poplatok. Mám právo ponúknuť alebo neposkytnúť argumenty za podporované nápady.
Správa od mali »12. novembra 2006 21:26
to je presne to, čo chcete. ak váš forwarder začne vymieňať, potom výkon skutočne pokračoval ****.
máte predstavu, ako ľahko môžete upraviť limit, ak sa skutočne stane problémom?
nemôže? existuje obmedzenie na objem údaje (MB)?! ak existuje, musí existovať iba vo vás. okrem toho chápete, že váš presmerovač podporuje aktívnu časť pripojenia na porte?!
NAT netfilter nie je potrebný nárazník pre nekopíruj údaje. všetko, čo potrebujete, je niekoľko minimálnych informácií na sledovanie spojenia. Hádaj čo? presmerovač musí tiež sledovať pripojenie a na to využíva oveľa viac zdrojov (aj keď si to neuvedomujete).
ty si vrchol. sťažujete sa na réžiu sieťového filtra NAT, ale „odporúčate“ riešenie v užívateľskom priestore?! „zabudli“ ste niekoľko malých detailov:
1) Zdroje spojené s presmerovačom užívateľského priestoru sú veľa nákladnejšie ako tie, ktoré používajú iptables na kontrolu: proces, zásuvky, deskriptory súborov, kopírovacia pamäť atď.
2) netfilter implementuje NAT s nulovým kopírovaním, zatiaľ čo vaše riešenie márne kopíruje údaje dvakrát: jadro skb -> vyrovnávacia pamäť používateľov, vyrovnávacia pamäť používateľov -> jadro skb
3) presmerovač vynúti údaje cez celý zásobník TCP/IP (dvakrát), zatiaľ čo NAT pracuje na najnižšej možnej úrovni a nevykoná celý zásobník ani raz.
4) presmerovač užívateľského priestoru zavádza latentné plánovanie.
Okrem toho implementovaný presmerovač nie je ekvivalentný DNAT, pretože upravuje zdroj paketov (server ich vidí prichádzať od presmerovača, nie od klienta, presmerovanie nie je transparentné). v závislosti od aplikácie to môže spôsobiť veľké problémy (na konkrétnom príklade ssh: práve ste zavraždili autentifikáciu na základe hostiteľa).
Myslím, že nerozumiete tomu, čo sa vlastne deje: netfilter NAT je (oveľa) optimalizovaná verzia vášho presmerovača
problémy so škálovateľnosťou netfilter/conntrack sú dobre známe a môže dôjsť k extrémnemu skenovaniu, pri ktorom by hlúpy presmerovač užívateľského priestoru porazil netfilter nabitý pravidlami. ale zovšeobecnenie na „iptables -t nat = CACA“ je hlúposť, pretože v 99% prípadov je situácia naruby: váš presmerovač potrebuje nielen viac zdrojov na sledovanie spojenia, ale aj v prípade, že sa ho pokúsite zmeniť. na rovnakej úrovni ako netfilter skončíte s oveľa väčšími problémami.
Správa od Nevrax »13. novembra 2006 01:00
mali, som rád za predložené podrobnosti. Takto môžu ostatní zistiť, ako niektoré veci fungujú. Bolo dobré, ak ste robili nejakú dokumentáciu
Škoda, že to nemá nič spoločné s tým, čo tam hovorím. Zdravým rozumom bolo prečítať si aj predchádzajúce príspevky. Ak ste sa predsa len rozhodli komentovať môj príspevok, prečo ste to neurobili viac _pozornosť_?
Predstavil som _tri_ odpovedí na _tri__ vyhlásení o hriechu. Presmerovač sme nepredložili ako riešenie na nahradenie _all_ NAT, ale ako alternatívu pre _simple_ port forwading!
Ak nepotrebujem transparentné presmerovanie alebo hostiteľskú autentifikáciu alebo iné zázraky, nastal problém? Povedal niekto, že chce škálovateľné riešenie? Pokiaľ ide o toto riešenie, povedal som, že je zložitejšie ako NAT? Buďte prosím opatrnejší!
Hore som predstavil _a_ komplexný systém. Pokiaľ to nebolo jasne pochopené, opakujem, systém _works_ 100% založený na netfilteri. Zadal som aj optimalizácie ako hash, notrack, pps limit atď. Pokiaľ ide o toto riešenie, povedal som niečo o presmerovači? Buďte prosím opatrnejší!
Svetu sa zdá byť rozumné vedieť, že existujú alternatívy. Pomôžte im lepšie pochopiť, čo je ich konečným cieľom, aby si mohli zvoliť správne riešenie.
Prečo im načítate hlavy iptables, keď v skutočnosti chcú hlúpe presmerovanie?
Prečo im nepoviete, že môžu mať veľké problémy s tabuľkou nat, ak nevedia, ako ju korelovať so surovinou, mangrovom alebo filtrom? Myslíte si, že osoba, ktorá požiada o jednoduché presmerovanie, bude vedieť, ako monitorovať svoje protibalenie?
NAT v sieťovom filtri považujem za veľkú stratu času v živote. Mohol som sa dozvedieť niečo viac _užitečnejšie_, keby som bol vedený včas správne.
To je presne to, čo robím. „vysloviť“ názory, pretože Chcem výmenu názorov a nie hádky! Názor stráženého človeka je často oveľa cennejší ako stovky strán v učebnici.
Vážim si toho, kto má dobrú vôľu povedať, aký má názor na danú tému, nech už je akýkoľvek. To neznamená, že to musí urobiť ... aby mi dal argumenty.