Евгений Воробьев, ну вот, видно, что локальная зона есть, прописана, должна работать. С чего бы тогда 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!
galliard, действительно, был не прав, чёртов PHP на этот случай не ругается.
Тьфу на него, уйду в монастырь. А какой прокси-то вам нужен, forwarding или reverse?
Для полной ясности уточнение: у этого BIND-а IP-адрес .101.141, да?