среда, 16 декабря 2015 г.

Учим apt качать с наиболее доступного зеркала.

Исходные данные: 
Xubuntu 14.04 (64 разряда).

Вдруг стал недоступен ru.archive.ubuntu.com... А надо, срочно. Когда-то давно в Дебианах была система зеркал. Она никуда не делась Смотрим ответ №85. И подгоняем его под свои реалии. Эти строки вставляем в самое начало /etc/apt/sources.list

deb mirror://mirrors.ubuntu.com/mirrors.txt trusty main restricted universe multiverse
deb mirror://mirrors.ubuntu.com/mirrors.txt trusty-updates main restricted universe multiverse
deb mirror://mirrors.ubuntu.com/mirrors.txt trusty-backports main restricted universe multiverse
deb mirror://mirrors.ubuntu.com/mirrors.txt trusty-security main restricted universe multiverse
и закомментариваем всякое упоминание ru.archive.ubuntu.com
Делаем apt-get update и продолжаем прерванное ранее.

пятница, 11 декабря 2015 г.

Блокировка url, squid, firefox и chromium


Сначала было слово

    Поступило распоряжение верховного руководства заблокировать ряд забугорных сервисов. Блокировать по ip как-то коряво, никто не несет никаких обязательств в части смены оных ip-шников, так же, в случае попадания в список каких-либо не крупных сервисов, можно нарваться на ip, расшаренный между несколькими, а то и многими сайтами. Стало быть по url. Тут кроме родного и близкого дедушки squid-а и ухватить-то некого... Его и ухватим. В сети примерно 160 ltsp-шных бездисковых станций, штук 40 Xubuntu, штук 50 Win... разномастных, пара Маков, штук 30 Андроидов. Попробуем максимально принудительно прописать им путь до прокси, потом закроем прямую дорогу.

Полезные ссылки в части принудительного насаждения прокси
http://en.wikipedia.org/wiki/Proxy_auto-config
http://wiki.squid-cache.org/SquidFaq/ConfiguringBrowsers
http://tdkare.ru/sysadmin/index.php/Chromium-browser
http://technet.microsoft.com/ru-ru/library/cc985352.aspx
и самое ценное
http://askubuntu.com/questions/263567/set-web-proxy-using-pac-file-url-in-lubuntu

Делаем

Сначала анонсируем прокси обоими возможными способами. dnsmasq обзавелся в своем конфиге вот такой строкой.
# wpad option
dhcp-option=252,http://wpad/wpad.pac

Местный apache был дообозван именем wpad и в корень ему был записан скрипт с именем wpad.dat И его же обозвали (прилинковали) как wpad.pac
В /etc/apache2/mods-available/mime.conf добавлена строчка
AddType application/x-ns-proxy-autoconfig .pac

Содержимое скрипта тривиально.

// Some ideas by Oskar Pearson and the Internet Solution (http://www.is.co.za)

function FindProxyForURL(url, host)
{
    //If they have only specified a hostname, go directly.
    if (isPlainHostName(host))
            return "DIRECT";

    //Connect directly to our domains (for Important News www)
    if (dnsDomainIs( host,"okgvv.loc"))
        return "DIRECT";
    // See next!
    if (dnsDomainIs( host,"www.monitor.kuzdrav.ru"))
        return "PROXY proxy:3128";
    // Parus use 81 port
    if (dnsDomainIs( host,"monitor.kuzdrav.ru"))

        return "DIRECT";

    //Vipnet client's direct path
    if (isInNet(host, "11.0.0.174", "255.255.255.255"))
        return "DIRECT";

    //Local IPs
    if (isInNet(host, "10.0.0.0", "255.255.254.0"))
        return "DIRECT";
    else
            return "PROXY proxy:3128";
}

Это было авто, для всех кто готов слушать и внимать. Всем "своим" еще более принудительно... 

На клиентах

На всех linux-ах, включая и ltsp пропишем для всех простых клиентов (midori например) в /etc/evironment

http_proxy=http://proxy:3128/
https_proxy=http://proxy:3128/
ftp_proxy=http://proxy:3128/
no_proxy="localhost,127.0.0.1,10.0.0.0/23"
HTTP_PROXY=http://proxy:3128/
HTTPS_PROXY=http://proxy:3128/
FTP_PROXY=http://proxy:3128/
NO_PROXY="localhost,127.0.0.1,10.0.0.0/23"

