Пиринг OpenVPN и VPC - Как разрешить домены .compute.internal в двух разных учетных записях с BIND9 - PullRequest
Новая
       46

Пиринг OpenVPN и VPC - Как разрешить домены .compute.internal в двух разных учетных записях с BIND9

1 голос
/ 04 июля 2019

В нашей компании у нас есть три учетные записи AWS, основная из которых используется в качестве «корневой» учетной записи для IAM и содержит сервер доступа OpenVPN. Два других аккаунта - pro и stg. Каждый из них имеет свой собственный VPC с различными диапазонами IP-адресов, и у нас есть VPC, пирингующийся между учетными записями root и pro, а другой - между root и stg. IP-маршрутизация уже настроена, и все контролируется с этой стороны.

(извините, я пока не могу загрузить изображения, поэтому у вас есть ссылка) VPN + VPC-пиринг

Проблема связана с разрешением DNS. Это установка:

Я установил BIND9 на сервере OpenVPN, чтобы разрешить пересылку DNS для частных размещенных доменов, используя конфигурацию, подобную этой в named.conf.local

zone "stg-my-internal-domain.com" IN {
    type forward;
    forward only;
    forwarders { 10.229.1.100;10.229.2.100; };
};


zone "pro-my-internal-domain.com" IN {
    type forward;
    forward only;
    forwarders { 10.228.1.100;10.228.2.100; };
};

А также два входящих распознавателя Route53 (простой сервер BIND, работающий на каждом VPC, также работает), работающих в 10.229.1.100 и 10.229.2.100 для stg и 10.228.1.100 10.228.2.100 для pro учетная запись

Клиенты VPN имеют профили OpenVPN, которые используют сервер доступа в качестве распознавателя DNS.

На моем клиенте я могу точно разрешить и my-service-1.pro-my-internal-domain.com, и my-service-2.stg-my-internal-domain.com, но проблема возникает, когда я хочу разрешить внутренние доменные имена, подобные тем, которые AWS генерирует внутри каждого VPC с my-service-2.eu-west-1.compute.internal

Я знаю, что это анти-шаблон, и я всегда должен использовать частный домен как можно чаще, но в некоторых случаях, таких как кластеры EMR, менеджеры YARN и Hadoop используют ссылки, которые ссылаются на внутренние имена AWS, делая разрешение невозможно.

Так что мой вопрос: есть ли способ настроить DNS для делегирования разрешения на вторичный адрес, если первичный отказывает?

Я мог бы настроить пересылку для зоны eu-west-1.compute.internal, используя все средства разрешения учетных записей, но Спецификация DNS гласит, что вторичный сервер имен будет использоваться только в том случае, если первый недоступен, поэтому, поскольку он отвечает на пустой или «неизвестный» ответ, он все еще является действительным ответом, а второй не будет запрошен.

Любая помощь очень ценится!

1 Ответ

0 голосов
/ 09 июля 2019

Почему бы просто не изменить внутреннее имя хоста на общедоступное имя DNS?Эти службы используют имя хоста, назначенное им, конечно.Вы можете изменить это.См. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-hostname.html

Возможно, вам (или не нужно) назначать фиксированные частные ips для каждого.В любом случае опубликуйте этот частный IP в публичной зоне DNS.После этого вы сможете правильно разрешить эти имена.Обратите внимание, что вы также можете запускать скрипт при каждом запуске при обновлении имени хоста и записи DNS.

Для хорошего обсуждения частных IP-адресов в общедоступной DNS см. https://serverfault.com/questions/4458/private-ip-address-in-public-dns

. Для справки, вот лучший ответ:

Некоторые людискажем, никакие публичные записи DNS никогда не должны раскрывать частные IP-адреса .... с учетом того, что вы даете потенциальным злоумышленникам возможность получить некоторую информацию, которая может потребоваться для эксплуатации частных систем.Лично я считаю, что обфускация - плохая форма безопасности, особенно когда мы говорим об IP-адресах, потому что в общем случае их легко угадать, поэтому я не рассматриваю это как реальный компромисс безопасности.Здесь больше внимания уделяется тому, чтобы ваши публичные пользователи не воспринимали эту запись DNS как часть обычных общедоступных служб вашего размещенного приложения.То есть: внешние DNS-запросы как-то начинают разрешаться по адресу, к которому они не могут добраться.Кроме того, я не вижу фундаментальной причины, по которой размещение личных записей адреса А в общедоступном пространстве является проблемой ... особенно, если у вас нет альтернативного DNS-сервера для их размещения.Если вы решите поместить эту запись в публичное пространство DNS, вы можете рассмотреть возможность создания отдельной зоны на том же сервере для хранения всех «личных» записей.Это прояснит, что они предназначены для частного использования ... однако для одной записи A, вероятно, я бы не стал беспокоиться.

...