major12

2 BARVIT Ви принципово ігноруєте мої рекомендації?

Ще раз запитаю ipfw nat show config ipfw nat show

Дуже подібно що таки LibAlias. nat 1: icmp=14, udp=26044, tcp=14320, sctp=0, pptp=0, proto=0, frag_id=715 frag_ptr=0 / tot=41093 Навіть циферки майже ті самі - 40к-45к сесій і починаються проблеми. Тільки у мене frag_id завжди нулі. Спробуйте те що я радив. Ну і можливо mbuf clusters покрутіть, бо краще коли total < max.

Додайте deny_in бо воно дійсно мастхев. І другий крок - не використовувати same_ports + патчик, про який я говорив на 3-й сторінці цієї теми.

2 BARVIT Напишіть "для протоколу" вивід команди ipfw nat show config і чи ставили ви патчик про який я писав?

2 FTTH_VN Розкажіть нам краще, чим вам так pf nat сподобався, що ви увірували.Буде користь хоч якась. Ну і всякі пруфлінки/презентації/обгрунтування можна і зразу в пості писати, а не чекати поки хто спитає Фряха десята - я у неї теж вірю. Але юзати буду з 10.1. А nightfly з 10.2. Тому що на поля з граблями, першими потрібно пускати теоретиків і піонерів

І про "сєтєвую срань". Фрясі має бути байдуже що там у вас літає по мережі. Має оброблятись скількись там kpps або Mpps в залежності від проца. Ато вчора броадкасти це срань, сьогодні торрент трафік, а завтра мабуть скайп будете пробувати "розумними світчами" - ібо багато udp пакетиків пересилає сволоч.

Ліричний відступ. Нат буває ipfw nat і pf nat. pf nat до останнього часу ніхто не юзав, бо від однопоточний (читай неюзабельний) на системах нижче фрі 10. Більшість користуються ipfw nat і нетреба їм ваших авантюр з переходом на нову і можливо сиру систему. Всі чекають хоча б версії 10.1 Забудьте ваші пункти 4 і 5. Ніхто тут собі не ворог щоб ставити глючні мережевки.

Гляньте через pmcstat на чому проц загружений. https://wiki.freebsd.org/PmcTools/CallchainCaptureAndAnalysis Далі якщо проблема в LibAlias - то рішення вже є. Якщо ні то можна дивитись далі. Або якщо впевнені що проблема в ipfw nat, то додайте опцію log ipfw nat 1 config ip <айпішка> log <решта опцій> і спостерігайте по ipfw nat show

нісагласєн - більша таблиця / повільніший пошук по хешах. Дешевше чистити рєзче. Точно точно. Більша хеш таблиця == швидший пошук, за рахунок меншої кількості елементів в 1 слоті. По таблиці пошук не йде. Там 1 раз виконується функція яка визначає номер слоту (фактично індекс у масиві). А далі звертання до М[0] чи до M[100500] відбувається за той самий час. В маленькій таблиці в 1 слот попаде 10 елементів і треба буде ще пошукати в списку з 10 елементів. В великій таблиці в 1 слот попаде 1-2 елементи. Якщо 1 елемент, то берем його зразу. Якщо 2 - то або вгадали або перескакуємо на наступний елемент списку і берем його. Ефективно ! Платимо оперативкою, купуємо швидкодію.

по логіці мало би давити pps pps не задавиш. Прийшло 100к пакетів і піти має 100к. І так наприклад кожну 1 секунду. От коли не вистачить проца - тоді ппс і просяде. А от оперативки такий тюнінг розміру табличок, в 10 раз більше зжере на те як-би й натякав. Старий я вже, не встигаю тайпати

Тоді вже краще глянути на /* Parameters used for cleanup of expired links */ /* NOTE: ALIAS_CLEANUP_INTERVAL_SECS must be less then LINK_TABLE_OUT_SIZE */ #define ALIAS_CLEANUP_INTERVAL_SECS 64 #define ALIAS_CLEANUP_MAX_SPOKES (LINK_TABLE_OUT_SIZE/5) А таймаути tcp/udp я би не чіпав. Хоча той же лінукс розділяє UDP на UNREPLIED і ESTABLISHED що ніби трохи правильніше. При нормальному розподілі воно ітак витягне 160М сесій, навіщо чистити.

Кількість слотів в LibAlias тюнінгується правкою /usr/src/sys/netinet/libalias/alias_local.h У мене #define LINK_TABLE_OUT_SIZE 40009 #define LINK_TABLE_IN_SIZE 40009 Ну і звичайно перекомпіляція ядра.

Вибачте, але це брєд

Певне пост погано прочитали. При поганій хеш функції і "поганих" вхідних значеннях, хеш таблиця вироджується в простий список. А пошук по ньому сильно неефективний. При нормальному ж розподілі, сесії будуть розділятись рівномірно по таблиці і халепа наступить при 40к елементів * 4к слотів у таблиці (дефолт) = при 160 М сесій на одну айпішку (інстанс нату).

