Juniperобсирание, серия 22

Я уже много раз упоминал, что эти с(т)ранные поделки под названием Juniper SRX годятся разве что только в качестве домашнего роутера. Недавно я изменил своё мнение. Даже в качестве домашнего роутера они тоже не годятся. Но сперва лирическое отступление про то, как устроен NAT в Linux и в Juniper.
В этом казалось бы несложном таинстве присуствует огромная путаница в терминологии, которая пошла ещё со времен первых цисок. В оборот ввели неочевидные понятия наподобие "симметричный NAT", "Full Cone NAT", "address overload", "port overload", "port address translation", "address mapping", "маскарадинг", "перекартирование" и так далее. Причем, в зависимости от контекста эти термины могут означать разное. Поэтому пользоваться ими не хочется.
Далее. Что касается Linux. У него всё максимально просто. Понятия "статический NAT" у него нет. Что, впрочем, не означает что его нельзя реализовать. Можно, причем аж тремя разными способами, два из которых не требуют включения трассировщика (conntrack). А дальше подход простой: если Linux может сохранить исходный номер порта (SRC Port), он его сохраняет. Если не может — берет первый попавшийся незанятый. Количество транслируемых сессий по сути упирается только в объем оперативной памяти под трассировщик соединений и в скорость поиска по хеш-таблицам (деревьям). Если нужно "вынести" какой-то порт внаружу, просто делаешь source-destination NAT "туда-сюда" и всё.
У ждуниперов всё не так. По умолчанию он всегда будет изменять номер Source Port. Зачем? А хрен его знает, потому что может. И чтобы его хоть как-то уговорить этого не делать, нужно чтобы "внешний" адрес обязательно был статическим. Нету? Ты в пролете, чувак, у тебя точно не будет нормально работать SIPs (SIP+TLS) и некоторые WebRTC (включая тот же Telegram).
Далее. Если какой-то внешний адрес уже используется в static nat, то его уже нельзя применять ни в source, ни в destination. А если ты пытаешься делать destination nat ака "проброс портов" снаружи вовнутрь, то Juniper не способен сопоставить встречные входящие и исходящие UDP-пакеты чтобы понять что они относятся к одной и той же сессии. И дальше начинает снова менять номера портов. То есть какое-нибудь RTP-соединение в таком сценарии не заработает: будет "односторонняя слышимость" или вообще тишина.
Получается, что если у тебя дома живёт SIP-телефон (или Asterisk) и ты хочешь для него SIPs, то единственный вариант — покупать у провайдера отдельный "честный" статический IP для него. А если у тебя дома два SIP-телефона? А если кроме телефонов кому-то ещё нужен "проброс портов" (домашний веб-сервер, торренты, хз ещё что)? Где столько белых IP-адресов взять? Что, IPv6? И много вы знаете российских SIP-провайдеров, которые умеют в IPv6? Я чё-то ни одного.
И да. У Juniper-ов для подобных случаев есть механизм под названием "Persistent NAT". Это отдельная (!) таблица в памяти (отдельный трассировщик), при помощи которой отслеживаются исходящие пакетики, и маршрутизатор автоматически организует для них "обратный NAT" на какое-то время (по умолчанию 5 минут). Эдакий костыль, который они позиционируют как раз для решения проблем с VoIP. Звучит интересно, но и тут не всё хорошо.
Во-первых, количество транзитных сессий сразу уменьшается до количества возможных портов, т.е. максимум 64000 на один внешний IP. Ладно, положим что для домашнего применения это не особо страшно. Но во-вторых, для нормальной работы SIP / WebRTC всё равно потребуется STUN-сервер. Потому что мы по-прежнему не знаем какой номер порта Juniper назначит "снаружи" для исходящих пакетов. Впрочем, для случая с динамическим IP-адресом и шифрованным каналом сигнализации это единственно возможная лазейка (либо отказываться от шифрования и включать ALG).
Самое смешное, что всех этих проблем можно было бы избежать и не городить башню из костыльной кости, если просто не менять номер SRC Port при Source NAT. Но это, видимо, было бы слишком просто. Не самурайский путь.
М-дя. Мораль простая: используйте Linux и не тр***йте никому мозг. Персонально я чем дольше работаю с Juniper-ами, тем большее отвращение к ним испытываю. Впрочем, до тех же микротиков даже им ещё есть куда падать.
|
</> |