Удаленный удаленный временный файл appPools папка
Существуют также панели инструментов страницы состояния с открытым исходным кодом как http://www.stashboard.org/, который можно использовать.
Я перезапустил сервер, и похоже, что он воссоздал папки. Святая мать, зачем Microsoft помещать такие важные файлы в папку с именем temp. Ошибка пользователя тоже, я должен был быть более осторожным и исследовать это!
(Сначала я написал, что это маршрутизируемая сеть, а не мостовая. Теперь я вижу, что она использует LXC, поэтому я точно не знаю. Но если PREROUTING уже работает, я очень надеюсь, что я написанное ниже, будет работать)
Вы используете цепочку PREROUTING, эта цепочка изменяет только маршрутизируемые пакеты (которые собираются быть), то есть пакеты, приходящие откуда-то еще. Пакеты, сгенерированные на Хосте , не маршрутизируются (они просто хорошо ... выводятся, как это может делать любой хост), поэтому эта цепочка никогда не получает пакеты curl. curl просто пытался подключиться к хосту как обычно. Есть другая цепочка для перехвата локально сгенерированных пакетов: OUTPUT.
Итак, вы также дублируете правила DNAT в цепочку OUTPUT (-t nat) с некоторыми изменениями: OUTPUT не требует входного интерфейса. Замените -i eth0 на -o lo! -s 127.0.0.0/8 или просто -d 66.66.66.66 или что-то еще, но вам нужно какое-то ограничение, иначе любой веб-запрос куда угодно будет идти к клиенту . Первый пример не зависит от IP-адресов Хоста , второй - короче, как вам нравится. Это не опечатка, если вы подключаетесь к 66.66.66.66 от самого себя, это локальный пакет, поэтому он проходит через интерфейс lo . Но тогда, поскольку адреса назначения, подобные 127.0.0.1, не могут быть перенаправлены ( curl http://127.0.0.1/ будет тайм-аут вместо сообщения о невозможности подключения), 127.0.0.0/8 помещается как исключение.
И все. Все остальное, как обычно, берет на себя conntrack. Вам следует удалить 2 правила MASQUERADE для конкретных портов. Oни'
Я согласен с MichelZ, что вам следует восстанавливать данные из резервной копии, однако это при условии, что вы сделали какие-либо резервные копии вручную, прежде чем настраивать что-либо в IIS. Я бы делал резервную копию сервера на системном уровне с помощью какого-нибудь программного обеспечения для резервного копирования; очевидно, что вы можете выбрать здесь десятки отличных поставщиков. Я бы также делал резервные копии IIS вручную перед серьезными изменениями. IIS будет создавать резервные копии самостоятельно, но приятно иметь возможность вернуться именно туда, куда вы хотите. Для этого откройте командную строку от имени администратора и перейдите в папку C: \ Windows \ System32 \ inetsrv
. Отсюда используйте команду appcmd, например: C: \ Windows \ System32 \ inetsrv \ appcmd добавить резервную копию «My Backup Name» (где My Backup Name - это имя, которое вы даете своей резервной копии)
Обычно я предпочитаю называть свои резервные копии чем-нибудь значимым на случай, если мне придется вернуться и восстановить. Что-то вроде «Конфигурация предварительной аутентификации ASP на сайте X» Таким образом, я знаю, что именно здесь я внес большие изменения в ASP на конкретном сайте на случай, если мне нужно будет вернуться к нему, прежде чем я внесу эти изменения.
Временные файлы конфигурации в этой папке создаются в целях безопасности (изоляции) процессом WAS. Для каждого отдельного пула приложений существует отдельный файл конфигурации. Подробности описаны здесь:
https://msdn.microsoft.com/en-us/library/dd163536.aspx
Кажется, что перезапуска пула приложений или IIS недостаточно для запуска процесса WAS для восстановления файлы. Только перезапуск сервера запускает процесс регенерации файлов.
Хотя я не пробовал, мне кажется, что перезапуска службы WAS также должно быть достаточно для запуска регенерации файлов, как это было бы касание / изменение файла applicationHost.config.