Экземпляр EC2 не может получить доступ к репозиториям amazon-linux (например, amazon-linux-extras install docker) через конечную точку шлюза s3
У меня горе с конечной точкой s3. Когда мои экземпляры инициализируются, они не могут установить докер. Подробности:
У меня есть экземпляры ASG, сидящие в VPC с пабами и частными подсетями. Соответствующая маршрутизация и EIP / NAT все зашиты. В экземплярах в частных подсетях outbouond 0.0.0.0/0 перенаправлен на NAT в соответствующих общедоступных подсетях. NACL для общедоступной подсети разрешают входящий и исходящий интернет-трафик, NACL вокруг частных подсетей разрешают входящий и исходящий трафик из общедоступных подсетей, исходящий трафик в Интернет (а также входящий и исходящий трафик от s3 cidr). Я хочу, чтобы это было под замком.
- В моем VPC включены DNS и имена хостов
- Я понимаю, что NACL не имеют состояния и включили правила IN и OUTBOUND для блоков cidr IP s3 amazon в эфемерных диапазонах портов (да, я также включил трафик между pub и частными подсетями)
- да, я проверил, что маршрут был подготовлен для моей конечной точки s3 в моих частных таблицах маршрутов
- да, я точно знаю, что это конечная точка s3 вызывает у меня горе, а не очередная ошибка -> когда я удаляю ее и открываю свои NACL, я могу yum обновить и установить докер (как и ожидалось) Я не ищу предложений, которые требуют открытия моего NACL, я использую endpiont шлюза VPC, потому что я хочу, чтобы все было заблокировано в частных подсетях. Я упоминаю об этом, потому что похожие обсуждения, кажется, говорят: «Я открыл 0.0.0.0/0 на всех портах, и теперь x работает»
- Стоит ли просто запечь AMI с установленным докером? Вот что я сделаю, если не смогу решить эту проблему. Я действительно хотел настроить свою сеть, чтобы все было хорошо заблокировано и казалось, что с использованием конечных точек все должно быть довольно просто. В основном это сетевое упражнение, поэтому я бы предпочел не делать этого, потому что это позволяет избежать решения и понимания проблемы.
- Я знаю, что другие мои конечные точки VPC работают отлично -> Выполняется конечная точка интерфейса службы автоматического масштабирования (я вижу, что она уменьшает количество экземпляров в соответствии с политикой), конечная точка интерфейса SSM позволяет мне использовать диспетчер сеансов, а конечная точка (и) ECR работают в сочетании с конечной точкой шлюза s3 (требуется конечная точка шлюза s3, потому что слои изображения находятся в s3) -> Я знаю, что это работает, потому что если я открою NACLS и удалю свою конечную точку s3 и установлю докер, затем снова заблокирую все, верну мой s3 gatewayendpoint Я могу успешно извлечь свои изображения ECR. Итак, конечная точка шлюза s3 подходит для доступа к слоям изображений ecr, но не к репозиториям amazon-linux-extra.
- SG, прикрепленные к экземплярам, не являются проблемой (экземпляры имеют исходящее правило по умолчанию)
- Я попытался добавить все более щедрые политики к моей конечной точке s3, как я видел в этой ветке 7-летней давности, и подумал, что это должно помочь (да, я правильно добавил свой регион)
- Я твердо уверен, что решение заключается в политике шлюза s3, обсуждаемой в этой ветке, однако мне мало повезло с моей все более отчаянной политикой.
Инстанс Amazon EC2 не может обновлять или использовать yum
еще одна борьба s3 с разрешением:
Я пытался:
S3Endpoint:
Type: 'AWS::EC2::VPCEndpoint'
Properties:
PolicyDocument:
Version: 2012-10-17
Statement:
- Effect: Allow
Principal: '*'
Action:
- 's3:GetObject'
Resource:
- 'arn:aws:s3:::prod-ap-southeast-2-starport-layer-bucket/*'
- 'arn:aws:s3:::packages.*.amazonaws.com/*'
- 'arn:aws:s3:::repo.*.amazonaws.com/*'
- 'arn:aws:s3:::amazonlinux-2-repos-ap-southeast-2.s3.ap-southeast-2.amazonaws.com/*'
- 'arn:aws:s3:::amazonlinux.*.amazonaws.com/*'
- 'arn:aws:s3:::*.amazonaws.com'
- 'arn:aws:s3:::*.amazonaws.com/*'
- 'arn:aws:s3:::*.ap-southeast-2.amazonaws.com/*'
- 'arn:aws:s3:::*.ap-southeast-2.amazonaws.com/'
- 'arn:aws:s3:::*repos.ap-southeast-2-.amazonaws.com'
- 'arn:aws:s3:::*repos.ap-southeast-2.amazonaws.com/*'
- 'arn:aws:s3:::repo.ap-southeast-2-.amazonaws.com'
- 'arn:aws:s3:::repo.ap-southeast-2.amazonaws.com/*'
RouteTableIds:
- !Ref PrivateRouteTableA
- !Ref PrivateRouteTableB
ServiceName: !Sub 'com.amazonaws.${AWS::Region}.s3'
VpcId: !Ref BasicVpc
VpcEndpointType: Gateway
(как видите, очень отчаянно) Первое правило требуется, чтобы конечные точки интерфейса ECR извлекали слои изображения из s3, все остальные - это попытки добраться до репозиториев amazon-linux-extras.
Ниже показано поведение, происходящее при инициализации, которую я воссоздал, подключившись к диспетчеру сеансов с помощью конечной точки SSM:
https://aws.amazon.com/premiumsupport/knowledge-center/connect-s3-vpc-endpoint/
Я не могу установить или обновить yum
root@ip-10-0-3-120 bin]# yum install docker -y
Загруженные плагины: extras_suggestions, langpacks, priority, update-motd Не удалось получить список зеркал Ошибка https://amazonlinux-2-repos-ap-southeast-2.s3.ap-southeast-2.amazonaws.com/2/core/latest/x86_64 / mirror.list была 14: ошибка HTTPS 403 - запрещено
Сбой одного из настроенных репозиториев (Неизвестно), а в yum недостаточно кэшированных данных для продолжения. На этом этапе единственная безопасная вещь, которую может сделать yum - потерпеть неудачу. Есть несколько способов "исправить" это:
1. Contact the upstream for the repository and get them to fix the problem.
2. Reconfigure the baseurl/etc. for the repository, to point to a working
upstream. This is most often useful if you are using a newer
distribution release than is supported by the repository (and the
packages for the previous distribution release still work).
3. Run the command with the repository temporarily disabled
yum --disablerepo=<repoid> ...
4. Disable the repository permanently, so yum won't use it by default. Yum
will then just ignore the repository until you permanently enable it
again or use --enablerepo for temporary usage:
yum-config-manager --disable <repoid>
or
subscription-manager repos --disable=<repoid>
5. Configure the failing repository to be skipped, if it is unavailable.
Note that yum will try to contact the repo. when it runs most commands,
so will have to try and fail each time (and thus. yum will be be much
slower). If it is a very temporary problem though, this is often a nice
compromise:
yum-config-manager --save --setopt=<repoid>.skip_if_unavailable=true
Не удается найти действительный базовый URL-адрес для репо: amzn2-core / 2 / x86_64
и не может:
amazon-linux-extras install docker
Catalog is not reachable. Try again later.
каталоги на https://amazonlinux-2-repos-ap-southeast-2.s3.ap-southeast-2.amazonaws.com/2/extras-catalog-x86_64-v2.json , https://amazonlinux-2- repos-ap-southeast-2.s3.ap-southeast-2.amazonaws.com/2/extras-catalog-x86_64.jsonОтслеживание (последний вызов последним): файл "/usr/lib/python2.7/site-packages/amazon_linux_extras/software_catalog.py", строка 131, в fetch_new_catalog request = urlopen (url) File "/ usr / lib64 / python2.7 / urllib2.py", строка 154, в urlopen return opener.open (url, data, timeout) Файл" /usr/lib64/python2.7/urllib2.py", строка 435, в open response = meth(req, ответ) Файл "/usr/lib64/python2.7/urllib2.py", строка 548, в http_response 'http', запрос, ответ, код, msg, hdrs) Файл "/usr/lib64/python2.7/urllib2.py", строка 473, по ошибке вернуть self._call_chain(*args) Файл" /usr/lib64/python2.7/urllib2.py", строка 407, в _call_chain result = func (* args) File" / usr / lib64 /python2.7/urllib2.py", строка 556, в http_error_default поднять HTTPError(req.get_full_url(), code, msg, hdrs,fp)HTTPError: Ошибка HTTP 403: запрещено
Какие-то ошибки, которые я пропустил? Я здесь очень застрял. Я знаком с базовыми сетями VPC, NACL и конечными точками VPC (по крайней мере, теми, которые я использовал), я следил за устранением неполадок (хотя у меня уже было все настроено, как описано).
Я чувствую, что проблема здесь в политике s3 ИЛИ в списке зеркал. Большое спасибо, если вы удосужились все это прочитать! Мысли?
3 ответа
Судя по всему, вы прекрасно понимаете, чего пытаетесь достичь. Даже если вы говорите, что это не NACL, я бы проверил их еще раз, так как иногда можно легко упустить из виду что-то незначительное. Примите во внимание приведенный ниже фрагмент, взятый из этой статьи об устранении неполадок AWS, и убедитесь, что в ваших правилах указаны правильные идентификаторы CIDR S3 для соответствующего региона:
Убедитесь, что сетевые ACL, связанные с подсетью вашего экземпляра EC2, разрешают следующее: выход на порт 80 (HTTP) и 443 (HTTPS) в региональную службу S3. Вход на эфемерные порты TCP из региональной службы S3. Эфемерные порты - 1024-65535. Региональная служба S3 - это CIDR для подсети, содержащей конечную точку интерфейса S3. Или, если вы используете шлюз S3, региональная служба S3 представляет собой общедоступный IP-адрес CIDR для службы S3. Сетевые ACL не поддерживают списки префиксов. Чтобы добавить S3 CIDR в сетевой ACL, используйте 0.0.0.0/0 в качестве S3 CIDR. Вы также можете добавить фактические CIDR S3 в ACL. Однако имейте в виду, что идентификаторы CIDR S3 могут измениться в любой момент.
На первый взгляд, ваша политика конечной точки S3 кажется мне хорошей, но вы правы в том, что очень вероятно, что политика или конфигурация конечной точки в целом могут быть причиной, поэтому я бы перепроверил и ее еще раз.
Еще одна вещь, которую я наблюдал ранее, заключается в том, что в зависимости от используемого AMI и настроек VPC (набор параметров DHCP, DNS и т. Д.) Иногда экземпляр EC2 не может правильно установить регион по умолчанию в конфигурации yum. Пожалуйста, проверьте, есть ли у файлов
$ cat /etc/yum/vars/awsregion
ap-southeast-2
Вы можете проверить, правильно ли работает разрешение DNS на вашем экземпляре:
dig amazonlinux.ap-southeast-2.amazonaws.com
Если кажется, что DNS работает нормально, вы можете сравнить, находится ли IP в выходных данных в пределах диапазонов, которые вы разрешили в ваших NACL.
Привет, @nick Nick -> это отличные предложения по написанию «ответа», потому что устранение неполадок будет полезно для других, плюс ограничение символов в комментариях.
Проблема, безусловно, в политике.
sh-4.2$ cat /etc/yum/vars/awsregion
ap-southeast-2sh-4.2$
копать землю:
sh-4.2$ dig amazonlinux.ap-southeast-2.amazonaws.com
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.5.2 <<>> amazonlinux.ap-southeast-2.amazonaws.com;; глобальные параметры: +cmd;; Получил ответ:;; ->>HEADER<<- код операции: QUERY, статус: NOERROR, id: 598;; флаги: qr rd ra; ЗАПРОС: 1, ОТВЕТ: 2, АВТОРИТЕТ: 0, ДОПОЛНИТЕЛЬНО: 1
;; ОПТИЧЕСКАЯ ПСЕВДОЗЕКЦИЯ:; EDNS: версия: 0, флаги :; UDP: 4096;; РАЗДЕЛ ВОПРОСОВ:; amazonlinux.ap-southeast-2.amazonaws.com. В
;; РАЗДЕЛ ОТВЕТОВ: amazonlinux.ap-southeast-2.amazonaws.com. 278 В CNAME s3.dualstack.ap-southeast-2.amazonaws.com. s3.dualstack.ap-southeast-2.amazonaws.com. 2 IN A 52.95.134.91
;; Время запроса: 4 мсек ;; СЕРВЕР: 10.0.0.2#53(10.0.0.2);; КОГДА: Пн, 20 сентября, 00:03:36 UTC 2021;; РАЗМЕР MSG rcvd: 112
давайте проверим NACL:
SO -----> '52.95.134.91'захватывается правилом 101 для исходящих и 400 для входящих, так что с точки зрения NACL это выглядит хорошо. (проблемы с будущими людьми, это то, что вам нужно искать)
Также в отношении этих блоков CIDR сценарий Deploy извлекает их из текущего списка и извлекает блоки s3 для ap-southeast-2 с помощью jq и передает их в качестве параметров развертыванию CF.
документы о том, как это сделать для других: https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html#aws-ip-download
Еще одно замечание, вы могли заметить выход 0.0.0.0/0, я понимаю (и для других людей, которые ищут, пожалуйста, заметку), это делает другие правила излишними, я просто вставляю его `` на всякий случай '' во время возни (и удаляю -> pub подсети). исходящий трафик частной подсети 0.0.0.0/0 направляется на соответствующие NAT в общедоступных подсетях. Я добавлю исходящий трафик для своих общедоступных подсетей и в какой-то момент удалю это правило.
подсети atm просто: 10.0.0.0/16 pub a: 10.0.0.0/24 pubb: 10.0.1.0/24 priv a: 10.0.2.0/24 priv b: 10.0.3.0/24
поэтому правила для блоков pub a и b будут повторно введены, поэтому я могу удалить разрешение на 0.0.0.0/0
Теперь я уверен, что это политика.
Я просто щелчком изменил политику в консоли на «полный доступ», чтобы дать ей взлом, и добился успеха.
Я предполагаю, что список зеркал затрудняет определение того, что явно разрешить, поэтому, даже если я разыграл широкую сетку, я не захватил требуемую корзину. Но я мало что знаю о том, как работают зеркала AWS, так что это предположение.
Я, вероятно, не хочу супер-разрешительной политики, так что это не совсем исправление, но оно подтверждает, в чем проблема.
У меня была аналогичная проблема. запуск «amazon-linux-extras» вообще ничего не делал.
Проблема заключалась в том, что экземпляр имел V4 и V6. V6 не работал должным образом в нашем исходящем сетевом пути. Отключение V6 решило это.