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

В какво се превръща адресът на източника

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

Правилата на защитната стена на Azure SQL на ниво сървър и на ниво база данни сравняват адреса на клиента, който достига до логическия сървър, а след пълен тунел това е изходният адрес. Група за сигурност на AWS, която разрешава един адрес, се държи по същия начин. Пакетът се изхвърля преди удостоверяването, така че грешката, която получавате, изглежда като мрежов отказ, а не като проблем с правата. Точно затова хората започват да нулират пароли.

Къде се решава списъкът с разрешени адреси

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

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

Три поправки, три слоя

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

RepairLayer it changesWhat it does not fix
Add the egress address to the ruleSource address matchingNothing about routing, and it breaks when the egress moves
Use a private endpointWhether the service is reached privatelyA client that still resolves the public name
Add a split-tunnel exceptionWhich flows bypass the tunnelAn expired credential or a wrong password

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

Защо управлявана платформа не може да се присъедини към тунела

Платформи за приложения като Heroku, AppHarbor или CloudBees изпълняват кода ви в среда без устройство tun или tap и без права да създадат такова. Техният модел за входящ трафик е HTTP, а не произволен слушащ сокет. Пакет за изграждане, който доставя VPN бинарник, все още няма къде да постави интерфейса. Работещите модели са статичен изходен адрес, който базата данни може да разреши, продукт за частна връзка, който платформата предлага, или прокси в DMZ, достъпно през HTTPS.

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

Проверете от клиента, който се провали

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

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

Подобни статии