Конфигуриране на ssh - Linux Forum - linux360
отворени източници и отворени умове
конфигуриране на ssh
Съобщение от Коломбо »08 ноември 2006 09:25
Съобщение от csdexter »08 ноември 2006 09:51
/ sbin/iptables -t nat -A ПРЕДВАРИТЕЛНО -s $ ip_permise -d $ ip_extern_router -m tcp -p tcp --dport $ port_exterior -j DNAT - to-destination $ ip_server_intern: 22
И е казано 1000 пъти
Съобщение от Коломбо »08 ноември 2006 10:58
Съобщение от csdexter »08 ноември 2006 12:06
Sine amicitia, vitam esse nullam.
Съобщение от Nevrax »10 ноември 2006 02:31
iptables -t nat = CACA
Спрете да използвате NAT в Linux. че не е добре. Не искам. и не е необходимо тук да се поддържа теорията за защитните стени. Ако ми вярвате, това е добре, ако не. пак добре
За действие, просто като глупаво пренасочване на портове, препоръчвам проста програма, която слуша на определен IP, на определен порт и изпраща трафик към определен IP към определен порт.
PS: Къде са добрите стари времена, когато хората не се подиграваха по този начин на ресурси. височина. DNAT за прост portfwd.
Съобщение от csdexter »10 ноември 2006 10:39
Не \ s \ h \ i \ t?! Хайде, това беше страхотно, особено оправданието
Sine amicitia, vitam esse nullam.
Съобщение от bsabin »10 ноември 2006 18:21
Съобщение от грях »11 ноември 2006 г. 17:28
Съобщение от тигър_око »11 ноември 2006 г. 19:52
Съобщение от Nevrax »11 ноември 2006 22:44
грехо, за да разбера, че всичко, което пиша в този форум, са отклонения?
ако има нещо, свързано с тази тема, моля, кажете ми какво не е наред.
Съобщение от грях »12 ноември 2006 г. 14:52
връзка за проследяване на връзка отнема по-малко от 300 байта памет. вашето решение с пренасочване консумира тз пъти повече памет.
как стигна до заключението, че правенето на NAT на linux е нещо лошо? също, ако нямате нищо против, кажете ни каква теория за защитната стена знаете ?
Съобщение от Nevrax »12 ноември 2006 г. 17:30
Предлагам да започнем с успокояване
Не искам да предизвиквам безкрайни спорове по този въпрос, затова ще се опитам да бъда възможно най-кратък.
Неправилно. Аргументът ви е детински и необоснован, защото вероятно не знаете подробности за това какво всъщност се случва. Защо просто говорите за паметта, консумирана от връзка? Защо не говорите за други включени ресурси, за да имате тази връзка? Защо не кажете какви са представленията между двете решения? Защо не обясните какви са рисковете?
Таблица нац се нуждае от проследяване за връзки. Това проследяване се основава на хеш, който заема неразменяема памет. Имате ли представа колко лесно можете да достигнете максималния лимит на този хеш? Предполагам знаете какво следва!
а пренасочване многократно използва същия буфер, който се освобождава, когато връзката е прекратена. Вероятно сега ще разберете по-добре защо не можете да прехвърляте 10 MB под NAT с iptables. Също така има смисъл да се обсъдят времето за реакция и консумираните ресурси в голям брой на пакет/секунда.?
До този извод стигнах след много години работа, следване и практика. Разработихме много сложни решения, базирани на NAT в Linux. Когато казвам сложни, имам предвид огромни масиви с хиляди правила, използвани за генериране на няколко хиляди други iptables правила. В момента тази система може да управлява прости правила като SNAT/DNAT, както и NAT за десетки услуги като pptp, gre, ftp, irc и т.н.
За да работи система като тази правилно, ви трябват оптимизации като хеширане, notrack, pps limit и т.н. Ако вземем предвид необходимостта от групиране на правилата по различни критерии, очевидно сложността на системната администрация ще се увеличи.
Разработването и оптимизирането на решението беше направено с течение на времето, като винаги ми докладваше как е разработен проектът iptables на www.netfilter.org .
След всички тези години мисля, че имам достатъчно аргументи в подкрепа на следното:
НЕ използвайте iptables -t nat в Linux. Сурови, мангрови или филтърни маси могат да се използват без проблеми.
iptables -t nat не си струва да се използва дори за прости правила като SNAT на IP или „пренасочване“ на порт. Ако искате да останете с мъртвите в къщата. това е.
Има смисъл да осъзнаете, че такава тема няма място тук в този форум. Вместо това мога да ви дам някои идеи.
„Дефиницията“ на защитната стена, както виждам, би била следната: Защитната стена е сложна система за управление на абстрактни ресурси, за да се подчинява на правила с точно определена крайна цел.
Като цяло има много объркване между защитните стени и iptables и NAT е само _small_ част от това, което всъщност означава защитна стена. На свой ред NAT е от няколко вида. В зависимост от крайната цел трябва да бъде избран правилният тип NAT.
Друг много важен аспект в защитната стена са атаките тип DoS, при които (и това ме боли сърцето) NAT в Linux може да причини огромни проблеми. Използвайте NAT само ако сте добри в това, което правите и знаете как да го контролирате.
Това е за NAT в Linux.
Забележка: ако някой иска разяснения, мога да предложа консултантски часове с най-голямо удоволствие, очевидно, срещу заплащане. Моето право е да предлагам или да не давам аргументи за идеите, които подкрепям.
Съобщение от Мали »12 ноември 2006 21:26
точно това искате. ако вашият спедитор започне да се разменя, изпълнението наистина продължи ****.
имате представа колко лесно можете да регулирате лимита, ако наистина се превърне в проблем?
не мога? има ограничение за сила на звука данни (MB)?! ако съществува, трябва да съществува само във вас. в допълнение, за да разберете, че вашият редиректор поддържа активна връзка на порта?!
NAT netfilter не е необходим буфер за не копирай данни. всичко, от което се нуждае, е минимална информация за проследяване на връзката. Познай какво? пренасочването също трябва да следва връзката и за това използва много повече ресурси (дори и да не го осъзнавате).
ти си върхът. оплаквате ли се от режийните NAT NATfilter, но "препоръчвате" ли решение за потребителско пространство?! "забравихте" няколко малки подробности:
1) Ресурсите, свързани с редиректор на потребителско пространство, са много по-скъпи от тези, използвани от iptables за conntrack: процес, сокети, дескриптори на файлове, буфер за копиране и т.н.
2) netfilter реализира NAT с нулево копиране, докато вашето решение напразно копира данните два пъти: skb ядро -> потребителско пространство буфер, потребителско пространство буфер -> skb ядро
3) редиректорът форсира данните през целия стек TCP/IP (2 пъти), докато NAT работи на възможно най-ниското ниво и не упражнява пълния стек нито веднъж.
4) редиректор на потребителско пространство въвежда латентно планиране.
в допълнение, пренасочването, внедрено, както вие предлагате, не е еквивалентно на DNAT, тъй като променя източника на пакетите (сървърът ги вижда, че идват от пренасочването, а не от клиента, пренасочването не е прозрачно). в зависимост от приложението това може да доведе до големи проблеми (на конкретния пример ssh: току-що сте убили удостоверяване въз основа на хост).
Мисля, че не разбирате какво всъщност се случва: netfilter NAT е (много) оптимизираната версия на вашия редиректор
проблемите с мащабируемостта на netfilter/conntrack са добре известни и може да има някакво екстремно сканиране, при което тъпият редиректор на потребителско пространство би победил опакован от правила netfilter. но обобщаването на "iptables -t nat = CACA" е идиотизъм, защото в 99% от случаите ситуацията е обърната: не само вашият редиректор се нуждае от много повече ресурси за проследяване на връзка, но ако се опитате да я мащабирате на същото ниво като netfilter в крайна сметка имате много по-големи проблеми.
Съобщение от Nevrax »13 ноември 2006 г. 01:00
mali, радвам се за представените подробности. По този начин другите могат да разберат как работят някои неща. Добре е да сте направили някаква документация
Жалко, че няма нищо общо с това, което казвам там. Беше здрав разум да прочетох и предишните публикации. Ако все пак сте решили да коментирате публикацията ми, защо не сте го направили повече _attention_?
Представих три отговора на три твърдения за грях. Не представихме пренасочването като решение за замяна на _all_ NAT, а като алтернатива за пренасочване на _simple_ порт!
Ако не се нуждая от прозрачно пренасочване или удостоверяване въз основа на хост или някакви други чудеса, има ли проблем? Някой каза ли, че иска мащабируемо решение? По отношение на това решение казах ли, че то е по-сложно от NAT? Бъдете по-внимателни, моля!
По-горе представих _и_ сложна система. Ако не беше ясно разбрано, повтарям, системата _работи_ 100% въз основа на netfilter. Също така посочих оптимизации като хеширане, notrack, pps limit и т.н. По отношение на това решение казах ли нещо за пренасочването? Бъдете по-внимателни, моля!
Изглежда здравият разум за света да знае, че има алтернативи. Помогнете им да разберат по-добре каква е крайната им цел, за да могат да изберат правилното решение.
Защо натоварвате главите им с iptables, всъщност те искат глупаво пренасочване?
Защо не им кажете, че мога да имам големи проблеми с таблицата nat, ако не знам как да я свържа със сурови, мангрови горива или филтри? Мислите ли, че човек, който поиска просто пренасочване, също ще знае как да наблюдава контраатаката си?
Считам NAT в netfilter за голяма загуба на време в живота си. Можех да науча нещо по-полезно_, ако бях ръководен правилно навреме.
Точно това правя. „изговарят“ мнения, защото Искам размяна на мнения, а не спор! Често мнението на охранявания мъж е много по-ценно от стотици страници в учебник.
Оценявам този, който има добра воля да каже какво мнение има по даден предмет, какъвто и да е той. Това не означава, че трябва да го направи ... за да ми дава аргументи.