Чи блокує комерційний VPN порт 5432? Порівняйте варіанти

Застосунок щодня спілкувався зі своєю базою даних з офісу. Потім хтось увімкнув комерційний клієнт VPN на тому самому ноутбуці, і з'єднання почало скидатися після рукостискання. У застосунку нічого не змінилося, тунель повідомляє, що здоровий, а в мережевому екрані, який ви контролюєте, немає правила блокування. Змінився шлях виходу: сервери постачальника — це спільні високонавантажені кінцеві точки, а постачальники фільтрують вихідні порти, щоб зменшити зловживання. Портьи баз даних і надсилання пошти отримують найбільшу частину цього, бо саме вони приваблюють сканування й спам з анонімного пулу адрес.

П'ятихвилинна перевірка, яка відокремлює фільтрацію від усього іншого

З тієї самої машини перевірте один порт, який має бути відкритим, і порт, що збоїть, на тому самому хості: спочатку з увімкненим тунелем, потім із вимкненим. Використовуйте ту саму команду обидва рази, щоб єдиною змінною був тунель:

Test-NetConnection db.example.com -Port 443
Test-NetConnection db.example.com -Port 5432
nc -vz -w3 db.example.com 5432

Чотири результати охоплюють майже всі випадки. Якщо 443 працює, а 5432 збоїть лише з увімкненим тунелем, ви бачите фільтрацію портів на шляху виходу. Якщо обидва збоїть з тунелем і обидва працюють без нього, проблема в маршрутизації або DNS, а не в політиці портів. Якщо обидва порти з'єднуються, але застосунок усе одно збоїть, вина в автентифікації або TLS, а не в доступності. І якщо збоїть лише одне розташування сервера постачальника, це політика для конкретного сервера, тому спробуйте інше розташування, перш ніж чіпати будь-яку конфігурацію.

Перший варіант: розділений тунель для підмережі бази даних

Якщо ноутбуку комерційний VPN потрібен лише для інших цілей, виключіть діапазон адрес бази даних із тунелю, щоб трафік взагалі не потрапляв на спільний вихід. Це найчистіший варіант, коли двом шляхам справді не потрібно зустрічатися, і він не коштує нічого, крім правила маршрутизації, яке ви можете задокументувати. Компроміс у тому, що розділений тунель запроваджує другу поверхню політики: те, що виключено з тунелю, має бути навмисним, а не побічним ефектом підмережі, яку хтось додав пізніше.

Він перестає працювати в той момент, коли база даних перебуває всередині мережі, до якої VPN має дістатися, тому перевірте це, перш ніж зупинитися на ньому.

Другий варіант: власна кінцева точка, власний вихід

Запуск невеликої VPN-кінцевої точки на VPS дає вам контроль над політикою виходу, і спільний пул тут не задіяний. Це варіант, який варто чесно порівняти з комерційним клієнтом: ви отримуєте передбачувану адресу джерела й втрачаєте глобальний слід і зручність постачальника. Для команди, якій порти баз даних і пошти потрібні весь день, компроміс зазвичай схиляється на користь власної кінцевої точки, бо режимом збою стає ваша власна помилкова конфігурація, а не чужа політика проти зловживань.

Порівняйте обидва за стабільністю адреси джерела, за тим, хто може читати ваш трафік, і за тим, що відбувається того дня, коли постачальник кінцевої точки змінює власну фільтрацію.

Третій варіант: приберіть ноутбук із цього шляху

Завдання CI, запуск контейнера за розкладом або бастіонний хост усередині дозволеної мережі не залежать від стану тунелю людини. Дістаньтеся бази даних через SSH-тунель із хоста, який уже дозволений, і ноутбук ніколи не звертається до порту напряму. Це варіант, який масштабується, коли кілька людей упираються в те саме обмеження, і він же усуває проблему, а не обходить її.

Він вимагає більше роботи заздалегідь, ніж правило розділеного тунелю, і не допомагає тій одній людині, якій просто зараз потрібна інтерактивна сесія.

Чому додавання адреси постачальника до списку дозволених — неправильне порівняння

Додавання вихідної адреси постачальника до списку дозволених для бази даних справді працює, але воно також дає доступ кожному іншому абонентові, який у цей момент ділить цю адресу. Для репліки лише для читання за вузько виданим обліковим записом застосунку розкриття може бути терпимим на один день. Для чогось записуваного це не компроміс, гідний назви, а змінні вихідні адреси все погіршують: кожна зміна сервера ламає правило, а обслуговування запрошує широкі записи CIDR, які зводять нанівець сенс списку дозволених.

Виділені або статичні адреси, там де постачальник їх продає, — єдина версія цього, яка масштабується. Прив'яжіть список дозволених до адреси, яка належить лише вам, або не прив'язуйте взагалі.

Що б ви не вибрали, запишіть шлях і причину. Наступна людина зіткнеться з тим самим з'єднанням, що скидається, і почне звинувачувати застосунок.