MySQL localhost-ը VPN-ի միջոցով. դեռ նշանակում է տեղական գործընթաց

Գրասենյակի սերվերի հավելվածը միանում է MySQL-ին localhost հասցեով, դուք պատճենում եք այդ հոսթի անունը աշխատասեղանի հաճախորդի մեջ, և կապը կամ ձախողվում է, կամ բացում է այլ տվյալների բազա։ VPN-ը ոչինչ չփոխեց բառի իմաստում՝ localhost-ը դեռ վերաբերում է այն մեքենային, որտեղ աշխատում է հաճախորդը։ VPN-ը տեղափոխեց փաթեթներ, ոչ ինտերֆեյսներ։ Որոշեք, թե որ վերջնակետին պետք է հասնի նոութբուքը, նախքան որևէ երթուղու դիպչելը։

Քայլ 1. որոշեք, թե որ վերջնակետին պետք է հասնի նոութբուքը

Երկու նախագծերն էլ օրինական են և պատասխանում են տարբեր հարցերի։ Ուղիղ հասանելիությունը նշանակում է, որ տվյալների բազան լսում է մասնավոր հասցեով, որին հասնում է թունելը, և նոութբուքը միանում է այդ հասցեին։ Փոխանցված հասանելիությունը նշանակում է, որ տվյալների բազան մնում է loopback-ի վրա, և SSH նստաշրջանը պորտը տանում է ձեր մեքենա։ Ընտրեք մեկը գիտակցաբար, որովհետև դրանք խառնելը ստեղծում է կապ, որն աշխատում է սխալ պատճառով։

Ուղիղ հասանելիության համար վերցրեք տվյալների բազայի հոսթի սեփական մասնավոր անունը կամ հասցեն և դրա պորտը նրանից, ով կառավարում է այն։ VPN-ի դարպասի հասցեն տվյալների բազայի հասցեն չէ, եթե դա նույն մեքենան չէ։ Այնուհետև հաստատեք, որ լսողը իսկապես կապված է այդ ինտերֆեյսին, որովհետև ինտերֆեյսի ուղղված երթուղին լսող չի ստեղծում դրա վրա։

Քայլ 2. փոխանցեք պորտը միայն այն դեպքում, երբ լսողը մնում է տեղական

Եթե տվյալների բազան պետք է մնա միայն loopback-ի վրա, փոխանցեք այն SSH-ով և տեղական ծայրը նույնպես կապեք loopback-ին։ Ձախ կողմի կապման հասցեն ձեր նոութբուքինն է, աջ կողմի թիրախը մեկնաբանվում է SSH սերվերի կողմից, ինչպես նկարագրում է OpenSSH-ի տեղեկագիրքը։ Այդ երկու դերերը շրջելն է սովորական պատճառը, որ փոխանցումը կարծես աշխատում է, բայց ոչնչի չի միանում։

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:13306:127.0.0.1:3306 [email protected]
ss -ltn 'sport = :13306'

Եթե SSH-ը վայրէջք է կատարում ցատկող հոսթի վրա, այլ ոչ թե տվյալների բազայի հոսթի, աջ կողմի loopback-ը վերաբերում է ցատկող հոսթին, և թիրախը պետք է փոխվի հասցեի, որին այդ հոսթը հասնում է։ ExitOnForwardFailure-ը բռնում է փոխանցումը հաստատելու ձախողումը, բայց չի ապացուցում, որ թիրախին ուղղված հետագա կապերը հաջողվում են։ Թողեք հոսթի բանալու ստուգումը միացված և մի առաջարկեք փոխանցման պորտը ձեր ամբողջ LAN-ին՝ այն բոլոր ինտերֆեյսերին կապելով։

Կանգնեք, եթե տվյալների բազան պետք է մնա միայն loopback-ի վրա, և դուք չեք կարող օգտագործել SSH։ Այդ դեպքում ուղիղ հասանելիությունը սխալ նախագիծ է, ոչ թե պարտադրվող կարգավորում։

Քայլ 3. ստիպեք հաճախորդին անցնել TCP-ի

Unix-ում localhost ստացած MySQL հաճախորդը լռելյայն ընտրում է Unix սոկետ, ուստի միայն պորտը փոխելը կարող է նրան թողնել փնտրելու սոկետ, որը ոչ մի կապ չունի ձեր փոխանցման հետ։ Օգտագործեք բացահայտ TCP արձանագրությունը և loopback հասցեն, որպեսզի հաճախորդը կապ բացի ձեր փոխանցման պորտին։

mysql --protocol=TCP --host=127.0.0.1 --port=13306 --user=DB_USER --password

Առանց արժեքի գաղտնաբառի ընտրանքը հարցնում է՝ գաղտնիքը հրամանի տողում դնելու փոխարեն, և դա այն սովորույթն է, որ արժե պահել։ Այլ գործիքներ ունեն իրենց անջատիչը նույն տարբերության համար, և որոշ դրայվերներ localhost-ին նույնպես հատուկ են վերաբերվում։ Ստուգեք, թե ինչ է անում ձեր հաճախորդը, փոխարենը ենթադրելու, որ դրոշակը փոխանցվել է։ Տվյալների բազայի հաշվին նույնպես անհրաժեշտ է թույլտվություն, որը համապատասխանում է սերվերի տեսած աղբյուրին, և դա փոխանցման հոսթն է, ոչ ձեր նոութբուքը։

Կանգնեք, եթե գործիքը հնարավոր չէ ստիպել TCP-ի։ Այդ դեպքում օգտագործեք այլ հաճախորդ կամ ուղիղ հասանելիություն մասնավոր լսողին։

Քայլ 4. ապացուցեք, թե որ վերջնակետին եք իրականում հասել

Հարցրեք սերվերին, թե ինչ է կարծում, որ կապն է։ Հոսթի անվան, պորտի և սոկետի փոփոխականները ասում են՝ արդյոք եկել եք TCP-ով և որ լսողն է պատասխանել, իսկ կապերի ցանկը ցույց է տալիս աղբյուրի հասցեն, որը սերվերը գրանցել է։ Այդ ապացույցն ավելի օգտակար է, քան ևս մեկ երթուղու փոփոխություն։

mysql --protocol=TCP -h 127.0.0.1 -P 13306 -u DB_USER -p -e "SELECT @@hostname, @@port, @@socket"

Գրանցեք, թե որ վերջնակետն եք փորձել՝ տեղական Unix սոկետ, ձեր փոխանցման պորտը կամ մասնավոր լսողը։ Այս երեք ձախողումներն ունեն տարբեր ուղղումներ, և VPN-ի երթուղին փոխելը, մինչ հաճախորդը դեռ խոսում է սխալ localhost-ի հետ, վատնված ջանք է։ Նոթերում առանձին պահեք նաև SSH նույնականացումը և տվյալների բազայի նույնականացումը, որովհետև մեկում ձախողումը աշխատասեղանի հաճախորդից նման է մյուսում ձախողմանը։ Այնուհետև հեռացրեք փոխանցումը, երբ ավարտեք։

Ցանկը ավարտվում է, երբ կարող եք անվանել վերջնակետը, հաճախորդի արձանագրությունը, սերվերի տեսած աղբյուրի հասցեն և թույլտվությունը, որը դա թույլ տվեց։ Չորս փաստ, և հաջորդ կապի խնդիրը տևում է րոպեներ, ոչ թե կեսօր։