VPN-ը չի արգելափակում psql-ը. ձեր կլիենտը զանգահարում է այլուր
psql-ը և GUI կլիենտը կարող են նույն սարքից դիմել տարբեր վերջնակետերի։ Համեմատեք հոսթը, սոքեթը, դերը և TLS-ը՝ նախքան VPN-ին մեղադրելը։
Երկու կլիենտներն էլ նույն նոթբուքի վրա են, անցնում են նույն թունելով, և նրանցից միայն մեկն է միանում։ Այդ համեմատությունը թվում է ապացույց, որ VPN-ը ընտրողական է, մինչդեռ շատ ավելի տարածված բացատրությունն այն է, որ երկու կլիենտները դիմում են տարբեր նպատակակետերի։ GUI-ն պահում է իր սեփական հոսթը, պորտը, դերն ու TLS-ի կարգավորումները և անհրաժեշտության դեպքում լուռ կառուցում է SSH փոխանցում, մինչդեռ psql-ը միացումը հավաքում է libpq-ի լռելյայն արժեքներից, որոնք ձեր shell-ը գուցե արդեն սահմանել է։ Աշխատող միացումը վերարտադրելը GUI-ի կարգավորումները կարդալու հարց է, ոչ թե թունելը վերատեղադրելու։
Առասպելը. մեկ աշխատող կլիենտն ապացուցում է ուղին
Եթե GUI-ն միանում է, թունելը տեղափոխում է տրաֆիկ, և դա միակ բանն է, ինչ GUI-ն ապացուցում է։ Այն ոչինչ չի ասում, թե psql-ը որ հասցեն է լուծում, որ դերով է նույնականացվում, կամ թե բացած սոքեթը երբևէ դուրս է գալիս սարքից։ Ուղին ընդհանուր է, պարամետրերը՝ ոչ։
Տեղական փոխանցումը մեծացնում է տարբերությունը։ GUI-ն կարող է միանալ 127.0.0.1-ին այն պորտով, որը փոխանցել է SSH-ով, և այդ լսողը գոյություն ունի միայն GUI-ի սեսիայի ընթացքում։ Առանց փոխանցման localhost-ին ուղղված psql-ը ստանում է մերժված միացում, որը ոչ մի կապ չունի VPN-ի հետ։
Կարդացեք այն վերջնակետը, որն իրականում օգտագործում է GUI-ն
Բացեք միացման հատկությունները և պատճենեք չորս արժեք՝ հոսթ, պորտ, տվյալների բազա և դեր։ Ապա փնտրեք թունելի ներդիր, որովհետև SSH փոխանցումը մասնավոր հասցեն դարձնում է տեղական պորտ և փոխում է այն, ինչ պետք է ասել psql-ին։
| Setting | What the GUI holds | What psql uses when the value is absent |
|---|---|---|
| Destination | A saved hostname, sometimes behind a forward | A local Unix socket, not the remote endpoint |
| Port | The direct port or a forwarded local port | 5432, or the port from a service file |
| Role and database | Stored per connection profile | Your operating-system user name |
| TLS identity | Its own CA bundle and verification mode | Whatever PGSSLMODE or the service file says |
| Startup files | Not read at all | Read unless -X is passed |
Յուրաքանչյուր տող ձախողվում է տարբեր շերտում, և ստացված հաղորդագրությունը նշում է այդ շերտը։ Պահված պրոֆիլի ընկերական անունը psql-ի մեջ փակցնելը վերը նշված արժեքներից ոչ մեկը չի փոխանցում, և ծառայության անունը լուծվում է ֆայլի միջոցով, որը տերմինալը գուցե երբեք չկարդա։
Ինչ է libpq-ն ժառանգում ձեր shell-ից
psql-ը բարակ կլիենտ է libpq-ի վրա, և libpq-ն շրջապատը կարդում է ամեն ինչից առաջ։ PGHOST, PGHOSTADDR, PGPORT, PGDATABASE, PGUSER, PGSERVICE և PGSSLMODE փոփոխականներից յուրաքանչյուրը կարող է վերաուղղորդել միացման մի մասը։ Դրանք ժառանգվում են, ոչ թե մուտքագրվում, ուստի ձեր գործարկած հրամանում ոչինչ դրանք չի ցուցադրում։ Արտահանված PGSSLMODE-ը նույնպես կարող է փոխել այն, ինչ կլիենտն ընդունում է՝ առանց հրամանի տողում մեկ բառ ասելու։
Այդ փոփոխականներից երկուսն առաջին հերթին կասկածի տեղիք են տալիս։ PGHOSTADDR-ը տալիս է թվային նպատակակետ, որը շրջանցում է անունների լուծումը, մինչդեռ հոսթի անունը դեռ որոշում է վկայագրի ինքնությունը, իսկ PGSERVICE-ը ծառայության ֆայլից հանում է հոսթը, տվյալների բազան և TLS-ի ընտրությունները։ Ամբողջ միջավայրը դատարկելը այս խնդիրը վրիպազերծելու համար վատ սովորություն է, քանի որ այն կարող է պարունակել գաղտնաբառեր և անկապ նշաններ. փոխարենը ընտրեք ձեզ հետաքրքրող փոփոխականները։
Ե՛վ host-ը, և՛ hostaddr-ը բաց թողնելը ընտրում է Unix դոմենի սոքեթ՝ ցանցային հասցեի փոխարեն։ Ուստի առանց -h-ի psql կանչը կարող է տեղում հաջողվել կամ ձախողվել սոքեթի սխալով՝ երբեք չդիպչելով այն ուղուն, որն օգտագործում է GUI-ն։
Ուղարկեք նույն պարամետրերը ձեռքով
GUI-ի արժեքները ձեռքին՝ փոխանցեք դրանք հստակորեն և բաց թողեք մեկնարկային ֆայլը, որը կարող է ավելացնել վերագրանցումներ։ Ստորև բերված միացման տողը օրինակ է՝ փոխարինեք վերջնակետը, պորտը, տվյալների բազան և դերը ձեր ադմինիստրատորի հաստատած արժեքներով և պահեք արդեն աշխատող վստահության կարգավորումը։
psql -X "host=db.internal.example port=6432 dbname=orders user=report_ro sslmode=verify-full connect_timeout=5"Այդ հրամանում երեք մանրամասն դիտավորյալ են։ -X-ը ճնշում է psql-ի մեկնարկային ֆայլը, թեև չի ճնշում libpq-ի միջավայրը կամ ծառայության սահմանումը։ connect_timeout=5-ը թույլ չի տալիս դատարկ ուղուն տերմինալը րոպեներով կախել։ sslmode=verify-full-ը միացված է պահում վկայագրի և հոսթի անվան ստուգումները, ինչը հենց այն մասն է, որ մարդիկ անջատում են, երբ հայտնվում է TLS սխալ։
Եթե հաստատված վերջնակետը pooler-ի հետևում է, 6432 և 5432 պորտերը կարող են հասնել նույն տվյալներին տարբեր սերվերի ինքնությունների միջոցով, և ստուգումը կարող է ձախողվել pooler-ի անունով, ոչ թե տվյալների բազայի անունով։ Ուղղեք անունը միացման տողում՝ եղանակը թուլացնելու փոխարեն։
Թող սխալի հաղորդագրությունն ընտրի հաջորդ քայլը
Ձախողման տեքստը ասում է, թե որքան հեռու է գնացել փորձը, և դա գերազանցում է թունելի մասին ցանկացած ենթադրության։ Անունը, որը չի լուծվի, ձախողվում է սոքեթի գոյությունից առաջ, ժամանակի սպառումը նշանակում է, որ ուղին կամ firewall-ը գցել է փաթեթները, մերժումը նշանակում է, որ ինչ-որ բան պատասխանել և հրաժարվել է, իսկ նույնականացման սխալը նշանակում է, որ ցանցն արդեն աշխատում էր։
psql -X -w "host=db.internal.example port=6432 dbname=orders user=report_ro sslmode=verify-full connect_timeout=5" -c '\conninfo'
env | grep -E '^PG'
psql --versionՀամեմատեք \conninfo-ի ելքը GUI-ի կենդանի սեսիայի հետ՝ նույն հոսթը, նույն պորտը, նույն դերը, նույն TLS վիճակը։ Երբ այս չորսը համընկնեն, VPN-ին այլևս բացատրելու բան չի մնա։ Քանի դեռ դրանք չեն համընկնում, թունելի յուրաքանչյուր լրացուցիչ փոփոխություն ենթադրություն է միացման մասին, որը տերմինալը երբեք չի արել։