MySQL localhost caur VPN: tas joprojām nozīmē vietējo procesu

Lietotne uz biroja servera savienojas ar MySQL adresē localhost, jūs nokopējat šo resursdatora nosaukumu galddatora klientā, un savienojums vai nu neizdodas, vai atver citu datubāzi. VPN neko nemainīja vārda nozīmē: localhost joprojām apzīmē mašīnu, kurā darbojas klients. VPN pārvietoja paketes, nevis saskarnes. Izlemiet, kuru galapunktu portatīvajam jāsasniedz, pirms aiztiecat maršrutu.

1. solis: izlemiet, kuru galapunktu portatīvajam jāsasniedz

Abi risinājumi ir likumīgi un atbild uz dažādiem jautājumiem. Tieša piekļuve nozīmē, ka datubāze klausās privātā adresē, ko sasniedz tunelis, un portatīvais savienojas ar šo adresi. Pāradresēta piekļuve nozīmē, ka datubāze paliek uz loopback un SSH sesija pārnes portu uz jūsu mašīnu. Izvēlieties vienu apzināti, jo to sajaukšana rada savienojumu, kas darbojas nepareiza iemesla dēļ.

Tiešai piekļuvei iegūstiet paša datubāzes resursdatora privāto nosaukumu vai adresi un tā portu no tā, kas to pārvalda. VPN vārtejas adrese nav datubāzes adrese, ja vien tā nav tā pati mašīna. Pēc tam pārliecinieties, ka klausītājs patiešām ir piesaistīts šai saskarnei, jo maršruts uz saskarni neizveido uz tās klausītāju.

2. solis: pāradresējiet portu tikai tad, ja klausītājs paliek vietējs

Ja datubāzei jāpaliek tikai uz loopback, pāradresējiet to caur SSH un arī vietējo galu piesaistiet loopback. Piesaistes adrese kreisajā pusē pieder jūsu portatīvajam; mērķis labajā pusē tiek interpretēts no SSH servera puses, kā apraksta OpenSSH uzziņa. Šo divu lomu samainīšana ir ierastais iemesls, kāpēc pāradresācija šķietami darbojas, bet nekam nepievienojas.

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

Ja SSH nonāk uz lēciena resursdatora, nevis datubāzes resursdatora, labās puses loopback attiecas uz lēciena resursdatoru, un mērķis jāmaina uz adresi, ko šis resursdators sasniedz. ExitOnForwardFailure uztver pāradresācijas izveides neveiksmi, bet nepierāda, ka vēlākie savienojumi ar mērķi izdosies. Turiet resursdatora atslēgas pārbaudi ieslēgtu un nepiedāvājiet pāradresācijas portu visam savam LAN, piesaistot to visām saskarnēm.

Apstājieties, ja datubāzei jāpaliek tikai uz loopback un jūs nevarat izmantot SSH. Tad tieša piekļuve ir nepareizais risinājums, nevis konfigurācija, kas jāuzspiež.

3. solis: piespiediet klientu lietot TCP

Unix sistēmā MySQL klients, kam dots localhost, pēc noklusējuma izvēlas Unix ligzdu, tāpēc, mainot tikai portu, tas var palikt meklējam ligzdu, kam nav nekāda sakara ar jūsu pāradresāciju. Izmantojiet skaidru TCP protokolu un loopback adresi, lai klients atvērtu savienojumu ar jūsu pāradresācijas portu.

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

Paroles opcija bez vērtības jautā, nevis ievieto noslēpumu komandrindā, un tas ir ieradums, ko ir vērts saglabāt. Citiem rīkiem ir savs slēdzis šai pašai atšķirībai, un daži draiveri arī localhost apstrādā īpaši. Pārbaudiet, ko dara jūsu klients, nevis pieņemiet, ka karodziņš tika pārnests. Datubāzes kontam arī vajadzīgas tiesības, kas atbilst avotam, ko redz serveris, un tas ir pāradresācijas resursdators, nevis jūsu portatīvais.

Apstājieties, ja rīku nevar piespiest lietot TCP. Tad izmantojiet citu klientu vai tiešu piekļuvi privātajam klausītājam.

4. solis: pierādiet, kuru galapunktu jūs faktiski sasniedzāt

Pajautājiet serverim, ko tas uzskata par savienojumu. Resursdatora nosaukuma, porta un ligzdas mainīgie pasaka, vai atnācāt pa TCP un kurš klausītājs atbildēja, un savienojumu saraksts rāda avota adresi, ko serveris reģistrēja. Šis pierādījums ir noderīgāks par vēl vienu maršruta maiņu.

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

Pierakstiet, kuru galapunktu izmēģinājāt: vietējo Unix ligzdu, savu pāradresācijas portu vai privāto klausītāju. Šīm trim neveiksmēm ir dažādi labojumi, un VPN maršruta maiņa, kamēr klients vēl runā ar nepareizo localhost, ir veltīgs darbs. Pierakstos turiet atsevišķi arī SSH autentifikāciju un datubāzes autentifikāciju, jo vienas neveiksme no galddatora klienta izskatās kā otras neveiksme. Pēc tam noņemiet pāradresāciju, kad esat pabeidzis.

Saraksts beidzas, kad varat nosaukt galapunktu, klienta protokolu, avota adresi, ko serveris redzēja, un atļauju, kas to pieļāva. Četri fakti, un nākamā savienojuma problēma aizņem minūtes, nevis pēcpusdienu.