Маршрутизатор доставляет свои собственные SSL-сертификаты вместо моего домена на хосты локальной сети

Я установил службу nextcloud на свой NAS в док-контейнере, и служба доступна из Интернета через полное доменное имя, для которого я создал подстановочные сертификаты Letsencrypt. Обратный прокси (Traefik) отправляет запросы к службе и обрабатывает http/https.

Все работает нормально за пределами моей локальной сети, но при подключении к nextcloud из локальной сети возникают ошибки сертификата. Например, попытка открыть домашнюю страницу nextcloud из Firefox дает:

nextcloud.yourdomain.com uses an invalid security certificate.
The certificate is not trusted because it is self-signed.
Error code: MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT
View Certificate

Нажатие на «Просмотр сертификата» фактически показывает собственный сертификат маршрутизатора.

В качестве дополнительной информации, мое полное доменное имя службы nextcloud правильно разрешается в общедоступный IP-адрес моего маршрутизатора даже из локальной сети, т.е.

ping nextcloud.yourdomain.com

правильно возвращает общедоступный IP-адрес моего маршрутизатора.

Как я могу этого избежать? Почему маршрутизатор использует свои собственные сертификаты для https-трафика на хосты, находящиеся внутри моей локальной сети, вместо сертификатов Letsencrypt моего домена, точно так же, как это происходит из-за пределов локальной сети?

Очевидно, что обратный прокси-сервер или NAS не виноваты, поскольку https-запросы даже не доходят до них.

Не могли бы вы помочь мне с дополнительным устранением неполадок? Спасибо, Пи.


ssl lets-encrypt https router nextcloud
person Sergio    schedule 10.01.2021    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Внешний IP-адрес, который вы используете, на самом деле является IP-адресом вашего маршрутизатора. Для трафика извне (т. е. из Интернета) существует правило переадресации портов, которое перенаправляет этот трафик на внутренний сервер. Для трафика изнутри эта переадресация портов применяться не будет — так работает ваш конкретный маршрутизатор. И поскольку на самом деле на том же порту работает служба (административный интерфейс маршрутизатора), и она доступна изнутри, она будет использоваться вместо нее.

Обратите внимание, что именно так работает этот конкретный маршрутизатор. Другой маршрутизатор может применять переадресацию портов как для внутреннего, так и для внешнего трафика. Однако в этом случае также потребуется поддержка петли NAT.

Обходным путем может быть использование разделенного DNS, то есть доступ к nextcloud извне по общедоступному IP-адресу и изнутри по внутреннему IP-адресу. Неизвестно, можно ли выполнить такую ​​настройку с системами, которые у вас уже есть.

person Steffen Ullrich    schedule 10.01.2021
comment
Привет, Штеффен, петля NAT действительно является проблемой, я пришел к такому же выводу, проводя дальнейшие исследования. У меня есть потребительский маршрутизатор (Sercomm), предоставленный телефонной компанией, и я совершенно уверен, что он не поддерживает петлю NAT, поэтому мне придется прибегнуть к использованию методов разделения DNS, как вы предлагаете. Я уже использую PiHole в своей локальной сети: послужит ли это цели, любой ресурс, на который вы можете мне указать, кроме поиска в Google? Спасибо - person Sergio; 10.01.2021
comment
@Sergio: Судя по короткому поиску, pi-hole должен поддерживать что-то вроде локальных записей DNS, которые, вероятно, можно использовать для этой службы. т.е. просто разрешите свой общедоступный домен своему внутреннему IP-адресу на pi-hole, независимо от того, имеет ли он другой IP-адрес при разрешении в Интернете. - person Steffen Ullrich; 10.01.2021
comment
Сделанный. Я определил локальные настройки DNS в Pi-Hole и настроил его в качестве DNS-сервера для своих устройств при подключении к локальной сети Wi-Fi. Работает отлично - person Sergio; 10.01.2021