Шлюзът хоства собствената си администраторска страница: вътрешен или публичен адрес

Администраторска страница отговаря от телефон с мобилни данни и изтича по време от лаптоп, свързан към VPN. Нищо в тунела не е счупено, защото заявката никога не влиза в него. Името на хоста се разрешава до публичния адрес на шлюза, а този адрес е достъпен само отвън от тунела, който той завършва. Поправянето означава да дадете на услугата частен вход, вместо да местите външната крайна точка.

Страницата се зарежда отвън, а не през тунела

Сравняват се две различни заявки. От мобилни данни браузърът достига публичния адрес директно. Отвътре в тунела същото име се разрешава до същия публичен адрес и пакетът сега трябва да излезе през тунела, за да достигне адрес от собствената далечна страна на тунела. Същото име, същият адрес, две много различни позиции.

Маршрутът за дестинация избира адрес, а не порт. Нищо в таблицата за маршрутизация не знае, че порт 443 е за администриране, а порт 1194 е транспортът, затова и двата се третират като една и съща дестинация.

Затова страницата понякога работи, а понякога не, в зависимост от това кое име и коя мрежа е използвал клиентът. Това е проблем на пътя, а не проблем на удостоверяването. И двата клиента се удостоверяват напълно успешно.

Пазете външната крайна точка достъпна

Профилите с пълен тунел се нуждаят от маршрут-изключение за крайната точка на VPN и опцията redirect-gateway на OpenVPN документира точно това: отдалечената крайна точка запазва маршрут през предварително съществуващия шлюз, за да не маршрутизира тунелът в себе си. Премахнете това изключение и криптираният транспорт следва тунела, което прекратява сесията в цикъл. Именно това изключение държи адреса на крайната точка достъпен отвътре в тунела.

Следствието е, че публичният адрес остава достъпен от клиента, поради което заявка на браузъра към този адрес може да следва същото изключение и да излезе, без да влезе в тунела. Изключението си върши работата, а името нанася щетата.

Четете решението за маршрута, а не списъка с интерфейси, преди да промените нещо. Командите по-долу отпечатват решението, а не инвентара. Изпълнете ги от клиента, който се провали.

ip -4 route get 203.0.113.77
ip -4 rule show
ip -4 route show table all

Ако търсенето показва маршрута на крайната точка през физическия шлюз, поведението е правилно и администраторската страница просто се изпраща по грешен път. Това е моментът, в който разрешаването на имена става поправката.

Дайте на услугата частно име

Услугата се нуждае от име, което се разрешава до адреса на шлюза вътре в тунела, като същевременно се запазва семантиката на сертификата и името на хоста, която приложението очаква. Частен зонов запис за администраторското име е обичайният отговор, и той оставя транспортното име незасегнато.

Не пренасочвайте транспортното име към вътрешния адрес, защото следващото установяване на тунел ще се опита да достигне адрес, който съществува само вътре в тунел. Тази грешка дава VPN, който работи точно веднъж.

Проверете и двете семейства адреси, защото оставен запис AAAA може да изпрати браузъра някъде, където частният план никога не е покривал.

dig +short admin.hq.internal
dig +short -t AAAA admin.hq.internal
curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://admin.hq.internal/

Съобразете политиката с мястото, където работи процесът

До роден процес, слушащ на шлюза, се стига по пътя на локалния вход, затова входната верига и обвързването на сокета решават дали заявката ще бъде приета. Правилата за препращане и IP препращането не карат локален слушател да отговаря. Разрешете източниците на тунела във входната политика и потвърдете, че процесът е обвързан с адрес, който тунелът може да достигне.

Контейнер, публикуван на порт на хоста, следва различен път, защото пакетът се преобразува по дестинация и се препраща. Тази заявка среща политиката за препращане на хоста и собствените правила на Docker, поради което работещ роден слушател може да съществува заедно с контейнер, който отказва същия порт.

Редът на стартиране е важен и в двата случая, защото обвързване към адрес, който се появява само след като тунелът вдигне, се проваля тихо при зареждане.

Проверете частния достъп и отказания публичен път

Направете нова именувана заявка от оторизиран клиент, като проверките за идентичност на приложението остават непокътнати. После опитайте същата услуга отвън на тунела и потвърдете, че не отговаря. Частното име е удобство, а не ограничение, а слушател, все още обвързан с публичния адрес, все още е изложен. Именно последната проверка повечето прегледи пропускат.

Четете обвързванията и състоянието на филтъра, а не името на хоста, което потребителите са получили. Излагането е свойство на сокета, а не на името. Това разграничение оцелява при всяка промяна на DNS.

ss -lntp | grep ':443'
nft list ruleset | grep -n 443
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' https://203.0.113.77/

Когато вътрешната заявка връща страницата, а външната изтича по време, услугата има един умишлен частен път и транспортът остава достъпен. Когато външната заявка все още отговаря, слушателят или публикуван запис на контейнер трябва да се стесни, преди някой да опише услугата като само вътрешна.