Установка Vmware-tools на debian 8.5

Добрый день, коллеги!

При установке vmware-tools на debian 8.5 есть маленькая хитрость - перед их установкой необходимо установить gcc и make, которых самих по себе в актуальном репозитории нет.

Поэтому перед запуском скрипта vmware нужно выполнить
root@debian:~#apt-get install build-essential

Не забудьте перед этим настроить сеть или примонтировать установочный диск!

Далее устанавливаем всё как обычно:

1. В консоли vmware выбираем guest -> Install/Upgrade VMWare Tools
2. В консоли VM Выполняем mkdir /mnt/cdrom
3. mount /dev/cdrom /mnt/cdrom
4. tar xvzf /mnt/cdrom/VMwareTools-*
5. cd vmware-tools-distrib/
6. ./vmware-install.pl

В самом начале установки, на вопрос "Действительно ли вы хотите установить VMWare Tools вместо  open-vm-tools отвечаем "Yes".
Далее, в принципе, можно все параметры оставить "По умолчанию".

Выбор именно нативных VMWare Tools обусловлен тем, что при использовании open-vm-tools не срабатывает кастомизация машин при клонировании или переносе.

Profit!

Доступ к внутреннему ресурсу через внешний ip-адрес (На примере MikroTik) [Решено]

Добрый день, коллеги!

Недавно появилась достаточно простая задача, с которой по какой-то причине не справился мой напарник- обеспечить доступ к локальному ресурсу сети через внешний ip.

Суть в следующем:
Есть mikrotik, который выполняет роль шлюза. На нём настроен внешний ip, NAT для некоторых ресурсов и прочие плюшки.
Есть локальная машина с адресом 192.168.0.99
Есть внутренний ресурс по адресу, скажем, 192.168.0.25 и порт 8080.
На этот ресурс проброшен NAT с внешним адресом 10.20.30.40 и порт 32154.
При доступе извне - ресурс доступен и всё прекрасно работает, но при попытке зайти на 10.20.30.40:32154 из внутренней сети получаем таймаут соединения или что-то подобное.

Почему так происходит? Да всё просто:
1 шаг: Исходная машина отправляет запрос на внешний адрес. Пакет имеет заголовок "src-address 192.168.0.99" и "dst-address 10.20.30.40"
2 шаг: Шлюз перенаправляет данный пакет на внутренний ресурс. Заголовки меняются на "src-address 192.168.0.99" и "dst-address 192.168.0.25".
3 шаг: Ресурс получает этот пакет и, для установки соединения, отвечает на него. Но отвечает не через шлюз (Как изначально был получен пакет), а напрямую, в обход NAT, так как адрес на который нужно отправить ответ находится в одной с ним подсети.
4 шаг: Исходная машина получает ответ от запрашиваемого ресурса. Но поскольку ответ ожидается от шлюза, а ответ пришёл от другого адреса - пакет просто отбрасывается. В итоге соединение не устанавливается.

Примерная схема:



Для того чтобы целевой ресурс отвечал тем же маршрутом (То есть через шлюз/маршрутизатор) необходимо включить маскарадинг (Masquerade) для пакетов из локальной сети. Маскарадинг (Если в двух словах) это подмена src ip адреса в заголовке пакета на ip устройства, которое выполняет перенаправление.
То есть, на шаге 2 src-address будет изменён на 10.20.30.40.

Итак, у нас на MikroTik уже настроено одно правило NAT:

• Chain: dstnat
• Dst. Address: 10.20.30.40
• Protocol: 6 (tcp)
• Dst. Port: 32154
• Action: dst-nat
• To Addresses: 192.168.0.25
• To Ports: 8080

Для настройки доступа изнутри по внешнему адресу добавим ещё одно правило NAT:

•  Chain: srcnat
• Src. Addresses: 192.168.0.0/24 (Правило работает для всей внутренней подсети)
• Dst. Addresses: 192.168.0.25 (Только для пакетов с этим целевым адресом)
• Protocol: 6 (tcp)
• Dst. Port: 8080 (Для пакетов отправляемых на этот порт. Внимание! Указывается внутренний порт!)
• Action: masquerade

Сохраняем, profit!

Теперь наш шлюз выполняет подмену ip адреса и ответы от целевого ресурса вернутся нужным нам маршрутом. Схема будет выглядеть так:


Теперь всё работает. Всем бобра и плюшек.

Не могу загрузить файлы в каталог vcloud director [РЕШЕНО]

Загрузка media в каталог организации в среде vcloud director отваливатеся со статусом failed при подключении извне.
При подключении из той же подсети, где развёрнут сервер VCD загрузка работает.

Для понимания процесса пришлось сниффать пакеты через WireShark. Оказывается, если в настройках VCD не указать внешний адрес (Тот что за NAT), неважно какой, доменное имя или ip - в качестве адреса для загрузки media будет использоваться внутренний ip сервера. Соответственно, из внешней сети мы до него никак не достучимся.

Связано это с тем, что для загрузки файлов используется JRE апплет, который взаимодействует с VCD через его API, а не через WEB-службу.

Решение:
Заходим в VmWare vCloud Director
Переходим на вкладку System -> Administration -> Public Addresses
Здесь обязательно нужно указать внешний адрес VCD в строке "vCloud Director secure public REST API base URL"

Обратите внимание! Подключение идёт через HTTPS, поэтому в следующей строке обязательно нужно указать сертификат, выданный на данный адрес, иначе загрузка работать всё равно не будет.

Profit!