Евгений Воробьев, ну вот, видно, что локальная зона есть, прописана, должна работать. С чего бы тогда BIND-у пересылать куда-то запросы по зоне, в которой он сам - master? Непоняточка.
Для полной ясности уточнение: у этого BIND-а IP-адрес .101.141, да?
Ипатьев, вы чего на Дмитрий накинулись? Он правильно написал, что сумму sizeof() не считает. Как и count(). И дополнительно обмолвился, что у count() плюсом еще и вкусняшка в виде рекурсии (неожиданно, блин, теперь буду знать. И поправочка: sizeof() это просто alias для count(), то есть аргументы и результат - одинаковые). После всего обвиняете человека ну хоть в чём-нибудь, что под руку подвернётся. Некрасиво выглядит.
Вообще-то у bind-а локальные зоны в приоритете, он сначала смотрит что есть у себя, если нет совпадения - запрашивает у forwarders-ов, если они не помогают - тогда идёт разматывать цепочку доменов самостоятельно, начиная с корневого домена. А в приведённом конфиге локальные зоны просто отрезаны, но они есть?
А сюда зачем пришли? Что бы вам посоветовали не делать того, что вы делать опасаетесь? Или надо угадать день, когда спамеры с публичных WEB-страниц загребли в свои спам-базы E-Mail адресов конкретно ваш адрес? Или объяснить вам, что такие подозрительные письма надо сжигать перед прочтением? Или что?
Во-первых вы неправильно работаете с массивом $items. Во-вторых вы неправильно понимаете смысл функции sizeof(). В-третьих вы неправильно считаете сумму значений, точнее вообще не считаете. В-четвёртых вы неправильно поняли смысл работы этого сайта.
70-C9-4E-54-03-2F, а вот еще вариант: адрес 192.168.0.1 точно находится на исследуемом Mikrotik-е? Проверяется в /ip address print, ну или "IP" -> "Addresses" в WinBox.
P.S. Хотя да, сразу видно, 192.168.0.1 - это его. Вон, в PacketSniffer-е tx-нутый пакет пролетел, значит с этого Mikrotik-а был отправлен.
Если я не ошибаюсь, в RDP (без патча библиотеки) одновременно может работать только один пользователь - или локальный, или удалённый. И удалённый не может заглядывать в экран локального и там помогать ему. И кстати, в Windows же есть "Удалённый помощник", но хоть бы раз увидеть как эта функция работает...
galliard, давайте я тоже напишу что-нибудь эдакое... Выбросите вы эти браузеры, используйте curl и wget, в них https_proxy есть!
Ну, чисто что бы поддержать пустой трындёж, уводящий в сторону от сути вопроса, про reverse proxy.
Можно включить логирование вообще во всех правилах Firewall-а, и отслеживать, где этот пакет убивается. Ну или только в запрещающих, потому что если во всех - то будет мноооого логов...
galliard, тогда единственный совет: перестаньте использовать Nginx как forwarding proxy, настраивайте его как reverse proxy, и всё получится. У вас даже всё уже получалось на 80-ом порту, отличие только в номере порта+шифрование, ничего экстраординарного.
galliard, так, вот сейчас будет очень тупой вопрос, но его надо задать: вы в своём уме? Вы настраиваете Nginx как reverse proxy, но используете его как forward proxy, так?
galliard, а вы уверены, что приведённая строка из логов - именно ваша? Потому что CONNECT - это признак использования этого Nginx как forwarding proxy. Должен быть GET или POST, но никак не CONNECT!