VPN нужен мне для доступа к домашним сервисам извне. Но когда я дома, подключаться к нему ради управления сервером неудобно. Компьютер уже находится в домашней сети — хочется открыть панель или подключиться по SSH без дополнительных действий.

При настройке веб-сервера выяснилось, что это работает не для всех способов доступа. Панель управления была доступна напрямую, а SSH и административная часть блога имели другие ограничения. Приходилось разбираться, на каком участке останавливается соединение.

Одна домашняя сеть — несколько зон

В моей инфраструктуре компьютеры и серверы находятся в разных сетевых сегментах. Поэтому запрос с компьютера к серверу проходит через маршрутизатор и его правила доступа.

Такое разделение полезно: гостевым устройствам и домашним гаджетам не требуется доступ к управлению серверами. Но само по себе оно не определяет, кому разрешено подключаться. Эти разрешения нужно настроить отдельно.

В итоге фраза «я же дома» ничего не объясняет межсетевому экрану. Он видит адрес источника, адрес назначения и порт, а затем применяет правило.

Доступ проверяется на нескольких уровнях

В этой истории пришлось проверить три места.

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

Второе — межсетевой экран сервера. У него был собственный список разрешённых источников для SSH. Одного изменения на маршрутизаторе оказалось бы недостаточно.

Третье — веб-сервер. Для административных страниц блога действовали отдельные ограничения. Главная страница могла открываться, а форма входа оставаться недоступной с того же компьютера.

Это объяснило, почему разные сервисы на одной машине вели себя по-разному.

Что изменили

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

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

На этом проверка веб-доступа закончилась: вход в учётную запись в тот момент не выполнялся. Доступность страницы и успешная авторизация — разные результаты, и смешивать их не стоит.

Позже проявилась ещё одна деталь

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

В правилах ранее был разрешён конкретный адрес компьютера. После его смены прежняя проверка уже не описывала текущую ситуацию.

Это важный момент для точечных исключений: если доступ привязан к адресу, нужно обеспечить его стабильность. Например, закрепить адрес за устройством в DHCP и затем повторить проверку. Саму такую настройку в рамках описанной проверки мы ещё не подтверждали.

С чего теперь начинаю диагностику

Сначала проверяю фактический адрес компьютера и маршрут до сервера. Затем — доступность нужного порта и правила на каждом участке соединения. Только после этого перехожу к настройкам приложения.

И отдельно отмечаю, каким путём получен результат: напрямую из домашней сети, через VPN или через промежуточный сервер.

Для меня удобная схема выглядит так: дома серверы доступны с моего компьютера напрямую, вне дома — через VPN. При этом управление остаётся защищено штатной авторизацией и точечными сетевыми разрешениями.