PostgreSQL-ը VPN-ի միջոցով՝ ո՞ր աղբյուրի հասցեն կտեսնի pg_hba

PostgreSQL-ը երբեք չի իմանում, որ հաճախորդը VPN-ում է։ Այն ստանում է TCP միացում ինչ-որ հասցեից և հավատարմագրերի հավաքածու, և որոշում է, թե ինչ անել դրանցով։ Ուստի մուտքը թունելից կախված դարձնելը նշանակում է երեք առանձին որոշումներ այնպես դասավորել, որ դրանք համաձայնեն, և ապա ստուգել այն միակ հասցեն, որը սերվերը իրականում տեսնում է, այլ ոչ թե այն, որը դուք գծել եք սխեմայի վրա։

Երեք որոշում, որոնք չպետք է միաձուլվեն

Թե որտեղ է սերվերը լսում, առաջին որոշումն է։ Թե որ տրաֆիկը կարող է հասնել այդ հասցեին, երկրորդն է, որը կայացնում է հոսթի firewall-ը և դրա դիմացի ցանկացած ցանցային սահման։ Թե որ տվյալների բազայի ինքնությունը կարող է նույնականացվել որ աղբյուրից, երրորդն է, որը կայացվում է pg_hba.conf-ում։

Յուրաքանչյուրը պարտադրվում է տարբեր բաղադրիչի կողմից, և յուրաքանչյուրը ձախողվում է տարբեր հաղորդագրությամբ։ Դրանք քննարկման մեջ միաձուլելը հանգեցնում է նրան, որ մարդիկ սկսում են խմբագրել HBA ֆայլը՝ firewall-ի խնդիրը լուծելու համար։ Պահեք դրանք հերթականությամբ՝ չկապված լսողին հնարավոր չէ հասնել, զտված պորտին հնարավոր չէ միանալ, և 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-ի ներսից։ Այս երեք արդյունքները բաժանում են ցանցային սահմանը տվյալների բազայի լիազորումից, ինչն էլ որոշումները առանձին պահելու ամբողջ իմաստն է։