PostgreSQL VPN арқылы: pg_hba қай бастауыш мекенжайды көреді

Тыңдаушы, firewall және бірінші сәйкес HBA ережесі — үш шешім. Префиксті таңдамас бұрын PostgreSQL шын мәнінде қабылдайтын көзді тексеріңіз.

PostgreSQL клиенттің VPN-де екенін ешқашан білмейді. Ол бір мекенжайдан TCP қосылымын және тіркелгі деректерінің жиынын қабылдап, олармен не істеу керегін шешеді. Сондықтан қолжетімділікті туннельге тәуелді ету — үш бөлек шешімді өзара сәйкестенетіндей реттеу, содан кейін диаграммада салған мекенжайдың орнына сервер шын мәнінде көретін жалғыз мекенжайды тексеру деген сөз.

Біріктіруге болмайтын үш шешім

Сервердің қайда тыңдайтыны — бірінші шешім. Қай трафиктің сол мекенжайға жете алатыны — екіншісі, оны хосттың firewall-ы және оның алдындағы кез келген желілік шекара қабылдайды. Қай дерекқор сәйкестігінің қай көзден аутентификациялана алатыны — үшіншісі, ол pg_hba.conf ішінде қабылданады.

Олардың әрқайсысын бөлек компонент орындайды және әрқайсысы бөлек хабарламамен сәтсіз аяқталады. Оларды талқылауда біріктіру — адамдардың firewall мәселесін түзету үшін HBA файлын өңдеуіне әкеледі. Оларды ретімен ұстаңыз: байланыстырылмаған тыңдаушыға жету мүмкін емес, сүзілген портқа қосылу мүмкін емес, ал HBA ережесі қосылым пайда болғаннан кейін не болатынын ғана шешеді. Өзгеріс әсер етпесе, үш қабаттың қайсысын шынымен өзгерткеніңізді анықтаңыз.

Сервер қайда тыңдайды

Интерфейс атына емес, машинаға шынымен берілген мекенжайға байланыстырыңыз:

listen_addresses = '10.20.0.30'

Дерекқор өзінің туннель интерфейсінсіз VPN шлюзінің артында тұруы мүмкін, дәл сондықтан мекенжайды атау дұрыс. Бұл параметрді өзгерту толық қайта іске қосуды талап етеді; қайта жүктеу жеткіліксіз.

Содан кейін портты, әдетте 5432-ні, хостта және оның алдындағы әр шекарада сүзіңіз. Жеке мекенжайға байланыстыру жариялы түрде қабылдамаудың дәлелі емес, өйткені портты бағыттау немесе бұлттық мекенжайды салыстыру пакеттерді сол жеке тыңдаушыға жеткізуі мүмкін.

HBA шын мәнінде көретін мекенжай

Маршрутталған қолжетімділікте сервер әр клиенттің ішкі туннель мекенжайын көреді. Көзді аудару кезінде оның орнына шлюздің аударылған мекенжайын көреді және барлық клиент сол бір мәнге жинақталады. Рұқсат етілетін префиксті таңдамас бұрын көзді сервердің өз қосылым дәлелдері арқылы тексеріңіз.

TLS пен SCRAM-ды қолданып жатқан орналастыру үшін әдейі тар қашықтан қолжетімділік үлгісі былай көрінеді:

hostssl appdb app_login 10.8.0.0/24 scram-sha-256
host all all 0.0.0.0/0 reject
host all all ::/0 reject

Бұл көрсетілген пулдан TLS арқылы бір рөлге және бір дерекқорға рұқсат береді, содан кейін басқа қашықтан TCP қолжетімділігін қабылдамайды. Бұл толық HBA файлын алмастырмайды: жергілікті әкімшілендіруді, репликацияны және кез келген басқа рұқсат етілген қызметті сақтаңыз, ал тар ережелерді кеңірек рұқсаттардың алдына қойыңыз.

Аудару іске қосылғанда HBA клиенттерді бастапқы мекенжайлары бойынша ажырата алмайды. Желілік қабылдауды қатаң ұстаңыз және нақты дерекқор тіркелгі деректерін талап етіңіз, және trust аутентификациясын нақты тіркелгімен ешқашан алмастырмаңыз.

Бірінші сәйкестік жеңеді, қосалқы жол жоқ

PostgreSQL файлды жоғарыдан төмен оқып, қосылымға сәйкес келетін бірінші жазбаны пайдаланады. Егер сол жазбаның аутентификациясы сәтсіз болса, екінші әрекет жоқ, сондықтан ертерек кең рұқсат кейінгі бас тартуды үнсіз жеңеді.

Осы рет ережесі мұқият жазылған бас тартудың ешқашан күшіне енбеуінің ең жиі себебі. Нақты ережелерді бірінші, кеңдерін соңына қойыңыз, содан кейін файлды жиын ретінде емес, тізбек ретінде оқыңыз. Төменге қосқан ереже саясат емес, ол түсініктеме. Файл еленбейді деген қорытындыға келмес бұрын оны жоғары жылжытып, қайта жүктеңіз.

HBA анықтамасы ретті де, host және hostssl жазбаларының айырмашылығын да анықтайды, бұл ереженің мәні қосылымның шифрлануы болғанда маңызды.

Қайта жүктеу, қайта іске қосу және бас тартылған жағдай

HBA өзгерістері қайта жүктеумен қолданылады, ал pg_hba_file_rules көрінісі талдау қателерін табуға көмектеседі. Бұл көрініс файлдың ағымдағы мазмұнын сипаттайды, жұмыс істеп тұрған сервер оларды сәтті жүктегенін емес, сондықтан таза тізім жаңа ережелердің күшінде екенінің дәлелі емес.

Тыңдаушының өзгерістері өз қайта іске қосылуын қажет етеді, ал өзгеріс әсер етпейтін сияқты көрінгенде екі операцияны шатастыру оңай.

Жаңа сессиялармен сынаңыз: көзделген тіркелгісі бар мақұлданған клиент қосылады, сол тіркелгі мақұлданбаған жолдан қосылмайды, ал рұқсат етілмеген дерекқор сәйкестігі VPN ішінен де сәтсіз болады. Осы үш нәтиже желілік шекараны дерекқор авторизациясынан ажыратады, бұл шешімдерді бөлек ұстаудың бүкіл мәні.

Қатысты мақалалар