MySQL localhost праз VPN: гэта ўсё яшчэ лакальны працэс
База даных, якую праграма называе localhost, знаходзіцца на серверы, а не на вашым ноўтбуку. Выкарыстайце прыватны слухач або SSH-перадачу, потым прымусьце кліент працаваць праз TCP.
Праграма на офісным серверы падключаецца да 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 кліент MySQL, якому далі localhost, па змаўчанні выбірае 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 і аўтэнтыфікацыю базы даных асобна ў нататках, бо няўдача ў адной выглядае як няўдача ў другой з настольнага кліента. Потым выдаліце перадачу, калі скончыце.
Кантрольны спіс заканчваецца, калі вы можаце назваць канцавы пункт, пратакол кліента, адрас крыніцы, які ўбачыў сервер, і дазвол, які гэта дазволіў. Чатыры факты, і наступная праблема са злучэннем займае хвіліны замест паўдня.