Для Хромиума в файле /etc/chromium-browser/default пропишем
CHROMIUM_FLAGS="--proxy-pac-url=http://wpad/wpad.dat --enable-plugins"



Для Ф-фокса в /etc/firefox/syspref.js в хвост
lockPref("network.proxy.autoconfig_url", "http://wpad/wpad.dat");
lockPref("network.proxy.type", 2);



если почитать about:config в Мозилле, много чего захочется добавить следом, например для бездисковых клиентов.

lockPref("browser.cache.disk.filesystem_reported", 1);
lockPref("browser.cache.disk.capacity", 35840);
lockPref("browser.cache.disk.smart_size.enabled", false);
lockPref("browser.startup.homepage", "http://yandex.ru");
pref("browser.search.defaultenginename","Яндекс");
pref("browser.search.order.2","Яндекс");


и в /etc/apt/apt.conf (сам файл скорее всего нужно создать).
Acquire::http::proxy "http://proxy:3128/";
Acquire::https::proxy "http://proxy:3128/";
Acquire::ftp::proxy "http://proxy:3128/";
Acquire::::Proxy "true";



В Windows достаточно прописать "автоматическое определение настроек". С ними сильно церемониться не будем (в этом лесу законы не писаны) а просто перекроем прямой роутинг (http+https) на пограничном шлюзе... Сами приползут :-)


Множественные черные списки в squid

    Родное государство постоянно заботится о безопасности госслужащих и госучреждений, но не путем создания отечественного ПО с дырками в сторону структур бывшего КГБ, а путем запретов использования всего иного прочего, с дырками в госдеп. Стало быть задачи ограничения всякого рода свобод все разнообразнее... При выполнении очередной указивки возникла потребность сделать несколько черных списков, так чтоб делить сотрудников по сортам, рангам и степени приближенности... Предыдущий вариант содержал только 1 черный список. Вот его модификация. Новое содержимое выделено голубым.

acl localnet src 10.0.0.0/23
acl onlywhite src "/etc/squid3/onlywhite.ip"
acl onlyblack src "/etc/squid3/onlyblack.ip"
acl black2 src "/etc/squid3/black2.ip"
acl black3 src "/etc/squid3/black3.ip"
.
.
acl blackn src "/etc/squid3/blackn.ip"
acl whitelist url_regex -i "/etc/squid3/whitelist.url"
acl blacklist url_regex -i "/etc/squid3/blacklist.url"
acl blacklist2 url_regex -i "/etc/squid3/blacklist2.url"
acl blacklist3 url_regex -i "/etc/squid3/blacklist3.url"
.
.
acl blacklistn url_regex -i "/etc/squid3/blacklistn.url"


Любой ip-адрес может быть встречен в каждом из списков

И ограничительная часть будет выглядеть так
http_access deny onlyblack blacklist
http_access deny black2 blacklist2
http_access deny black3 blacklist3
.
.
http_access deny blackn blacklistn
http_access deny onlywhite !whitelist
http_access allow localnet

Получается в первом списке у нас соц. сети, во втором Google и Whatsapp, в третьем youtube, ну и так далее. Попавшие во все списки вынуждены заниматься на работе только работой...

среда, 23 сентября 2015 г.

Плановое обновление LTSP-клиентов

Исходные данные: 

Xubuntu 14.04 (32-LTSP-client и сервер 64 разряда).

Дано: LTSP-Сервер к которому подключено примерно 150 бездисковых станций по принципу fat-client. Нужно обновить образ в соответствии с текушим состоянием репозитариев. Собственно сервер мы не трогаем.

Заходим "внутрь"
ltsp-chroot -m
Обновляемся
apt-get update
apt-get upgrade
apt-get autoremove
Выходим из чрута
И пересоздаем образ
ltsp-update-image
ltsp-update-kernels
Все, можно перегружать клиентов.

среда, 29 июля 2015 г.

Замена HDD или компьютера целиком (перенос на другой диск) Xubuntu 14.04

При выполнении простых повседневных вещей хочется избежать глупых ошибок, по этому попробую формализовать весь процесс до тупого набора простых действий.
   Итак: 


Берем новый комп и подключаем к нему диск со старого компа (который нужно переписать). 


Грузимся с флешки или CD-образа.

