Для "сокрытия" инфраструктуры есть такая вещь как reverse proxy. Вообще NAT-PT & NAT в IPv6 не одно и то же. NAT-PT (он же NPt) можно приравнивать к NAT1:1 в v4, а так в IPv6 непонятно зачем, но, можно и отдельные порты на отдельные IP натить. Да без NAT-PT сделать Multi WAN можно, но нужно иметь свою ASN и свою личную подсеть, пиров и ospf шлюз...
В смысле в полном обьеме? ВК вообще вырубили IPv6, еще давным давно, еще до того как его в Украине забанили...
>> но сам факт, что некоторые сайты могут криво работать с ipv6 забавляет :)
Скажем так - чем сайты которые работают по IPv6 могут делать что то криво? Разве что:geoip, rate limiting, brute force protection, ip restrictions. Тоесть все логические взяви с IP, их в системах не так уж и много. А то что не отображась картинки - это уже проблема из ряда DNS который указывает не на тот сервер или мисконфигурации самого веб сервера..., на прямую к IPv6 не имеющего отношения, просто те кто тестил работу сервиса могли банально забыть что у них еще есть IPv6. Видел одного клиента у которого "заводские" настройки DNS у регистратора имели АААА на парковочные IPv6. Их админ не понимая что такое АААА и почему он там - не стал его убирать, а А запись он конечно поправил. Вышла картина: сайт у них работает "для них", потому что у них нет IPv6, но для нас и для всех нормальных поисковых систем их сайт это что? Правильно - просто заглушка. А потом они удивлялись почему их в поисковиках никто найти не может... Ахаха...
По PMTUD - запустите Microsoft Skype for Business или Lync, и поймете :P
Такая же схема с pfsense: 2 HE туннеля, по одному на WAN, с разными HE endpoint через NATPt. Клиенты в сети получают IPv6 с подсети основного WAN, и транслируются через резервный канал когда основной не доступен. Минус: на момент переключения мы теряем преимущество IPv6: прозрачную маршрутизацию, но без своей ASN я другого решения не вижу. Схема в работе больше 3 лет, работает отлично.
Ну и есть два минуса в самом использовании туннеля:
увы, но в интернетах до сих пор встречаются сервисы которые не понимая важность ICMP трафика банят то что банить нельзя (destination unreachable/package too big) ломая PMTUD и этим ломая HE туннель так как из-за 5 калек вешать на всю intranet MTU 1480 не охота, а без этого они не доступны через туннель.
приходится пройтись по многим geoip db и откорректировать данные о тех подсетях что вы используете для того чтобы бы сервисы которые их используют корректнее работали. Увы война с корпорацией добра (Google) у меня так и не увенчалась успехом, что я не делал, они не меняют geoip информацию на мои 2*/48 подсети на протяжении всех лет. Не понимаю я их если честно - у них в руках их личная geoip, данные геолокации с телефонов и они не могут даже их сопоставить, и форму заявки для ipv6 адаптировать не могут, как и человеко-саппорт добавить.
Разруливаю оба этих недостатка через unbound python модуль (раньше свой личный, а теперь тот что в pfBlockerNG): делаю strip AAAA для таких нехороших сервисов в DNS resolving. К слову снова с Google пришлось снова повоевать, нужно было обрезать AAAA сразу для нескольких их доменов, видители они в токены авторизации зашивают IP, и выдают свои токены на разные сервисы. Выходит: пришел на google.com по ipv4 - значит иди и на googleusercontent и на youtube, и т.д. Не знаю как у них это вообще работает даже с нормальным резолвингом, ибо любой браузер умеет и сам делать downgrade на запросы с ipv6 на ipv4, если при этом есть выигрыш в производительности.
Про MX ничего не выстрадано :), просто навидался на неверные конфирации других людей, и знаю как многие spam фильтры по понятным причинам вешают за это плохую оценку. Плюс очевидно что домен без MX не колышит bounce handling. Многие bounce можно получить сразу, прямо в tcp сессии двух почтовиков, но когда между 2 почтовиками (отправителем и получателем) есть еще один - почтовик (по класике отдельностоящий спам фильтр или концентратор) - bounce может прилитеть уже отдельным письмом - user not exist, user over quota, etc.
Про мониторинг DMARC - если у вас 101+ SMTP сервер - и полный бардак, то да, он вам нужен. А если у вас 1-3 SMTP сервера и /29 пул IPv4 и к нему притянуто за уши с /64 подсети аналогичное количество IPшников, то я не знаю на кой болт вам анализировать DMARC - настроил SPF & DKIM, проверил все 1-3 SMTP и забыл. Я ради интереса анализирую DMARC & TLS репорты - больше что бы увидеть каким бездельникам делать нефиг и делать spoofing dmarc p=reject; sp=reject. А так - я знаю что у меня все ок. Я предпочитаю не сливать в 3rd party отчеты, parsedmarc+elk хорошо справляется с этой задачей в docker-compose слепленном на коленке за пол часа. Увы пока TLS репорты проверяю глазами, и то делал это раз 5 - просто из интереса, DANE & MTA-STS у меня рабочий и отлаженный, парится не о чем. Но вот когда люди не шарящие (и это касается не только мелких компаний) настраивают DMARC, а потом дропают емейл указаный в нем - вот это вправду бесит, прямо очень. Я один из тех не многих кто шлет те самые DMARC репорты сам, и что поделать - ловлю bounce, если кто то известный - пишу им что бы поправили, если найду кому - редко помогает. Если не помогло вешаю получателя DMARC в бан что бы мой почтовик не отправлял ему отчет.
По поводу репутации IP: каждый сервис может как слушать жмени RBL, выставлять оценки за каждую или как идиот rejectить за наличие хоть в одном RBL, так и иметь свою внутренню систему репутации (вон с Rspamd это на раз-два). Интернет независим, каждый делат так как может (в виду скила и тех возможностей) и как хочет. К тому же Microsoft плевать если вы будете в 10 RBL, как и Google, но если они по своей внутренней системе репутации вас спутают с спамером (просто потому что IP спамера в той же подсети) - то все - привет junk folder или reject, а Microsoft может еще круче поступить, сказать 250 ОК, и молча выкинуть ваше письмо в /dev/null.
Слепо надеястя на то что юзер не кинет вас в junk мало, я уже говорил - следите за FBL loop и postmaster на больших Mail ISP, реагируйте на жалобы, меняйте тело письма и стратегию отправки если жалоб больше 5%.
Ну обычная p2p (people to people) переписка это одно - а mass mail, это уже совершенно другое, тут нужно подзапарится и время от времени проверять все ли ок.
Если IP еще использовался для отправки почты то нужно начинать им пользоваться постепенно, разогреть так сказать. Даже если он был в использовании но его объемы отправки резко вырастут некоторые репутационные сервисы могут воспринять это как спам. Это самый сложный из пунктов.
Как ни странно настроить SPF/DKIM/DMARC и не нарушать их.
Зарегистрироваться на как можно больше сервисов бесплатной почты для мониторинга своей репутации у них. Microsoft SNDS, Yahoo Postmaster, Mail.ru Postmaster, FBL ReturnPatch, DNSWL.org и тд.
На домене для отправки почты иметь MX и ящик для приема bounce сообщений, вроде очевидно - а бывает что некоторые об этом не парятся. Bounce приходят на envelope-from, mime-from, может отличаться, но и на него тоже стоит иметь MX, пусть даже с silent drop если это noreply@example.org
Следить за bounce, и желательно в автоматическом режиме исключать из рассылки тех кому идут permfail
Следить за очередью - если в ней письма задерживаются больше чем на 12 часов - разбираться почему
Иметь актуальный список емейлов и регулярный емейл трафик - а для этого нужно 2 вещи:
Если это рассылки с веб сервиса - валидировать емейл ваших пользователей в процессе регистрации. Никогда не слать рассылки тем кто ее не прошел. На самой форме регистрации использовать надёжную капчу и ограничение между попытками повторной регистрации и повторных отправлк писем валидации
По умолчанию предлагать пользователям новостные рассылки и отправлять их тем кто от них не отказался что бы поддержать некий уровень доставки почты. Рассылки всем нужно растягивать - слать пачками
Ну давай начнем с того что сейчас win7 без обновлений даже не может ставить новые драйвера. Установите win7 и поставьте на нее тот же OpenVPN ;) - у вас это получится только после установки обновлений для поддержки SHA-2. Пруф: https://community.openvpn.net/openvpn/ticket/1254
И так будет и свежими драйверами на другие устройства (если вы вообще их найдете)
Запустите подписанный софт, и получите ошибку и попап smartscreen - сертификаты используются не только в encryption, но и в signing исполняемых файлов и драйверов, и там выбор CA не настолько велик и они тоже експайрятся ;).
В общем я это к чему: мне ни капли не жаль тех людей что все еще пытаются плыть на утонувшем плоту, потому как, проблема утопающих - это только проблема самих утопающих. Извините за тафтологию. Пираты, не пираты, а обновленную хоть до последнего ОС поставить вы можете, а если нет - попросите тыжпрограмистов. (joke)
P.s. ни разу не видел в интернетах линуксоидов сидящих до сих пор на Ubuntu 12.04 (ОС как раз времен Win7) и жалующихся что их ОС или софт под ней криво работает в 2021. К слову - хорошая ОС была и харе заниматься некромантией :)
Upd:
Минимальна оценка потерь на порядки превышает стоимость решения. Я даже не захотел проверять.
На самом деле подождите первого обновления и проблема пройдет. У Windows реализована функция фонового обновление доверенных сертификатов. Можно принудительно запустить обновление скачав его с сайта Microsoft. https://support.microsoft.com/en-us/topic/support-for-urgent-trusted-root-updates-for-windows-root-certificate-program-in-windows-a4ac4d6c-7c62-3b6e-dfd2-377982bf3ea5
Так они еще й bgp каналы угоняют что бы трафик якобы с реальных ip apple отправлять, ибо все ж знают что подпись dkim подделать уже может и калькулятор.
Используемая мною библиотека dns_parser поддерживает не все типы DNS-запросов, а только некоторые самые распространённые.
Ну, не все так плохо: https://docs.rs/dns-parser/0.8.0/dns_parser/enum.Type.html
Когда читаешь такую формулировку думаешь что дела куда хуже :). А вообще мне как то привычнее сделать tcpdump с фильтром и потом почитать его в Wireshark, это будет более универсально - работает на любой ОС. А если говорить про unix, то поднимается за 3 минуты unbound на localhost и включается логирование всех запросов - готово.
Суд над https://en.m.wikipedia.org/wiki/George_Hotz vs Sony в таком духе и проходил. Мол консоль твоя, а вот ПО на ней — нет, и ты не имел права его взламывать, реверс енжинерить и модифирова. Ну тут конечно немного другая картина, парень не расказывал об уязвимости, он ее использовал что бы поставить на ps3 linux, ну а другие уже его же методами что бы запускать игры на халяву.
К слову по большому счету любой ASN который "строго" относится к своим клиентам в плане отправке почты зачастую имеет хорошую репутацию. Вывод: если нужно разблокировать 25 outgoing port и если ASN abuse contact отзывчивый и банит "своих" спамеров, то репутация у него будет зачастую хорошая. А те кто не банит 25 outbound по умолчанию мусорщики всегда.
Мне повезло что мой сервер в ДЦ на колокейшене и я саппорту вменяемый, я перед получением своей /29 подсети вменяемо обьяснил что мне нужен белый и пушистый IP потому что я планирую использовать всю /29 как отправителей SMTP. К тому же /29 лучше чем /32 для IPv4 потому как многие чекают репутацию минимум по /29 подсети, и соседний IP может вам испортить жизнь очень сильно. Хотя тот же Outlook блин болван банит всеми /24. Золотой пули увы нет, многие юзают hetzner дата центр, как повезет. Знаю что ovh к примеру не стоит брать, а по локальным ДЦ не подскажу ибо мое "локальное", скорее всего не "ваше" :).
Не путайте L4 с L7, вы реально готовы свой прод сайт повесить за L4 файрвол и отсекать всех и вся без разбора, просто из-за неудачного IP?
Mailu лучше уже валять на k8s/swarm. Для docker-compose mailcow куда лучше и профитнее
Я это и написал :)
Для "сокрытия" инфраструктуры есть такая вещь как reverse proxy. Вообще NAT-PT & NAT в IPv6 не одно и то же. NAT-PT (он же NPt) можно приравнивать к NAT1:1 в v4, а так в IPv6 непонятно зачем, но, можно и отдельные порты на отдельные IP натить. Да без NAT-PT сделать Multi WAN можно, но нужно иметь свою ASN и свою личную подсеть, пиров и ospf шлюз...
Там уже другая rce ;)
В смысле в полном обьеме? ВК вообще вырубили IPv6, еще давным давно, еще до того как его в Украине забанили...
>> но сам факт, что некоторые сайты могут криво работать с ipv6 забавляет :)
Скажем так - чем сайты которые работают по IPv6 могут делать что то криво? Разве что:geoip, rate limiting, brute force protection, ip restrictions. Тоесть все логические взяви с IP, их в системах не так уж и много. А то что не отображась картинки - это уже проблема из ряда DNS который указывает не на тот сервер или мисконфигурации самого веб сервера..., на прямую к IPv6 не имеющего отношения, просто те кто тестил работу сервиса могли банально забыть что у них еще есть IPv6. Видел одного клиента у которого "заводские" настройки DNS у регистратора имели АААА на парковочные IPv6. Их админ не понимая что такое АААА и почему он там - не стал его убирать, а А запись он конечно поправил. Вышла картина: сайт у них работает "для них", потому что у них нет IPv6, но для нас и для всех нормальных поисковых систем их сайт это что? Правильно - просто заглушка. А потом они удивлялись почему их в поисковиках никто найти не может... Ахаха...
По PMTUD - запустите Microsoft Skype for Business или Lync, и поймете :P
не понял причем там ВК :).
По MTU - прочитайте еще раз, проблем нет пока вы не наткнетесь на сервер у которого не функционирует PMTUD из-за неверного firewall на его стороне.
Такая же схема с pfsense: 2 HE туннеля, по одному на WAN, с разными HE endpoint через NATPt. Клиенты в сети получают IPv6 с подсети основного WAN, и транслируются через резервный канал когда основной не доступен. Минус: на момент переключения мы теряем преимущество IPv6: прозрачную маршрутизацию, но без своей ASN я другого решения не вижу. Схема в работе больше 3 лет, работает отлично.
Ну и есть два минуса в самом использовании туннеля:
увы, но в интернетах до сих пор встречаются сервисы которые не понимая важность ICMP трафика банят то что банить нельзя (destination unreachable/package too big) ломая PMTUD и этим ломая HE туннель так как из-за 5 калек вешать на всю intranet MTU 1480 не охота, а без этого они не доступны через туннель.
приходится пройтись по многим geoip db и откорректировать данные о тех подсетях что вы используете для того чтобы бы сервисы которые их используют корректнее работали. Увы война с корпорацией добра (Google) у меня так и не увенчалась успехом, что я не делал, они не меняют geoip информацию на мои 2*/48 подсети на протяжении всех лет. Не понимаю я их если честно - у них в руках их личная geoip, данные геолокации с телефонов и они не могут даже их сопоставить, и форму заявки для ipv6 адаптировать не могут, как и человеко-саппорт добавить.
Разруливаю оба этих недостатка через unbound python модуль (раньше свой личный, а теперь тот что в pfBlockerNG): делаю strip AAAA для таких нехороших сервисов в DNS resolving. К слову снова с Google пришлось снова повоевать, нужно было обрезать AAAA сразу для нескольких их доменов, видители они в токены авторизации зашивают IP, и выдают свои токены на разные сервисы. Выходит: пришел на google.com по ipv4 - значит иди и на googleusercontent и на youtube, и т.д. Не знаю как у них это вообще работает даже с нормальным резолвингом, ибо любой браузер умеет и сам делать downgrade на запросы с ipv6 на ipv4, если при этом есть выигрыш в производительности.
Про MX ничего не выстрадано :), просто навидался на неверные конфирации других людей, и знаю как многие spam фильтры по понятным причинам вешают за это плохую оценку. Плюс очевидно что домен без MX не колышит bounce handling. Многие bounce можно получить сразу, прямо в tcp сессии двух почтовиков, но когда между 2 почтовиками (отправителем и получателем) есть еще один - почтовик (по класике отдельностоящий спам фильтр или концентратор) - bounce может прилитеть уже отдельным письмом - user not exist, user over quota, etc.
Про мониторинг DMARC - если у вас 101+ SMTP сервер - и полный бардак, то да, он вам нужен. А если у вас 1-3 SMTP сервера и /29 пул IPv4 и к нему притянуто за уши с /64 подсети аналогичное количество IPшников, то я не знаю на кой болт вам анализировать DMARC - настроил SPF & DKIM, проверил все 1-3 SMTP и забыл. Я ради интереса анализирую DMARC & TLS репорты - больше что бы увидеть каким бездельникам делать нефиг и делать spoofing dmarc p=reject; sp=reject. А так - я знаю что у меня все ок. Я предпочитаю не сливать в 3rd party отчеты, parsedmarc+elk хорошо справляется с этой задачей в docker-compose слепленном на коленке за пол часа. Увы пока TLS репорты проверяю глазами, и то делал это раз 5 - просто из интереса, DANE & MTA-STS у меня рабочий и отлаженный, парится не о чем. Но вот когда люди не шарящие (и это касается не только мелких компаний) настраивают DMARC, а потом дропают емейл указаный в нем - вот это вправду бесит, прямо очень. Я один из тех не многих кто шлет те самые DMARC репорты сам, и что поделать - ловлю bounce, если кто то известный - пишу им что бы поправили, если найду кому - редко помогает. Если не помогло вешаю получателя DMARC в бан что бы мой почтовик не отправлял ему отчет.
По поводу репутации IP: каждый сервис может как слушать жмени RBL, выставлять оценки за каждую или как идиот rejectить за наличие хоть в одном RBL, так и иметь свою внутренню систему репутации (вон с Rspamd это на раз-два). Интернет независим, каждый делат так как может (в виду скила и тех возможностей) и как хочет. К тому же Microsoft плевать если вы будете в 10 RBL, как и Google, но если они по своей внутренней системе репутации вас спутают с спамером (просто потому что IP спамера в той же подсети) - то все - привет junk folder или reject, а Microsoft может еще круче поступить, сказать 250 ОК, и молча выкинуть ваше письмо в /dev/null.
Слепо надеястя на то что юзер не кинет вас в junk мало, я уже говорил - следите за FBL loop и postmaster на больших Mail ISP, реагируйте на жалобы, меняйте тело письма и стратегию отправки если жалоб больше 5%.
Ну обычная p2p (people to people) переписка это одно - а mass mail, это уже совершенно другое, тут нужно подзапарится и время от времени проверять все ли ок.
Если IP еще использовался для отправки почты то нужно начинать им пользоваться постепенно, разогреть так сказать. Даже если он был в использовании но его объемы отправки резко вырастут некоторые репутационные сервисы могут воспринять это как спам. Это самый сложный из пунктов.
Как ни странно настроить SPF/DKIM/DMARC и не нарушать их.
Зарегистрироваться на как можно больше сервисов бесплатной почты для мониторинга своей репутации у них. Microsoft SNDS, Yahoo Postmaster, Mail.ru Postmaster, FBL ReturnPatch, DNSWL.org и тд.
На домене для отправки почты иметь MX и ящик для приема bounce сообщений, вроде очевидно - а бывает что некоторые об этом не парятся. Bounce приходят на envelope-from, mime-from, может отличаться, но и на него тоже стоит иметь MX, пусть даже с silent drop если это noreply@example.org
Следить за bounce, и желательно в автоматическом режиме исключать из рассылки тех кому идут permfail
Следить за очередью - если в ней письма задерживаются больше чем на 12 часов - разбираться почему
Иметь актуальный список емейлов и регулярный емейл трафик - а для этого нужно 2 вещи:
Если это рассылки с веб сервиса - валидировать емейл ваших пользователей в процессе регистрации. Никогда не слать рассылки тем кто ее не прошел. На самой форме регистрации использовать надёжную капчу и ограничение между попытками повторной регистрации и повторных отправлк писем валидации
По умолчанию предлагать пользователям новостные рассылки и отправлять их тем кто от них не отказался что бы поддержать некий уровень доставки почты. Рассылки всем нужно растягивать - слать пачками
Это пока вы сударь не наткнетесь на Hsts ;)
Ну давай начнем с того что сейчас win7 без обновлений даже не может ставить новые драйвера. Установите win7 и поставьте на нее тот же OpenVPN ;) - у вас это получится только после установки обновлений для поддержки SHA-2. Пруф: https://community.openvpn.net/openvpn/ticket/1254
И так будет и свежими драйверами на другие устройства (если вы вообще их найдете)
Запустите подписанный софт, и получите ошибку и попап smartscreen - сертификаты используются не только в encryption, но и в signing исполняемых файлов и драйверов, и там выбор CA не настолько велик и они тоже експайрятся ;).
В общем я это к чему: мне ни капли не жаль тех людей что все еще пытаются плыть на утонувшем плоту, потому как, проблема утопающих - это только проблема самих утопающих. Извините за тафтологию. Пираты, не пираты, а обновленную хоть до последнего ОС поставить вы можете, а если нет - попросите тыжпрограмистов. (joke)
P.s. ни разу не видел в интернетах линуксоидов сидящих до сих пор на Ubuntu 12.04 (ОС как раз времен Win7) и жалующихся что их ОС или софт под ней криво работает в 2021. К слову - хорошая ОС была и харе заниматься некромантией :)
Upd:
Вот эту часть вообще не понял.
На самом деле подождите первого обновления и проблема пройдет. У Windows реализована функция фонового обновление доверенных сертификатов. Можно принудительно запустить обновление скачав его с сайта Microsoft. https://support.microsoft.com/en-us/topic/support-for-urgent-trusted-root-updates-for-windows-root-certificate-program-in-windows-a4ac4d6c-7c62-3b6e-dfd2-377982bf3ea5
Потому что ваш старый сертификат имел в цепочке устаревший СА. Если бы позаботились об этом сами, такого бы не произошло.
Для этого есть слово "гик" или "гуру"
Так они еще й bgp каналы угоняют что бы трафик якобы с реальных ip apple отправлять, ибо все ж знают что подпись dkim подделать уже может и калькулятор.
(сарказм)
Ну, не все так плохо: https://docs.rs/dns-parser/0.8.0/dns_parser/enum.Type.html
Когда читаешь такую формулировку думаешь что дела куда хуже :). А вообще мне как то привычнее сделать tcpdump с фильтром и потом почитать его в Wireshark, это будет более универсально - работает на любой ОС. А если говорить про unix, то поднимается за 3 минуты unbound на localhost и включается логирование всех запросов - готово.
Суд над https://en.m.wikipedia.org/wiki/George_Hotz vs Sony в таком духе и проходил. Мол консоль твоя, а вот ПО на ней — нет, и ты не имел права его взламывать, реверс енжинерить и модифирова. Ну тут конечно немного другая картина, парень не расказывал об уязвимости, он ее использовал что бы поставить на ps3 linux, ну а другие уже его же методами что бы запускать игры на халяву.
К слову по большому счету любой ASN который "строго" относится к своим клиентам в плане отправке почты зачастую имеет хорошую репутацию. Вывод: если нужно разблокировать 25 outgoing port и если ASN abuse contact отзывчивый и банит "своих" спамеров, то репутация у него будет зачастую хорошая. А те кто не банит 25 outbound по умолчанию мусорщики всегда.
Мне повезло что мой сервер в ДЦ на колокейшене и я саппорту вменяемый, я перед получением своей /29 подсети вменяемо обьяснил что мне нужен белый и пушистый IP потому что я планирую использовать всю /29 как отправителей SMTP. К тому же /29 лучше чем /32 для IPv4 потому как многие чекают репутацию минимум по /29 подсети, и соседний IP может вам испортить жизнь очень сильно. Хотя тот же Outlook блин болван банит всеми /24. Золотой пули увы нет, многие юзают hetzner дата центр, как повезет. Знаю что ovh к примеру не стоит брать, а по локальным ДЦ не подскажу ибо мое "локальное", скорее всего не "ваше" :).
У меня кроме основного IP для почты еще стоит PostalHQ для массовых рассылок который юзает сразу все 3 IP. Как только я получил свою подсеть /29 подсеть я пошел на http://multirbl.valli.org/lookup и проверил все свои IP и еще пару соседей. Кроме этого чекнул их на talosintelligence.com (тут можно и соседей как раз сразу увидеть на всю /24 подсеть) http://www.anti-abuse.org/multi-rbl-check-results https://www.cyren.com/security-center/cyren-ip-reputation-check и https://ipremoval.sms.symantec.com/