Невозможно подключиться удаленно после смены порта - Mongodb - PullRequest
1 голос
/ 28 мая 2020

У меня виртуальная машина Ubuntu 18.04, работающая на GCP, и у меня проблема при удаленном подключении после изменения порта по умолчанию на Mongodb

После установки на Mongodb я выполнил несколько шагов, чтобы включить удаленный доступ на порт по умолчанию в файл /etc/mongodb.conf изменил bindIP на 0.0.0.0 и открыл порт по умолчанию на брандмауэре GCP, и я смог подключиться к Mongodb.

Но я хочу изменить переключатель порта Mongodb по умолчанию с 27017, например, на: 38018 Я изменил порт в /etc/mongodb.conf с 27017 на 38018, перезапустил службу mon go и открыл новый порт на брандмауэре GCP.

После изменения порта я могу подключиться с терминала с помощью следующей команды

mongo --port 38018 -u "user" -p "pass" --authenticationDatabase "admin"

Но когда я пытаюсь подключиться извне через новый порт с mon go compass соединение отклонено, чего мне здесь не хватает?

Также я проверил, работает ли mon go на новом порте с

sudo netstat -tulpn | grep 38018

I получите следующее сообщение:

tcp        0      0 0.0.0.0:38018           0.0.0.0:*               LISTEN      6644/mongod
  1. Ubuntu 18.04.4 LTS
  2. mongod --version db version v4.2.7
  3. UFW inactive

Вот мой файл конфигурации mon go

    # for documentation of all options, see:
#   http://docs.mongodb.org/manual/reference/configuration-options/

# Where and how to store data.
storage:
  dbPath: /var/lib/mongodb
  journal:
    enabled: true
#  engine:
#  mmapv1:
#  wiredTiger:

# where to write logging data.
systemLog:
  destination: file
  logAppend: true
  path: /var/log/mongodb/mongod.log

# network interfaces
net:
  port: 38018
  bindIp: 0.0.0.0


# how the process runs
processManagement:
  timeZoneInfo: /usr/share/zoneinfo

security:
    authorization: enabled

#operationProfiling:

#replication:

#sharding:

## Enterprise-Only Options:

#auditLog:

#snmp:

Я выполняю следующую команду, поскольку @YasBES сказал

mongod -f your_config_file.conf

и перезапустил процесс mon go, процесс не удалось запустить

После проверки журнала я обнаружил эту ошибку Не удалось запустить WiredT iger под любой версией совместимости.

И я нашел следующую команду, чтобы исправить ошибку

sudo chown -R mongodb:mongodb /var/lib/mongodb/

Затем я удалил 27017 .sock файл

sudo rm /tmp/mongodb-27017.sock

и дал правильный право собственности на вновь созданный файл

sudo chown mongodb:mongodb mongodb-38018.sock

после выполнения этих команд процесс успешно запустился, когда я смотрю mongod.log, я получил эти сообщения

2020-05-28T17:13:06.807+0000 I  SHARDING [initandlisten] Marking collection local.startup_log as collection version: <unsharded>
2020-05-28T17:13:06.807+0000 I  FTDC     [initandlisten] Initializing full-time diagnostic data capture with directory '/var/lib/mongodb/diagnostic.data'
2020-05-28T17:13:06.811+0000 I  SHARDING [LogicalSessionCacheRefresh] Marking collection config.system.sessions as collection version: <unsharded>
2020-05-28T17:13:06.812+0000 I  SHARDING [LogicalSessionCacheReap] Marking collection config.transactions as collection version: <unsharded>
2020-05-28T17:13:06.812+0000 I  NETWORK  [listener] Listening on /tmp/mongodb-38018.sock
2020-05-28T17:13:06.812+0000 I  NETWORK  [listener] Listening on 0.0.0.0
2020-05-28T17:13:06.812+0000 I  NETWORK  [listener] waiting for connections on port 38018
2020-05-28T17:13:07.003+0000 I  SHARDING [ftdc] Marking collection local.oplog.rs as collection version: <unsharded>

Теперь процесс запускается и он говорит, что прослушивает 38018, но по-прежнему не может подключиться удаленно

2020-05-28T17:13:06.812+0000 I  NETWORK  [listener] Listening on 0.0.0.0
2020-05-28T17:13:06.812+0000 I  NETWORK  [listener] waiting for connections on port 38018

1 Ответ

0 голосов
/ 17 июня 2020

После некоторого времени исследований я пришел к решению протестировать ту же настройку в облаке Azure с той же версией Mon go, конфигурация как на GCP.

После изменения порта mon go по умолчанию с 27017 на 38018 я открыл брандмауэр на Azure с новым портом 38018, и удаленное соединение было установлено.

Это момент, когда Я обнаружил, что что-то не так с переадресацией портов на GCP.

Я использовал GCP, и я делал много переадресации для других машин и других служб, но это было странно.

Я пробовал несколько разных типов пересылки с разными приоритетами диапазонов IP-адресов и т.д. протокол и порты 38018 tcp / udp.

...