Ага пошук у списочку в 45к елементів при 20-30 kpps грузить 1 ядро на 100%. Далі стає сумно. За що я платив гроші інтелу !

Загалом по опціях kernel NAT log - помагає при дебагу, дає статистику deny_in - мастхев unreg_only - іноді потрібне не використовувати same_ports і не використовувати global - бо буде шукати по всіх нат інстансах, а у мене їх наприклад 200+

Добра людина з яндексу пофіксила http://www.freebsd.org/cgi/query-pr.cgi?pr=189655

І у мене таке було Загалом це некоректна робота LibAlias + якийсь потужний юзер торренту або вірус. Я навіть невеликий пост про це написав, але ненашою мовою - major12.net До фрібсд-шної баги вже патч є. Отже позбільшувати хеш-таблички ну і 10к сесій на айпішку тяне без проблем.

Не спрацює ! Браузер не прийме ніяких даних через невалідний сертифікат. Як зараз розшифровується HTTPS для наприклад фаєрфокса рівень 1 - локальна машина Програма-антивірус, типу касперського дописує свій сертифікат в довірені кореневі сертифікати вндовс, Коли браузер звертається до google.com, програма на льоту формує сертифікат для google.com і підписує його своїм довіреним сертифікатом. Відповідно антивірус може розшифрувати запит, далі з'єднатись з справжнім гуглом і передати дані знову користувачу, причому дані можуть бути перевірені на віруси чи навіть змінені. Дистанційно (коли немає контролю над машиною) - не працює рівень 2 - підприємство Тут всі віндовс машини входять в домен. І сертифікат інсталюється через політики на всі комп'ютери. Далі див рівень 1. Дистанційно (коли немає контролю над доменом) - не працює рівень 3 - держава Наприклад Китай може надавити (і так і робить) на центр сертифікації і отримати можливість генерувати сертифікати для будь-якого сайту в світі. Wiki: GFW can use a root certificate from CNNIC, which is found in most operating systems and browsers, to make a MITM attack Дистанційно - працює. Перехоплюється трафік всього населення. Але є одне але Хром для google.com робить додаткову перевірку і унеможливлює цю атаку. https://www.imperialviolet.org/2011/05/04/pinning.html Starting with Chrome 13, we'll have HTTPS pins for most Google properties. This means that certificate chains for, say, https://www.google.com, must include a whitelisted public key. It's a fatal error otherwise. The whitelisted public keys for Google currently include Verisign, Google Internet Authority, Equifax and GeoTrust. Отже якщо мова йде про хром і сайти гугла - там нічого не ламається навіть на рівні держави (крім США мабуть). Підсумок для ТС: Якщо у вас не контрольований гуртожиток чи підприємство, а звичайні абоненти, тоді щоб поламати HTTPS і показати сторінку-заглушку вам потрібно мати кума-брата-свата в уряді Китаю (для звичайних браузерів) чи спецслужбах США (для хрому і доменів google).

Щойно замітив що у ТС немає оновлення сорсів - тоді немає змісту ні в build world ні в перекомпіляції штатного ядра (того що GENERIC)

Варто почистити результати старого білда rm -rf /usr/obj

Офтопік: добрішим треба бути! Ато з'являються потім теми типу "Отношение форумчан к форумчанам" http://local.com.ua/forum/topic/55486-%D0%BE%D1%82%D0%BD%D0%BE%D1%88%D0%B5%D0%BD%D0%B8%D0%B5-%D1%84%D0%BE%D1%80%D1%83%D0%BC%D1%87%D0%B0%D0%BD-%D0%BA-%D1%84%D0%BE%D1%80%D1%83%D0%BC%D1%87%D0%B0%D0%BD%D0%B0%D0%BC/

В найпростішому випадку, якщо Unit тільки один і перевіряти name="bill_identifier" непотрібно, то щось таке $attr = $xml->Transfer->Data->Unit->attributes(); $id = $attr['value'];

Топікстартер мабуть шукає щось типу цього //Sample XML //<message type="dr"> //<adn>123</adn> //<msisdn>9820202020</msisdn> //<tid>1234567890</tid>] //<ccode>123SMSPULL2000</ccode> //<status>1</status> //<tdate>2012-02-21 12:31:20</tdate> //</message> $body = file_get_contents('php://input'); $xml = simplexml_load_string($body); //CP shortcode $adn = $xml->adn; //Handset number $msisdn = $xml->msisdn; //Transaction Id $tid = $xml->tid; //Charging code $ccode = $xml->ccode; //DR status $status = $xml->status; //Transaction date $tdate = $xml->tdate; вкрадено звідси http://blog.djakapm.com/2012/07/13/how-read-xml-from-post-request-with-php/