Например, тем, что wpad-запрос может вырваться за пределы сети.
Если комп находится в домене city.example.office, то wpad будет последовательно искать:
wpad.city.example.office.
wpad.example.office.
wpad.office.
wpad.
И на одном из этапов можно подсунуть свой pac-файл, и направить трафик туда, куда надо.
Это, походу, не у них, это архитектурно так. У меня та же засада. Как решить — пока не придумал.
Ну, т.е. теоретически да, поменять заголовки там, все такое. Как это реализовать на постфиксе?
Когда — точно не вспомню, больше года уже.
В службе поддержки отказались предоставлять какую-либо информацию. Я пытался донести мысль о том, что этот ящик практически не используется для отправки писем, что на него регистрация аккаунтов всяких завязана, что меня подломить не могли — иначе аккаунты уже поуводили бы. В поддержке требовали либо телефон для привязки, либо указать, когда я последний раз логинился туда. А логинился я более трех месяцев как, не помнил точно. Единственное, что я мог указать — некоторые письма во входящих и исходящих, которые я точно помнил (даты, темы, адресатов, содержание).
Этого оказалось недостаточно. К тому моменту я просто устал бороться, и бросил свои попытки.
На тот момент я пользовался почтовыми сервисами mail.ru, gmail, outlook.com, yahoo.com. Такого рода сложности возникали только с mail.ru, с разными аккаунтами. После того, как один из аккаунтов был заблокирован второй раз, я и ушел.
Ушел по той же причине. Ящик заблокировали за, якобы, рассылку спама. Пример разосланного спама предоставить отказались, как и сообщить, когда это происходило.
Восстановить доступ к ящику без телефона тоже не дали.
У меня теперь психологическая непереносимость вашего почтового сервиса из-за всего, что вы там развели. Пользоваться Gmail — одно удовольствие.
Насколько я помню, раньше по правилам некоторых зон, com.ua в частности, в whois должна быть указана достоверная информация, и без Protection Privacy. В том случае, если домен зарегистрирован на себя, а не на регистратора. У меня, во всяком случае, именно так, и в whois указаны достоверные данные изначально. Даже и не знал, что их скрыть можно.
Как-то пользовался подобной услугой в Батуми.
Так там велики отпираются и запираются ключом. RFID-чип вмонтирован в брелок ключа. Алгоритм примерно такой:
1. Подходишь к станции выдачи подносишь карточку (proxymity).
2. Одна из ячеек с ключами разблокируется, и начинает моргать красным.
3. Берешь ключ, смотришь на номер на брелоке, и идешь отпираешь этот вел.
4. Катаешься. Ключ в кармане.
5. Когда хочешь сдать вел, ставишь его в стойло и запираешь на ключ.
6. Подходишь к станции выдачи, подносишь карточку, свободная ячейка для ключей загорается зеленым.
7. Вставляешь в ячейку ключ.
8. Все, прокат окончен.
У меня бывало — отваливались, если машина с 1С стартовала на ином железе. В виртуальной среде есть хосты с разным железом. Когда лицензии генерились — машина работала на одном железе, потом смигрировала на другое — эта ситуация отрабатывает нормально. А вот если после этого стартанет на новом — слетят.
Т.е. если, например, виртуальную среду проапгрейдить — система при старте увидит новые процессора, и лицензии сломаются.
Доходило до смешного — подключенный образ виртуального диска ломал лицензию. Появился новый /dev/sdX — все.
Может сейчас все и поменялось. Описанное выше было с год назад примерно.
Вот Вы мне сейчас на больной мозоль наступили.
PostgreSQL версия от 1С имеет в зависимостях библиотеку libicu, причем у этой библиотеки версия в названии прописана — libicu46. А в репозитории 14.04 — libicu52. Все, неудовлетворенная зависимость. Но при этом сама библиотека libicu лежит внутри deb-пакета, распространяемого 1С.
Это все решается, конечно, либо пересборкой пакета с удалением зависимости, либо dummy-пакетом libicu46, возможно еще как-то. Но если бы этот модифицированный PostgreSQL распространялся в виде snap-пакета — такой проблемы не было бы.
Второе. :)
Стараюсь решать задачи имеющимися средствами.
У меня на одной машине поднято два инстанса OpenVPN — второй специально под микротики. Работает — и ладно. Проблем с ним меньше, чем с UDP'шным. На последнем, правда, подключений на порядок больше.
В моей практике был только один случай, когда OpenVPN UDP был принципиально, качественно лучше, чем TCP — когда в нем голос бегал при задержках около 200 мс. На задержках до 50 мс. голос и в TCP бегает нормально.
Окно Овертона в действии.
Главное — плавно двигать идею:
Немыслимо -> Радикально -> Приемлемо -> Разумно -> Стандартно -> Норма.
Все чаще встречаются одобрительные комментарии по поводу цензуры. Я бы общий настрой оценил где-то между Радикально и Приемлемо.
Не смог пройти мимо, и не поделиться прямо противоположным опытом.
У меня сейчас в эксплуатации 40+ микротиков, все на OpenVPN'е. Большинство — старые 750-е. Соединение держат неделями — пока канал не упадет. Скорости, правда, небольшие — где 4 Мбит, где 10 — это промышленные площадки, им больше не нужно.
UDP нет, LZO нет — все так, но у UDP соединений есть свои неприятные тонкости.
Из особенностей — при использовании OpenVPN в режиме топологии net30 (не знаю, как на счет subnet — не пробовал) гейтвей не пингуется, и микротик «опускает» эти маршруты. Решается пушем маршрутов с указанием ip сервера в качестве гейтвея.
Если комп находится в домене city.example.office, то wpad будет последовательно искать:
wpad.city.example.office.
wpad.example.office.
wpad.office.
wpad.
И на одном из этапов можно подсунуть свой pac-файл, и направить трафик туда, куда надо.
Согласен целиком и полностью.
А вообще спасибо за камент, ты натолкнул меня на мысль, куда копать.
Ну, т.е. теоретически да, поменять заголовки там, все такое. Как это реализовать на постфиксе?
В службе поддержки отказались предоставлять какую-либо информацию. Я пытался донести мысль о том, что этот ящик практически не используется для отправки писем, что на него регистрация аккаунтов всяких завязана, что меня подломить не могли — иначе аккаунты уже поуводили бы. В поддержке требовали либо телефон для привязки, либо указать, когда я последний раз логинился туда. А логинился я более трех месяцев как, не помнил точно. Единственное, что я мог указать — некоторые письма во входящих и исходящих, которые я точно помнил (даты, темы, адресатов, содержание).
Этого оказалось недостаточно. К тому моменту я просто устал бороться, и бросил свои попытки.
На тот момент я пользовался почтовыми сервисами mail.ru, gmail, outlook.com, yahoo.com. Такого рода сложности возникали только с mail.ru, с разными аккаунтами. После того, как один из аккаунтов был заблокирован второй раз, я и ушел.
Ушел по той же причине. Ящик заблокировали за, якобы, рассылку спама. Пример разосланного спама предоставить отказались, как и сообщить, когда это происходило.
Восстановить доступ к ящику без телефона тоже не дали.
Так там велики отпираются и запираются ключом. RFID-чип вмонтирован в брелок ключа. Алгоритм примерно такой:
1. Подходишь к станции выдачи подносишь карточку (proxymity).
2. Одна из ячеек с ключами разблокируется, и начинает моргать красным.
3. Берешь ключ, смотришь на номер на брелоке, и идешь отпираешь этот вел.
4. Катаешься. Ключ в кармане.
5. Когда хочешь сдать вел, ставишь его в стойло и запираешь на ключ.
6. Подходишь к станции выдачи, подносишь карточку, свободная ячейка для ключей загорается зеленым.
7. Вставляешь в ячейку ключ.
8. Все, прокат окончен.
Т.е. если, например, виртуальную среду проапгрейдить — система при старте увидит новые процессора, и лицензии сломаются.
Доходило до смешного — подключенный образ виртуального диска ломал лицензию. Появился новый /dev/sdX — все.
Может сейчас все и поменялось. Описанное выше было с год назад примерно.
PostgreSQL версия от 1С имеет в зависимостях библиотеку libicu, причем у этой библиотеки версия в названии прописана — libicu46. А в репозитории 14.04 — libicu52. Все, неудовлетворенная зависимость. Но при этом сама библиотека libicu лежит внутри deb-пакета, распространяемого 1С.
Это все решается, конечно, либо пересборкой пакета с удалением зависимости, либо dummy-пакетом libicu46, возможно еще как-то. Но если бы этот модифицированный PostgreSQL распространялся в виде snap-пакета — такой проблемы не было бы.
Стараюсь решать задачи имеющимися средствами.
У меня на одной машине поднято два инстанса OpenVPN — второй специально под микротики. Работает — и ладно. Проблем с ним меньше, чем с UDP'шным. На последнем, правда, подключений на порядок больше.
В моей практике был только один случай, когда OpenVPN UDP был принципиально, качественно лучше, чем TCP — когда в нем голос бегал при задержках около 200 мс. На задержках до 50 мс. голос и в TCP бегает нормально.
Главное — плавно двигать идею:
Немыслимо -> Радикально -> Приемлемо -> Разумно -> Стандартно -> Норма.
Все чаще встречаются одобрительные комментарии по поводу цензуры. Я бы общий настрой оценил где-то между Радикально и Приемлемо.
У меня сейчас в эксплуатации 40+ микротиков, все на OpenVPN'е. Большинство — старые 750-е. Соединение держат неделями — пока канал не упадет. Скорости, правда, небольшие — где 4 Мбит, где 10 — это промышленные площадки, им больше не нужно.
UDP нет, LZO нет — все так, но у UDP соединений есть свои неприятные тонкости.
Из особенностей — при использовании OpenVPN в режиме топологии net30 (не знаю, как на счет subnet — не пробовал) гейтвей не пингуется, и микротик «опускает» эти маршруты. Решается пушем маршрутов с указанием ip сервера в качестве гейтвея.