Налаштування ssh - Форум Linux - 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 призначення $ ip_server_intern: 22
І це було сказано 1000 разів
Повідомлення від Коломбо »08 листопада 2006 10:58
Повідомлення від csdexter »08 листопада 2006 12:06
Sine amicitia, vitam esse nullam.
Повідомлення від Невракс »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.
Повідомлення від бсабін »10 листопада 2006 18:21
Повідомлення від гріх »11 листопада 2006 17:28
Повідомлення від тигрові_очі »11 листопада 2006 19:52
Повідомлення від Невракс »11 листопада 2006 22:44
гріх, зрозуміти, що все, що я пишу на цьому форумі, є відхиленнями?
якщо щось пов’язане з цією темою, скажіть, будь ласка, що не в порядку.
Повідомлення від гріх »12 листопада 2006 14:52
з'єднання для відстеження з'єднання споживає менше 300 байт пам'яті. ваше рішення з редиректором споживає в десятки разів більше пам'яті.
як ви дійшли висновку, що робити NAT на linux - це погано? також, якщо ви не проти, розкажіть нам, яку теорію брандмауера ви знаєте ?
Повідомлення від Невракс »12 листопада 2006 р. 17:30
Я пропоную розпочати із заспокоєння
Я не хочу викликати нескінченні суперечки на цю тему, тому намагатимусь бути якомога коротшим.
Невірно. Ваш аргумент є дитячим та необґрунтованим, тому що ви, мабуть, не знаєте подробиць того, що насправді відбувається. Чому ви просто говорите про пам'ять, споживану з'єднанням? Чому б вам не розповісти про інші ресурси, що беруть участь у такому зв’язку? Чому б вам не сказати, які вистави між двома рішеннями? Чому б вам не пояснити, які ризики?
Стіл нац потрібне відстеження для з’єднань. Це відстеження базується на хеші, який займає пам'ять, що не міняється. Ти уявляєш, як легко ти можеш досягти максимальної межі цього хешу? Я думаю, ви знаєте, що далі!
a редиректор повторно використовує той самий буфер, який він вивільняє при припиненні з'єднання. Ви, мабуть, тепер краще зрозумієте, чому ви не можете передати 10 Мб під 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 - це лише маленька частина того, що насправді означає брандмауер. У свою чергу, NAT буває декількох типів. Залежно від кінцевої мети, слід вибрати правильний тип NAT.
Ще одним дуже важливим аспектом брандмауера є атаки типу DoS, де (і це болить моє серце) NAT в Linux може спричинити величезні проблеми. Використовуйте NAT, лише якщо ви добре вмієте робити те, що знаєте, і знаєте, як цим керувати.
Це приблизно NAT в Linux.
Примітка: якщо хтось хоче пояснень, я із задоволенням можу запропонувати консультаційні години, очевидно за окрему плату. Моє право пропонувати чи не наводити аргументи за ідеї, які я підтримую.
Повідомлення від малі »12 листопада 2006 21:26
це саме те, що ви хочете. якщо ваш експедитор почне обмін, то продуктивність дійсно продовжилася ****.
Ви уявляєте, як легко ви можете налаштувати ліміт, якщо це справді стає проблемою?
не може? існує обмеження на гучність даних (МБ)?! якщо вона існує, вона повинна існувати лише у вас. на додаток до того, щоб зрозуміти, що ваш редиректор підтримує активний шматок з'єднання на порту?!
NAT netfilter буфер не потрібен для не копіювати даних. все, що йому потрібно, це якась мінімальна інформація для відстеження зв'язку. Вгадай що? редиректор також повинен підключатись, і для цього він використовує набагато більше ресурсів (навіть якщо ви цього не усвідомлюєте).
ти вершина. ти скаржишся на накладні витрати на NAT netfilter, але ти "рекомендуєш" рішення простору користувача?! ви "забули" кілька дрібних деталей:
1) Ресурси, пов'язані з редиректором простору користувача, є багато дорожчі, ніж ті, що використовуються iptables для conntrack: процес, сокети, дескриптори файлів, буфер копіювання тощо.
2) netfilter реалізує NAT з нульовим копіюванням, тоді як ваше рішення марно копіює дані 2 рази: kernel skb -> buffer user space, buffer userspace -> kernel skb
3) редиректор форсує дані через весь стек TCP/IP (2 рази), тоді як NAT працює на найнижчому можливому рівні і не виконує повний стек навіть один раз.
4) редиректор простору користувача вводить приховане планування.
крім того, реалізований, як ви пропонуєте, редиректор, не еквівалентний DNAT, оскільки він змінює джерело пакетів (сервер бачить, що вони надходять з редиректора, а не від клієнта, переадресація не прозора). залежно від програми це може спричинити великі проблеми (на конкретному прикладі ssh: ви щойно вбили аутентифікацію на основі хоста).
Я думаю, ви не розумієте, що насправді відбувається: netfilter NAT - це (набагато) оптимізована версія вашого редиректора
проблеми масштабованості netfilter/conntrack добре відомі, і може бути якесь екстремальне сканування, при якому німий редиректор користувацького простору би переграв упакований правилами netfilter. але узагальнення до "iptables -t nat = CACA" є ідіотизмом, тому що в 99% випадків ситуація перевертається: не тільки вашому редиректору потрібно набагато більше ресурсів для відстеження з'єднання, але якщо ви намагаєтеся масштабувати його на тому ж рівні, що і мережевий фільтр, у вас виникають набагато більші проблеми.
Повідомлення від Невракс »13 листопада 2006 01:00
mali, я радий представленим деталям. Таким чином інші можуть дізнатися, як працюють деякі речі. Добре, якщо ви зробите якусь документацію
Шкода, що це не має нічого спільного з тим, що я там кажу. Був здоровим глуздом прочитати і попередні дописи. Якщо ви все-таки вирішили прокоментувати мій пост, чому ви не зробили цього більше _увага_?
Я представив три відповіді на три заяви про гріх. Ми не представляли редиректор як рішення для заміни _all_ NAT, а як альтернативу для простого порту!
Якщо мені не потрібне прозоре перенаправлення, автентифікація на основі хоста чи будь-які інші дива, чи є проблема? Хтось сказав, що вони хочуть масштабованого рішення? Щодо цього рішення, чи я сказав, що воно є більш складним, ніж NAT? Будьте обережніші, будь ласка!
Вище я представив _і_ складну систему. Якщо це не було чітко зрозуміле, повторюю, система _ працює на 100% на основі netfilter. Я також вказав такі оптимізації, як хешування, notrack, pps limit тощо. Щодо цього рішення, я щось сказав про редиректор? Будьте обережніші, будь ласка!
Здається здоровим глуздом для світу знати, що існують альтернативи. Допоможіть їм краще зрозуміти, якою є їх кінцева мета, щоб вони могли вибрати правильне рішення.
Чому ви навантажуєте їм голови iptables, коли насправді вони хочуть дурне перенаправлення?
Чому б вам не сказати їм, що у мене можуть бути великі проблеми з таблицею nat, якщо я не знаю, як співвіднести її з сировиною, мангровим заростю або фільтром? Чи вважаєте ви, що людина, яка просить просту переадресацію, також буде знати, як контролювати свою контратаку?
Я вважаю NAT у мережевому фільтрі великою втратою часу у своєму житті. Я міг би навчитися чогось більш корисного, якби вчасно керувався правильно.
Це саме те, що я роблю. "виголошувати" думки, тому що Я хочу обміну думками, а не суперечки! Часто думка охоронця набагато цінніша за сотні сторінок підручника.
Я ціную того, хто має добру волю сказати, яку думку він має щодо того чи іншого предмета, яким би він не був. Це не означає, що він повинен це робити ... щоб наводити мені аргументи.