Конфигурирајте ssh - Форум Linux - linux360
со отворен извор и отворени умови
конфигурирај ssh
Порака од коломбо »08 ноември 2006 година 09:25 часот
Порака од csdexter »08 ноември 2006 година 09:51
/ sbin/iptables -t nat -ПРЕДУПРЕДУВАЕ -s $ ip_permise -d $ ip_extern_router -m tcp -p tcp --dport $ port_external -j DNAT - до дестинацијата $ ip_server_intern: 22
И тоа е кажано 1000 пати
Порака од коломбо »08 ноември 2006 10:58
Порака од csdexter »08 ноември 2006 година 12:06
Синус амициција, витамин есе нулам.
Порака од Невракс »10 ноември 2006 02:31
iptables -t nat = CACA
Престанете да користите NAT во Linux. дека не е добро. Не сакам. и не е потребно тука да се чува теоријата за заштитени идови. Ако ми верувате, тоа е во ред, ако не. повторно добро
За акција едноставно како глупаво пренасочување на порти, препорачувам едноставна програма што слуша на одредена IP, на одредена порта и испраќа сообраќај до одредена IP до одредена порта.
ПС: Каде се старите добри времиња кога луѓето не се исмеваа на овој начин на ресурси. висина DNAT за едноставна порта.
Порака од csdexter »10 ноември 2006 година 10:39 часот
Не \ s \ h \ i \ t?! Ајде, тоа беше одлично, особено оправдувањето
Синус амициција, витамин есе нулам.
Порака од бсабин »10 ноември 2006 година 18:21 часот
Порака од грев »11 ноември 2006 година 17:28
Порака од тигар_око »11 ноември 2006 година 19:52 часот
Порака од Невракс »11 ноември 2006 година 22:44
грев, да разберам дека сè што пишувам на овој форум се абери?
ако има нешто поврзано со оваа нишка, ве молам кажете ми што не е во ред.
Порака од грев »12 ноември 2006 14:52
врската за следење на врската троши помалку од 300 бајти меморија. вашето решение со пренасочувач троши тz пати повеќе меморија.
како дојдовте до заклучок дека правењето НАТ на Linux е лошо? исто така, ако не ви пречи, кажете ни каква теорија за заштитен ид знаете ?
Порака од Невракс »12 ноември 2006 година 17:30 часот
Предлагам да започнеме со смирување
Не сакам да предизвикам бесконечна полемика на оваа тема, затоа, ќе се обидам да бидам што пократок.
Погрешно. Вашиот аргумент е детски и неоснован затоа што веројатно не знаете детали за тоа што навистина се случува. Зошто зборувате само за меморијата потрошена од врската? Зошто не зборувате за други вклучени ресурси за да ја имате таа врска? Зошто не кажете какви се претставите меѓу двете решенија? Зошто не објасните кои се ризиците?
Табела nat треба следење за врски. Ова следење се базира на хаш што зафаќа меморија што не може да се замени. Дали имате идеја колку лесно можете да ја достигнете максималната граница на овој хаш? Претпоставувам дека знаете што е следно!
а пренасочувач повторно го користи истиот тампон што го ослободува кога врската е прекината. Сега веројатно ќе разберете подобро зошто не можете да имате 10 MB трансфер под NAT со iptables. Исто така, има смисла да се дискутира за времето на одговор и потрошените ресурси во голем број по пакет/секунда.?
Дојдов до овој заклучок по долгогодишна работа, студии и пракса. Развивме многу сложени решенија засновани на NAT во Linux. Кога велам комплекс, мислам на огромни низи со илјадници правила што се користат за да се генерираат неколку илјади други правила за iptables. Во моментов овој систем може да управува со едноставни правила како SNAT/DNAT, како и NAT за десетици услуги како pptp, gre, ftp, irc итн.
За ваков систем да работи правилно, ви требаат оптимизации како што се хаширање, нотрак, ограничување на ппс, итн. Ако ја земеме предвид потребата да се групираат правилата за различни критериуми, очигледно, комплексноста на администрацијата на системот ќе се зголеми.
Развојот и оптимизацијата на решението беше направено со текот на времето, секогаш известувајќи ми за тоа како е развиен проектот iptables на www.netfilter.org .
После сите овие години, мислам дека имам доволно аргументи за да го поддржам следново:
НЕ користете iptables -t nat во Linux. Сурови, мангрови или филтер маси може да се користат без проблеми.
iptables -t nat не вреди да се користат дури и за едноставни правила како SNAT на IP или „пренасочување“ на портот. Ако сакате да останете со мртвите во куќата. тоа е тоа.
Логично е да сфатиме дека на оваа форума нема место на ваква тема. Наместо тоа, можам да ви дадам неколку идеи.
„Дефиницијата“ за заштитен allид, како што гледам, ќе биде следнава: Заштитен allид е комплексен систем на управување со апстрактни ресурси со цел да биде предмет на правила со добро дефинирана крајна цел.
Општо, постои голема конфузија помеѓу заштитен ид и iptables, а NAT е само _ мал _ дел од она што всушност значи заштитен allид. За возврат, NAT е од неколку видови. Во зависност од крајната цел, мора да се избере точниот тип на NAT.
Друг многу важен аспект во заштитен allид се нападите од типот DoS, каде што (и тоа го повредува моето срце) NAT во Linux може да предизвика огромни проблеми. Користете NAT само ако сте добри во тоа што го правите и знаете како да го контролирате.
Тоа е за NAT во Linux.
Забелешка: ако некој сака појаснувања, со задоволство можам да понудам часови за консултации, очигледно за одреден надомест. Мое право е да понудам или да не давам аргументи за идеите што ги поддржувам.
Порака од мали »12 ноември 2006 година 21:26
тоа е токму она што го сакате. ако вашиот шпедитер започне размена, тогаш перформансите навистина продолжија ****.
имате идеја колку лесно можете да ја прилагодите границата ако тоа навистина стане проблем?
не може постои ограничување на волумен податоци (MB)?! ако постои, мора да постои само во вас. покрај тоа, да разбереме дека вашиот пренасочувач поддржува активно парче врска на приклучокот?!
нет-филтер НАТ не е потребен тампон за не копирај податоци потребна е само неколку минимални информации за следење на врската. погоди што? пренасочувачот исто така мора да ја следи врската и за ова користи многу повеќе ресурси (дури и ако не го сфаќате тоа).
ти си врвот. дали се жалите на горниот дел од мрежниот филтер NAT, но дали „препорачувате“ решение за кориснички простор? „заборавивте“ неколку мали детали:
1) Ресурсите поврзани со пренасочување на корисничкиот простор се многу поскапи од оние што ги користат iptables за влез: процес, приклучоци, опишувачи на датотеки, тампон за копирање итн.
2) netfilter спроведува NAT со нулта копија, додека вашето решение залудно ги копира податоците 2 пати: кернел skb -> тампон кориснички простор, тампон кориснички простор -> кернел skb
3) пренасочувачот ги присилува податоците низ целиот TCP/IP оџак (2 пати) додека NAT работи на најниско можно ниво и не вежба целосен стек дури еднаш.
4) пренасочувачот на корисничкиот простор воведува латентен распоред.
како додаток, пренасочувачот спроведен како што предлагате не е еквивалентен на DNAT бидејќи го модифицира изворот на пакетите (серверот ги гледа како доаѓаат од пренасочувачот не од клиентот, пренасочувањето не е транспарентно). во зависност од апликацијата, ова може да предизвика големи проблеми (на конкретниот пример ssh: вие само убивте автентикација заснована врз домаќин).
Мислам дека не разбирате што всушност се случува: netfilter NAT е (многу) оптимизирана верзија на вашиот редиректор
проблемите со приспособливост на нет-филтер/контракта се добро познати и може да има екстремно скенирање во кое нем пренасочувач на корисничкиот простор би победил нет-филтер исполнет со правила. но генерализирање на „iptables -t nat = CACA“ е идиотизам затоа што во 99% од случаите ситуацијата е наопаку: не само што на вашиот пренасочувач му требаат многу повеќе ресурси за да ја следите врската, но ако се обидете да ја разместите на исто ниво со нетфилтер, ќе завршите со многу поголеми проблеми.
Порака од Невракс »13 ноември 2006 година 01:00 часот
мали, мило ми е за презентираните детали. На овој начин другите можат да откријат како функционираат некои работи. Добро беше ако направите некоја документација
Штета што нема никаква врска со она што го зборувам таму. Беше здрав разум да се прочитаат и претходните објави. Ако сепак решивте да го коментирате мојот пост, зошто не го сторивте тоа повеќе _ внимание_?
Јас презентирав _ три_ одговори на _ три_ изјави за грев. Ние не го претставивме пренасочувачот како решение за замена на _ сите_НАТ, туку како алтернатива на простиот превоз на _едноставната_порта!
Ако не ми треба транспарентно пренасочување или автентикација заснована врз домаќин или какво било друго чудо, има проблем? Дали некој рече дека сакаат скалабилно решение? Во врска со ова решение, дали реков дека е покомплексно од НАТ? Бидете повнимателни, ве молам!
Погоре презентирав _ и_ комплексен систем. Ако не беше јасно разбрано, повторувам, системот _ работи_ 100% базиран на нет-филтер. Исто така, наведов оптимизации како што се хаширање, нотрак, ограничување на ппс, итн. Во врска со ова решение, кажав ли нешто за пренасочување? Бидете повнимателни, ве молам!
Се чини дека здравиот разум е светот да знае дека постојат алтернативи. Помогнете им подобро да разберат која е нивната крајна цел за да можат да го изберат вистинското решение.
Зошто им ги товарите главите со iptables, а всушност тие сакаат глупаво пренасочување?
Зошто не им кажете дека можат да имаат големи проблеми со табелата nat, ако не знаат како да ја поврзат со сурова, мангрова или филтер? Дали мислите дека лицето кое бара едноставно пренасочување, исто така, ќе знае како да го следи неговиот контра напад?
Сметам дека NAT во нет-филтерот е големо губење време во мојот живот. Можев да научам нешто покорисно, ако навремено се водев правилно.
Јас токму тоа го правам. „државни“ мислења затоа што Сакам размена на мислења, а не расправија! Честопати мислењето на чуван човек е многу повредно од стотици страници во учебник.
Го ценам оној што има добра волја да каже какво мислење има за некоја тема, каква и да е таа. Тоа не значи дека тој мора да го стори тоа ... за да ми даде аргументи.