Разбираемся с дисками (fdisk -l /dev/sda и fdisk -l /dev/sdb нам в помощь). Будем 
полагать что sda - новый, а sdb старый диск, так обычно и бывает. 

Заводим иерархию (в предположении что у нас на старом диске есть / и /home) 
/mnt/old/root и /mnt/old/home.

Монтируем старый диск (это избавит его от случайного повреждения, большинство системных программ предупредит о попытке что-то сделать с примонтированным диском). 
mount /dev/sdb1 /mnt/old/root и mount /dev/sdb3 /mnt/old/home.

Разбиваем новый диск. Обычно первый раздел примерно 20-30Г под /, второй swap (2 объема памяти), третий - остатки под /home. 

Создаем файловые системы и своп, даем им сразу приличиствующие имена.
mkfs.ext4 -L rootfs /dev/sda1 
mkfs.ext4 -L homefs /dev/sda3 
mkswap -L swapfs /dev/sda2

Монтируем новый /  
mount /dev/sda1 /mnt/new

Копируем рутовый раздел. 
cd /mnt/old/root 
tar c . | ( cd /mnt/new ; tar xvf - )

Удаляем в новом разделе /media/* - это нужно, поскольку тут обычно используются расширенные атрибуты (acl) которые мы при копировании перетаскивать не стали, при работе fusefs все что нужно создастся само, если мы не удалим старые каталоги, то fusefs работать не будет (не открываются флешки). 
rm -rf /mnt/new/media/*

На всякий случай ревизируем, что там скопировалось в lost+found, если что-то  там есть, скорее всего, это нужно стереть и хорошо подумать откуда оно взялось...

Монтируем новый /home. 
mount /dev/sda3 /mnt/new/home

И копируем содержимое. 
cd /mnt/old/home 
tar c . | ( cd /mnt/new/home ; tar xvf - )

Подключаем /dev, /sys и /proc  к новой файловой системе. 
mount -B /dev /mnt/new/dev 
mount -B /proc /mnt/new/proc

mount -B /sys /mnt/new/sys

Чрутимся в новую ФС. 
chroot /mnt/new

Правим /etc/fstab.  Вместо UUID=бла-бла-бла пишем LABEL=rootfs и LABEL=homefs и LABEL=swapfs  соответственно. Если грызут сомнения в части дубляжных имен, хорошая идея на будущее rootfs20150730.  

И ставим загрузчик 
grub-install /dev/sda 
update-grub

poweroff и снимаем старый диск. Все!


Крайне полезно после загрузки с нового диска запустить apt-get update и apt-get upgrade, grub пожалуется на отсутствующий старый диск и позволит выбрать новый (/dev/sda).

Дополнение от 20 сентября 2016

  Копирование большого количества файлов, особенно возобновление оного после какой-либо неудачи удобно делать не tar-ом, а rsync-ом
rsync -aHAX /mnt/old/home/ /mnt/new/home/
  Атрибуты сохраняются, в том числе расширенные. Запомнить опять же легко (на великом и могучем), если хочется наглядности - добавить буковку "v". И вот еще что - если копируем огромные объемы (от 2Тб при условии мелких файлов, а не фильмов) нужно иметь или достаточное количество оперативной памяти (8Г - хороший выбор), или подключать swap, иначе имеем шанс после 10 часов ожидания получить выпадение в ошибку, это и tar и rsync примерно одинаково.


воскресенье, 26 июля 2015 г.

Про HDMI, DVI, старенькую NVIDIA, и звук в Kubuntu

  Дело было так. Была у меня старенькая карта, которая служила верой правдой, замечаний по службе не имела. В качестве монитора (кабелем DVI-HDMI) к ней был подключен большой - большой телевизор LG (второй канал не использовался) и все это работало под Kubuntu 12.x (не помню она апрельская или февральская). Карточка была вот такая:
  Просто замечательная. не грелась и не шумела. Звук она передавать в принципе, похоже, не умела и он был проброшен отдельным простым аналоговым кабелем.
  Карточка сдохла. Стала она быстро нагреваться и всякие чудеса рисовать. Нашел я у себя такую же примерно старую EN9400GT, она с одним выходом во всех видах HDMI, DVI, VGA. Поставил, со звуком ничего не делал, но он магическим образом исчез! Все настройки телевизора перепроверил, выяснил (путем подтыкания наушников) что в кабеле он есть, а упрямый телеящик его не слышит - видать что-то такое передает "новая" карточка по HDMI - интерфейсу, что дает основания считать телевизору что звук идет то же по HDMI! По ходу пьесы вот еще какое замечание. Пробовал я использовать VGA интерфейс, вход в телевизоре есть. И звук есть. Но! Моим не самым острым зрением видна существенная потеря качества. Для HD аналог уже не годится...
  Углубление в теорию дало вот что. Карты бывают, как минимум, трех поколений. Первые, самые старые. Ничего про звук не знают и в HDMI/DVI гонят соответствующий признак. Телевизор понимает что надо включать или аналог, или внешний SPDIF, который обычно на оптоволокне. К этому поколению была отнесена моя старая, сдохшая карточка. Моя "новая" карточка относится к следующему, среднему поколению. Они имеют едва приметный разъем для подключения SPDIF прям внутри компа с материнки, и транслируют его в HDMI или DVI в безусловном порядке. Ну и третья группа, о них везде и прописано, что при установке NVIDIA-шного драйвера появляется еще и звуковое устройство, которое надо прописать в настройках как выходное для звука.
   Ну вот, все встало на места, надо победить проводок. При помощи китайского мультиметра выясняем, что единственный разъем на видеокарте имеет верхнюю ножку намертво проброшенную на "массу", стало быть нижняя - SPDIF-вход. Ну а на материнке все прописано в описании, на фото использован кабель от CD-ROM.

  Реально нужен один проводок, у нас он черный. Подойдет какой угодно. +5 не используется и висит не одетым на стороне видеокарты, масса лишней не будет. Никаких настроек не потребовалось. Материнка - P5KC - старая... Вот такая практическая работа. 

пятница, 3 июля 2015 г.

Сохранение (backup) клиентских виртуальных машин.

Исходные данные: 
Xubuntu 14.04 (64 разряда + Windows всех мастей под VirtualBox).

Есть много (штук примерно 20) компьютеров под Xubuntu, на которых установлен VirtualBox и запускается виртуальная машина. Конечно винды, конечно с комплектом каких-то мерзких, совершенно не переносимых программ для формирования налоговой отчетности и т.п. Этот зоопарк (виртуалки) надо периодически сохранять. Бэкапить саму Ксубунту смысла никакого, ее быстрее, случись чего, заново поставить. Все полезные документы исключительно на серверах (или внутри ВМ...).  Всякие хорошие и полезные программы типа bacula ориентированы на копирование серверов и несколько избыточны в плане возможностей (ну и не слишком в плане удобства и дружелюбия). Требование примерно такие. 

  1. Все хранится в дереве файлов. Никаких доп. баз данных.
  2. Формат хранения не требует никаких средств кроме общесистемных для извлечения архивной копии.
  3. Запускается на клиенте, пишет на сервер.
  4. Желательно кроме основной копии на сервере (одной) иметь еще несколько архивных копий на самом клиенте.
  5. Ну и простота, для прозрачности процесса.

Как и что. 

В качестве хранилища rcyncd, делаем модуль в режиме write-only, это защитит копию от всякого рода рисков. Все клиенты в единое дерево, идентификация по имени машины и клиента, чтоб заранее в дереве ничего не создавать. В качестве средства создания локальной копии tar и logrotate. Запуск в "околоручном" режиме при попытке выхода из сеанса. Вот с этого места и начнем.


В xfce4 выход из сеанса реализован запуском xfce4-session-logout. Живет она где-то в /usr/bin. Если взять свой скриптик, поименовать его так же и положить в /usr/local/bin, получим его вызов стандартными средствами при попытке выхода из сеанса или выключения компьютера. 

Ну вот он и есть /usr/local/bin/xfce4-session-logout:

#! /bin/bash

###
# Пре-назначения. В конфиг файле можно все переназначить
FLAG=$HOME/.need2backupvm
VMDIR=$HOME/.Virtulbox\ VMs
VMNAME='Mint\ 17'
BASE='root@192.168.20.1::onecopy'
NROTATE=5
LOCALSTORE=$HOME/.local/share/vb_backup

CONFIG=$HOME/.config/vmbackupconfig
SYSTEMPROG=/usr/bin/xfce4-session-logout
COPY=/usr/local/bin/copy_vm.bash

# Config
test -r ${CONFIG} && . ${CONFIG}

# Check flag
if [ ! -r $FLAG ] ; then
  $SYSTEMPROG
  exit 0
fi
###

# Make selection
res=`zenity --list --radiolist \
       --title="Резервная копия виртуальной машины" \
       --text="Настало время скопировать ВМ, выберете вариант. Копирование занимает примерно час" \
       --column="Выбор" --column="parametr" --column="Что дальше" \
       TRUE "bcppower" "Запуститить копирование, по окончании выключить" \
       FALSE "bcponly" "Запустить копирование, по окончании не выключать" \
       FALSE "sys" "Отложить копирование (вызвать системый диалог)" \
       --hide-column=2 --print-column="2"`
CASE=$?

case $CASE in
0)
  case ${res} in
  sys)
  $SYSTEMPROG
  ;;
  *)
notify-send -i info Information "Резервное копирование запущено"
# Make backup here
#
# $1 - имя ВМ для остановки
# $2 - каталог, который мы копируем
# $3 - база к которой будет добавлено $DEST на сервере
# в виде root@192.168.20.1::onecopy
# $4 - Локальное хранилище                                                      
# $5 - количество копий 

$COPY "$VMNAME" "$VMDIR" $BASE "$LOCALSTORE" "$NROTATE" | logger
notify-send -i info Information "Резервное копирование завершено"
rm -f $FLAG
if [[ $res == 'bcppower' ]] ; then
 $SYSTEMPROG --halt 
fi
  ;;
  esac
  ;;
-1)
          zenity --error --text="Внутреняя ошибка 001."
  ;&
    1)
  $SYSTEMPROG
  ;;

esac

exit 0

Задача скрипта совсем не сложная - проверить флажок (пора - не пора, ставим его по крону с нужной периодичностью), получить добро у юзера и запустить вторую часть.

Часть вторая, /usr/local/bin/copy_vm.bash:

#! /bin/bash
#
# $1 - имя ВМ для остановки
# $2 - каталог, который мы копируем
# $3 - база к которой будет добавлено $DEST на сервере
# в виде root@192.168.20.1::onecopy
# $4 - Локальное хранилище
# $5 - количество копий

DEST=`hostname -s`
DEST=$DEST-$USER
LIST=`VBoxManage list runningvms |grep "$1" | cut -d'"' -f2`
LRSTATE=$HOME/.cache/logrotate/vm_copy
LRCONF=$HOME/.config/vm_copy-logrotate
TARFILE=${4}/vm.tar

# Выключаем нужную ВМ
if [[ -n $LIST ]] ; then
        VBoxManage controlvm "$LIST" savestate 2>&1  | logger
fi

# Копия на сервер
rsync -a -H -x -o --numeric-ids --del -A "$2" ${3}/$DEST/

# Локальная копия (архив)
# Делаем конфиг для logrotate
echo "$TARFILE {
  rotate $5
  compress
}" > ${LRCONF}

# Каталог нодобно заранее создать...
mkdir -p ${4}

# logrotate
touch "$LRSTATE"
test -r ${TARFILE} && logrotate -f -s "$LRSTATE" "$LRCONF"

# Тарим
tar cf ${TARFILE} "$2"

Тут и пояснять-то нечего.

На сервере (там стоит не слишком свежая Гента, но отличий почти нет). Фрагмент конфига. /etc/rsyncd.conf

# This line is required by the /etc/init.d/rsyncd script
pid file = /run/rsyncd.pid

# Global
use chroot = yes
address = 192.168.20.1

[onecopy]
path = /mnt/storage/onecopy
comment = Client backups
read only = false
write only = true
uid = root
list = false
ignore nonreadable
dont compress = *.gz *.tgz *.tar.gz *.zip *.7z *.rar *.deb *.bz2 *.iso

Что в итоге?

Во всей получившейся, довольно стройной, системе нет ни единого пароля. Все сделано без подпиливания каких-либо штатных средств. Практически вся нагрузка остается на клиенте, сервер не напрягаем. Путем небольших изменений конфига можно заставить самую последнюю копию хранить на клиенте, а остальные дублировать на сервер (а оно нужно?)
Да, в конфиге ничего интересного:
spec-5@spec-5:~/.config$ less vmbackupconfig 
VMDIR=$HOME/.VirtualBox/Machines
VMNAME='WinXP'
BASE='root@192.168.20.1::onecopy'

В /etc/cron.weekly/vmbcp (имя файла не имеет значения)
#! /bin/bash

# VM backup
DUSER=имя подставить
touch /home/${DUSER}/.need2backupvm
chmod a+rw /home/${DUSER}/.need2backupvm

Последнее изменение 20150826

понедельник, 18 мая 2015 г.

Черный и белый список в squid.

Много материала по настройке ограничений доступа посредством squid-а. Но есть желание задокументировать (пока не забыл) еще один совсем простой способ. Итак, что нам нужно. Сначала допущения. Заворот на прокси-сервер мы тут не рассматриваем, будем только предполагать что сама сеть или запрещает прямой доступ наружу, или заворачивает трафик на прокси и у пользователей нет никаких шансов это дело проскочить (tor, внешние прокси и пр. нас тут не интересуют). Теперь идея. Пользователи разделены на три группы - некое большинство, для которого нет никаких особых ограничений. Белый список (только белый список, совсем жестко). Черный список, их тоже много.

/etc/squid3/squid.conf

Собственно списки и сети. В localnet попадают все пользователи, в том числе и те, которые фигурируют в черном или белом списке.

acl localnet src 10.0.0.0/23
acl onlywhite src "/etc/squid3/onlywhite.ip"
acl onlyblack src "/etc/squid3/onlyblack.ip"
acl whitelist url_regex -i "/etc/squid3/whitelist.url"

acl blacklist url_regex -i "/etc/squid3/blacklist.url"

Стандартный доступ
http_access deny !Safe_ports

# Deny CONNECT to other than secure SSL ports
http_access deny CONNECT !SSL_ports

# Only allow cachemgr access from localhost
http_access allow localnet manager
http_access deny manager

# We strongly recommend the following be uncommented to protect innocent
# web applications running on the proxy server who think the only
# one who can access services on "localhost" is a local user


http_access deny to_localhost

И наши ограничения следом
http_access deny onlyblack blacklist
http_access deny onlywhite !whitelist
http_access allow localnet
# And finally deny all other access to this proxy

http_access deny all

/etc/squid3/onlyblack.ip

10.0.1.0-10.0.1.127

/etc/squid3/blacklist.url

vk\.com
ok\.ru
odnoklassniki\.ru
facebook\.com
\.porn
\.sex

Оставшиеся 2 файла ничего нового нам не добавят, все аналогично.
Появилось предновогоднее дополнение

Сортировка dnsmasq.leases по ip-адресам

Совсем простое дело, но пришлось чуть-чуть повозиться. При наведении порядка в большой сети полезно бывает получить сортированный список назначенных ip. Пример вот:
cat /var/lib/misc/dnsmasq.leases |grep "0\.1\."| sort -V -k3.8,3.11|less
В результате получим.

воскресенье, 19 апреля 2015 г.

Дополнительный NAT при отладке juniper

Не часто, зато регулярно приходится иметь дело со всякими умными железками. Причем решаемые задачи от хрестоматийно простых, до "этого сделать нельзя, но очень надо". Так и в этот раз, после двух- или трехлетнего перерыва нужно сделать конфиг для Juniper SRX-100 (версия "B", который с маленькой памятью). Задача осложнена тем, что нужно заранее сделать и быстро-быстро переставить (больница, режим работы круглосуточный простои крайне не желательны). Нужно делать стенд и отлаживать. Ресурсов для деланья оного стенда нет, можно сгородить только половину от желаемого. С созданием source-nat проблем никаких. В результате имеем подключенный к внутренней сети девайс, который можно использовать в качестве дефолтового шлюза (один из интерфейсов вытолкнули наружу, правда через "лишний чужой" NAT). Прописали его на одном компе и погоняли. Все гладко. Надо настроить destination-nat, там полтора десятка разных пробросов, их, собственно и хочется погонять. Условием работы desination nat является использование того-же устройства в качестве default gateway (пакеты приходят с мира, имея настоящий обратный адрес, на который и уходят ответы сервера). Поскольку все те сервисы, которые надобно отладить, используют совершенно другой ip в качестве дефолта, отладка остановилась. Единственный выход - сделать доп. трансляцию адресов с тем, чтоб source-address в пакете был заменен на адрес интерфейса маршрутизатора. Вот этот конфиг, вернее его кусочки и приведем. На самом деле все оказалось не просто, а очень просто.
Раздел system, тут ничего интересного, приведен полностью на всякий случай.

version 11.2R4.3;
system {
    host-name gw1;
    time-zone Asia/Bangkok;
    root-authentication {
        encrypted-password "онтутбыл"; ## SECRET-DATA
    }
    name-server {
        208.67.222.222;
        208.67.220.220;
        8.8.8.8;
        77.88.8.8;
    }
    services {
        ssh;
        web-management {
            http {
                interface vlan.0;
            }
            https {
                system-generated-certificate;
                interface vlan.0;
            }
        }
    }
    syslog {
        archive size 100k files 3;
        user * {
            any emergency;
        }
        file messages {
            any critical;
            authorization info;
        }
        file interactive-commands {
            interactive-commands error;
        }
    }
    max-configurations-on-flash 5;
    max-configuration-rollbacks 5;
    license {
        autoupdate {
            url https://ae1.juniper.net/junos/key_retrieval;
        }
    }
    ntp {
        peer 10.0.0.3;
    }

}

Интерфейсы, даже вычистим серединку для экономии места. Пока стоит один внешний, все остальное в switching.

interfaces {
    fe-0/0/0 {
        unit 0 {
            family inet {
                address 91.201.11.82/29;
            }
        }
    }
    fe-0/0/1 {
        unit 0 {
            family ethernet-switching {
                vlan {
                    members vlan-trust;
                }
            }
        }
    }

....
    fe-0/0/7 {
        unit 0 {
            family ethernet-switching {
                vlan {
                    members vlan-trust;
                }
            }
        }
    }
    lo0 {
        unit 0 {
            family inet {
                filter {
                    input deny-ssh;
                }
            }
        }
    }
    vlan {
        unit 0 {
            family inet {
                address 10.0.0.26/23;
            }
        }
    }

Роутинг и пр. Так же на всякий случай

}
snmp {
    community public {
        authorization read-only;
    }
}
routing-options {
    static {
        route 0.0.0.0/0 next-hop 91.201.11.81;
    }
}
protocols {
    stp;
}

Адресную книгу и правила firewall приводить нет смысла. А вот и собственно NAT.

    nat {
        source {
            rule-set trust-to-untrust {
                from zone trust;
                to zone untrust;
                rule source-nat-rule {
                    match {
                        source-address 0.0.0.0/0;
                    }
                    then {
                        source-nat {
                            interface;
                        }
                    }
                }
            }
            rule-set untrust-to-trust {
                from zone untrust;
                to zone trust;
                rule source-rule {
                    match {
                        source-address 0.0.0.0/0;
                    }
                    then {
                        source-nat {
                            interface;
                        }
                    }
                }
            }
        }
        destination {
            pool d-rdp2 {
                address 10.0.0.2/32 port 3389;
            }
            rule-set D-NAT {
                from zone untrust;      
                rule rdp2 {             
                    match {             
                        destination-address 91.201.11.82/32;
                        destination-port 3390;
                    }                   
                    then {              
                        destination-nat pool d-rdp2;
                    }                   
                }                       
            }                           
        }                               
    }                                   
    policies {                          
        from-zone trust to-zone untrust {
            policy trust-to-untrust {   
                match {                 
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
        from-zone untrust to-zone trust {
            policy local2-acc {
                match {
                    source-address any;
                    destination-address local2;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
    }
    zones {
        security-zone trust {
            host-inbound-traffic {
                system-services {
                    all;
                }
                protocols {
                    all;
                }
            }
            interfaces {
                vlan.0;
            }
        }
        security-zone untrust {
            interfaces {
                fe-0/0/0.0 {
                    host-inbound-traffic {
                        system-services {
                            ping;
                            ssh;
                        }
                    }
                }
            }
        }
    }
}

Розовым цветом выделен "дополнительный NAT", ради которого вся писанина. Никаких дополнительных policy не нужно! Теперь пакеты прошедшие destination NAT, проходят еще и source NAT, и приходят  на терминальный сервер с 10.0.0.26 (адрес интерфейса), что позволяет потихоньку проверять устанавливаемые правила пробросов не мешая всему остальному.