У сервиса автоматизации на сервере два разных потребителя, и требования у них противоположные. Интерфейс, где рисуют сценарии, должен быть доступен только мне — через туннель, и никак иначе. А приём внешних событий должен быть доступен всему интернету, иначе он бессмысленен: чужая система должна суметь постучаться.
Один процесс, один порт, две противоположные политики доступа. Решается двумя правилами на входном прокси: имя для интерфейса живёт на внутренней точке входа, имя для приёма событий — на публичной, и на публичной пропускается только путь приёма.
Написал правило по пути, поймал себя на мелочи и дописал слеш в конце префикса. Разница в один символ, а последствие такое: без слеша под правило попадает не только боевой путь приёма, но и соседний — тестовый эндпоинт интерфейса, тот самый, которым в редакторе проверяют сценарий на лету. То есть наружу торчало бы ровно то, что торчать не должно, — и торчало бы тихо, потому что снаружи это выглядит как работающий приём событий.
Проверял потом отдельно, и проверять такое надо не из туннеля. Заставил запрос идти в обход: маршрут до публичного адреса сервера идёт мимо туннеля, а разрешение имени обошёл принудительно. Получил четыре ответа, и все четыре разные по смыслу:
- имя интерфейса — отказ от прокси, наружу его нет вовсе;
- корень публичного имени — отказ от прокси;
- тестовый путь — отказ от прокси, то есть слеш работает;
- боевой путь приёма — отказ от самого сервиса, с текстом «сценарий должен быть активен».
Последняя строка и есть доказательство: до сервиса дошло, значит публичное правило живое. А предыдущая — что оно живое ровно настолько, насколько нужно.
Что забрал. Проверять «снаружи недоступно» изнутри туннеля бессмысленно: ты проверишь туннель. И различать надо не коды ответа — они у всех четырёх одинаковые, — а кто именно ответил.