Многие, кто что-то публично селфхостит у себя дома сталкиваются с проблемой одновременного доступа к ресурсам изнутри и снаружи. Это не касается случаев, когда, например, ресурс размещён на роутере или роутер выступает в качестве реверс прокси - запросы в любом случае идут через сам роутер и проблемы нет. Проблема возникает, когда роутер не является реверс-прокси.

Сетап, при котором возникает проблема:

• публичный IP ресурса указывает на роутер (1.2.3.4);
• на роутере проброс портов на реверс-прокси, который размещён внутри сети;
• реверс-прокси следит за SSL-сертификатами и проксирует ресурсы, которые находятся так же внутри сети (192.168.88.101);
• внутренний PiHole

Что же делать? Вариантов решения, лежащих на поверхности, минимум пара.

Самый простой и очевидный - обращаться к внутренним ресурсам по внутренним именам или ip. Что-то вроде cloud.home или 192.168.88.101. С внутренними именами нам поможет PiHole (или любой другой DNS-сервер).

Второй вариант - переназначить для внутренней сети публичный IP адрес. Было cloud.example.com - 1.2.3.4, стало cloud.example.com - 192.168.88.101. В этом нам тоже поможет PiHole. Для мобильной техники плюс большой - ненужно ничего перенастраивать для доступа снаружи.

Вариант, ресурсы находятся только внутри сети и доступ извне получаем только подключившись через VPN к домашней сети я не рассматриваю. Но рассмотрю ещё один вариант с использованием IPv6.

Для этого варианта нем требуется сеть IPv6, которую мы можем получить у домашнего провайдера (счастливчики) или у туннельных брокеров (это, в моей практике, чаще встречается). И тут получается третий вариант - прописываем AAAA запись для реверс-прокси нашего ресурса и, внутри сети, обращаемся уже по нему. На роутере разрешаем форвардинг пакетов к нашему реверс-прокси и получаем доступ уже и снаружи, при наличии поддержки IPv6, конечно же.

Как можем заметить, для последнего варианта нам не особенно нужен PiHole, но нужен IPv6 (не забудьте только прикрыть доступ ко всей сети снаружи).