Търговски 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 записи, които обезсмислят списъка с разрешени.

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

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