Main

2019-03-17 Networking-Blog

Лазал я тут по ебею, и неожиданно попался моему взору juniper J 4350, за 5 тыщь вместе с доставкой - погуглил/почитал - по сути своей это софтроутер, по железу ни что иное как обычный четвертый пень в немного необычном конструктиве, унутри сплошной тантал - ломаца можно сказать нечему, за пару баксов с того же ебея можно туда вотнуть проц на 3.8GHz и памяти до 4 гигов, правда заюзать можно только 3.5 ибо i686, ну да не суть и того хватает с головой, вобщем во всех отношениях пиздатый аппарат😊 voip только можно сказать отсутствует, но с этим у жуниреров всегда было никак, есть какието платы пашущие тока с аваевским CM который мне нах не нужен, но с этим я решил смирица приставив сбоку циску с голосовыми портами, ктому же она у меня итак есть, ну и взял я его вобщем.

До него у меня дома роутером была cisco 2851, впринципе никаких проблем с ней небыло - всем хороша, кроме ната - больное место всех бранчевых кошек, торренты нисчадно его насиловали плодя тысячи сессий как я гайки(таймауты) там ни закручивал - всеравно периодически это ушатывало ее сраный процессор от калькулятора ситизен в полку😊 Это тоже от части способствовало покупке жунипера, у него заявлено 225килопакетов/с и 250к сессий на коробку с 2 гигами оперативы и какаято умопомрачительная по цискиным меркам цифра в 10000 новых сессий в секунду😊 у кошки просто 10000 сессий на нате уже проблема, если в секунду это уже пиздец ей в ту же секунду😊 Ну нада думать, калькулятор VS четвертый пень, хоть и селерон там на 2.53GHz но всеравно небо и земля😊 На практике вобщем то так и получилось - он этих торентов ваще никак не ощющает - что есть что нет - разница в загрузке плавает в районе 5 процентов. Кучу времени потратил на поиски софта - роутер приехал с убитой флешкой, не мог даже загрузица, заменить не проблема - там обычная CF на гиг-два пойдет а вот софт найти оказалось не так просто - довольно таки древний аппарат который вытеснили SRX'ы у которых ноги вобщем то и растут из J серии, точнее так то он по сути не сильно древний - поддержку дропнули тока в 2018 году, и софт есть на торрентах, но это архивы для установки уже поверх существующей системы, а вот чтоп с нуля на флэшку можно было закатать пришлось поискать, но в итоге все получилось - Juniper links все работает, после недельного траха с тоннелем на работу😊 Об этом и хочу рассказать😊

Вобщем нужен мне тоннель на работу, поверх которого у меня BGP почти прямо в кору в бэкбон. Дома у меня динамический серый IP. Все было легко и просто когда была кошка, так как с другой стороны тоже была кошка - все работало сполпинка поверх dmvpn что не удивительно ибо кошка с кошкой и кошковский dmvpn для такого и предназначен😊 Но тут вместо кошки жунипер - и резко возникает вопрос - КАК БЛЯТЬ ТЕПЕРЬ ЗДЕЛАТЬ этот сраный тоннель😊 Я не спец по всяким бранчевым решениям, у меня большие сети, большие маршрутизаторы, и физические каналы, а всякие vpn это все не мое, но тем не менее я сетевик - почитал порыл - задолбался - милионы блять howto и примеров как зделать практически любые тоннели между кошкой и джунипером да и не тока, но без динамических IP и ната - ну да блять, там и делать то нехер - прописал с двух сторон хоть гре хоть ipip да что угодно - и постят эти howto кругом, кому они нах нужны тока, а вот с динамикой из за ната уже все не так просто😊 В итоге я понял что блять единственный интероперабельный вариант в такой ситуации это IPSEC в туннельном режиме. Никогда до этого не ковырял IPSEC, попробовал вывернуца приставив сбоку кошку за джунипером - но DMVPN споткнулся на двойном нате, пришлось таки в срочном порядке осваивать IPSEC😊

На джунипере как ни странно все оказалось достаточно просто, а вот со стороны кошки постоянно получались какието косяки😊 Собственно сам IPSEC поднять получилось без проблем, проблемы возникали с тоннелем😊 У кошки вариантов этого ипсека тьма на все случаи жизни, если с другой стороны кошковское же решение😊 а вот если нет то начинаюца нестыковки😊

Сначала затык вышел с IPSEC внутри VRF😊 У меня там по сути был так называемый Front Door VPN - тоесть один конец тоннеля торчит в VRF c интернетом, другой в VRF с бэкбоном, так вот IPSEC в VRF не заработал, в global работал, в VRF нет - видать баг иоса какой то потому что дома так работал как и написано у кошки, а где нада нет😊

Так как там где нада это была не основная задача а иос подбираеца под основную таки - пришлось все это дело оттуда вообще вынести на какуюнить другую подходящую хрень😊 Подходящая хрень в виде древней ободранной и страшной как сама моя жизнь циски 3725 нашлась под чьим то столом, в состоянии "пинали лет 5 ногами" пока она там валялась, но тем не менее она включилась, матерясь на хренова крутящиеся вентиляторы, нада отдать ей должное😊 вентиляторы смазал😊 через пару дней смазка видать попала куда нада и мат убрался😊 В добавок таким образом надобность в одном vrf отпала и интернет я засунул в global дабы не усложнять себе жизнь😊

В итоге первое что реально заработало на ней собсно IPSEC через cryptomap на интерфейсе, с двумя ip на концах и поверх этого GRE тоннель - работает, но не красиво ибо умом то понимаеш что GRE тут лишний оверхед, а мне и сам IPSEC тоже лишний оверхед ибо шифровать мне там нечего - нужен только транспорт - нада убрать значит😊 Начал искать как - нарыл кошкин DVTI aka Dynamic Virtula Interface - вроде бы что нужно - жунипер судя по всему имеет то же самое и может гонять routing protocol прямо поверх тунельного интерфейса.

Но и тут вышел косяк - если в proxy identify вписать какой то конкретный ip то все работает, но со стороны жунипера шифруеца не весь траффик попадающий в интерфейс а только тот что попадает в proxy identify - тоесть route based VPN нихрена не получается. Если в proxy identify поставить 0.0.0.0/0 как и должно быть то интерфейс поднимался, но без роутинга - тоесть кошка без понятия какие адреса на встречном конце - ситуация сама по себе прикольная - интерфейс есть, а маршрута через него нет😊 И ниче с этим сделать нельзя - интерфейс динамический - берет настройки с virtual-template, ip с лупбэка через unnumbered - тоесть никак в конфигурации маршрут через него указать нельзя, как и адреса на другом конце😊 Можно настроить xauth и раздавать адреа из пула, но у меня там BGP и нужен статический IP, а создавать пул из 1 адреса тоже как то не красиво😊 Хрен его знает каким образом это работает между кошками но судя по howto и примерам в интернете как то работает. Я нашол только одно упоминание что такая проблема между кошками имеет место быть, и там же нашол решение - запустить до кучи какойнить мульткастовый routing протокол на интерфейсе, конкретно там был rip, но не нравица мне он и я попробовал ospf - и прокатило😊 По ospf кошка быстро снюхалась с жунипером и выяснила какой адрес на другом конце тоннеля, после чего уже стало возможным поднять BGP😊 но это просто на словах, а по факту есть куча ньюансов😊

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

cisco может имеить кучу ospf процессов, причем не связанных друг с другом, посему делаем так - для туннельного интерфейса отдельный ospf процесс, с distance 210, и все - его задача только выяснить что на другом конце тоннеля, ну и до кучи проанонсировать свою сторону но жуниперу это не нужно - там можно статически написать как локальный так и удаленный ip на туннельном интерфейсе, но малоли - может кому еще понадобица.

Тем не менее нам нада как то обмениваца маршрутами с маршрутизаторами входящими в бэкбон. Так как по ospf нельзя ибо как написано выше опастно делать мы это будем по протоколу BGP ибо фильтруеца он как угодно, а на кошке будем делать двухстороннюю редистрибьюцию bgw<->ospf 1.

Juniper как циско иметь кучу независимых ospf процессов не может, зато может по другому - там есть виртуальные роутеры - чтото типа кошкиных VRF тока круче😊 И ospf можно засунуть в такой виртуальный роутер дабы он не анонсировал что ни попадя, и че бы он там ни принял эти анонсы в этом виртуальном роутере так и остануца и не попадут в глобальную таблицу маршрутизации.

Вроде бы на этом все мои страдания по скрещиванию законьчилис, теперь собственно

Learn more...

2018-07-09 Networking-Blog

Networking-Blog

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

Cвязка squid + c-icap с моими любимыми шлюхами и блэкджеками (ака контент фильтрация) для себя любимого у меня стояла уже лет 10 как в качестве банерорезки и кеша, После начала позора роскомнадзора со своими блокировками я добавил в эту схему tor для обхода блокировок, и i2pd до кучи - хз зачем но пускай будет. Но я все время искал чем бы заменить сквид с его sslbump ибо для одного юзверя это даже не из пушки по воробьям а чето ближе к ядерной боеголовке. И не особо то находил, а без sslbump все это не имеет смысла, большая часть траффика идет по https, и его необходимо расковыривать для фильтрации баннеров и кеширования тоже. Плюс сквид это тот еще монстр и часто заточить его на чтото что вызывает standart violation без рашпиля (ковыряния в исходниках) бывает невозможно. Не для персонального использования он создан, он может не чхая переварить полгига траффика и тысячи юзверей - я правда проверял - может😊 но при этом иногда заставить его к примеру закешировать чтото что по стандарту кешироваца не должно весьма проблематично.

И тут, недавно, не помню уже с чего вдруг гдето выплыл выплыл у меня в поиске [[Glossary_wwwoffle?|wwwoffle]], который заточен какрас для персонального использования в противовес сквиду, и почемуто я решил на него глянуть, не помню уже почему - мошт просто делать нехер было. И полной неожиданностью оказалось что оно умеет mitm ака sslbump в сквиде типа из коропки, причем уже много лет, и кешировать https тоже умеет, ну и еще кучу всяких standart violation для которых squid нада затачивать что не всегда тривиально, а тут типа все есть. ну и сразу же я решил сие дело посмотреть и опробовать.

Вообще так как все это нужно для 1-2-3 добашних клиентов, требования ко всему этому очень просты:

  • Оно должно быть маленькое и простое, пофиг на производительность и масштабируемость. Хотя кстати тот же сквид кстати тормозил при старте на парсинге ACL'ей сгенерированных из списка РКН
  • Оно обязательно должно уметь mitm aka sslbump в сквиде для https.
  • Оно должно уметь роутить траффик по url спискам, ну тоесть к примеру http://www.gedanken.org.uk/software/wwwoffle/ - идем директом, https://rutracker.org/forum/viewforum.php?f=1958 - идем через некий parent прокси дабы обойти блокировку, и это должно работать и для https тоже, а url желательно с масками.
  • Так же оно должно бы уметь роутить и по dst ip адресам и подсетям, ну тоесть 1.1.1.0/22 идем директом, а 2.2.2.0/24 опять таки идем через некий parent proxy, хотя это опционально так как в случае socks прокси тора это решается на уровне системы связкой [[Glossary_tun2socks?|tun2socks]] + ipset + iproute.
  • Хорошо бы еслип оно умело делать преобразование socks<->http proxy, но тоже опционально - решаеца промежуточными прокси, к примеру 3proxy
  • Оно должно уметь блочить url по маскам дабы фильтровать рекламку и прочую дроч, желательно с возможностью подмены заблоченных ссылок на свои.
  • Неплохо было бы так же иметь контент-фильтрацию, хотя опять таки решается промежуточными прокси к примеру privoxy/bfilter.

Learn more...

Linux Gentoo system wide epatch user

В Gentoo есть очень полезная возможность наложить свои патчи на стандартный ebuild при сборке. Делается это так - патчи нужно сложить к примеру в /etc/portage/patches/net-proxy/wwwoffle для пакета net-proxy/wwwoffle и они применяца автоматом при сборке, ЕСЛИ! в ебилде вызов epatch_user в src_prepare(), а есть он блять не везде.. поэтому гдето это работает а гдето нет.

Но есть способ это исправить:

В /etc/portage/bashrc помещаем следующее:

pre_src_prepare() {
    [[ ${EAPI:-0} == [012345] ]] || return
    if ! type estack_push > /dev/null 2>&1; then
        local estack_names="eshopts_push eshopts_pop evar_push evar_push_set evar_pop estack_push estack_pop"
        source <(awk "/^# @(FUNCTION|VARIABLE): / { p = 0 } /^# @(FUNCTION|VARIABLE): (${estack_names// /|})\$/ { p = 1 } p { print }" ${PORTDIR}/eclass/estack.eclass)
    fi
    if ! type epatch_user > /dev/null 2>&1; then
        local epatch_names="EPATCH_SOURCE EPATCH_USER_SOURCE epatch_user_death_notice epatch_user epatch"
        source <(awk "/^# @(FUNCTION|VARIABLE): / { p = 0 } /^# @(FUNCTION|VARIABLE): (${epatch_names// /|})\$/ { p = 1 } p { print }" ${PORTDIR}/eclass/epatch.eclass)
    fi

    epatch_user

    for name in $epatch_names; do
        unset $name
    done
    for name in $estack_names; do
        unset $name
    done

}

Улыбимся/радуемся - гентуж блять!! рулит жеж нах!!😊

Learn more...

Linux Gentoo build package for debugging

Создаем /etc/portage/env/debugsyms и пишем туда следующее:

USE="debug"
CFLAGS="${CFLAGS} -g -ggdb"
CXXFLAGS="${CXXFLAGS} -g -ggdb"
FEATURES="${FEATURES} nostrip"

#debuging FEATURES: keepwork nostrip splitdebug compressdebug nostrip

Этого достаточно чтоп собрать пакет с отладочной информацией.

До кучи создаем /etc/portage/env/installsources с вот таким содержимым:

FEATURES="${FEATURES} installsources"

Это позволит установить результирующие исходники из которых был собран пакет со всеми патчами дабы не ипаца вручную, ставяца они в /usr/src/debug/

Это по сути мы сделали вариацию окружения для сборки пакетов с отладкой, на систему это не влияет - нада принудительнр сказать что нам нада собрать с отладкой, делается это вот так к примеру для пакета net-proxy/wwwoffle:

/etc/portage/package.env:

net-proxy/wwwoffle debugsyms installsources

Тоесть собрать с отладкой и поставить исходники.

Learn more...

Linux Conntrack automatic helper assignment Docs

nf_conntrack: default automatic helper assignment has been turned off for security reasons and CT-based firewall rule not found. Use the iptables CT target to attach helpers instead. вот что выдало мне ядро 4.14 на нате, вобщем то предупреждали уже давно, на 4.4 как минимум точно. Ну, я подгрузил модули хелперов принудительно, и думал что этого достаточно, но не тут то было.

Позвонили из саппорта, говорят pptp не хочет у когото соединяца, правда ошиблись и назвали не тот роутер на котором у меня тестируется 4.14, я забил сказав что со мной сие никак не связано😊 Тем не менее мне прислали дамп:

root@nwmsk-46-gw:~# tcpdump -ni eth1.189 host 37.29.74.109
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1.189, link-type EN10MB (Ethernet), capture size 262144 bytes
13:15:18.411162 IP 10.32.60.245.49223 > 37.29.74.109.1723: Flags [S], seq 3051623381, win 8192, options [mss 1460,nop,wscale
8,nop,nop,sackOK], length 0
13:15:18.454187 IP 37.29.74.109.1723 > 10.32.60.245.49223: Flags [S.], seq 1229404315, ack 3051623382, win 5600, options [mss
1400,nop,nop,sackOK,nop,wscale 5], length 0
13:15:18.455865 IP 10.32.60.245.49223 > 37.29.74.109.1723: Flags [.], ack 1, win 257, length 0
13:15:18.455873 IP 10.32.60.245.49223 > 37.29.74.109.1723: Flags [P.], seq 1:157, ack 1, win 257, length 156: pptp CTRL_MSGTYPE=SCCRQ
PROTO_VER(1.0) FRAME_CAP(A) BEARER_CAP(A) MAX_CHAN(0) FIRM_REV(0) HOSTNAME() VENDOR(Microsoft)
13:15:18.498863 IP 37.29.74.109.1723 > 10.32.60.245.49223: Flags [.], ack 157, win 209, length 0
13:15:18.511886 IP 37.29.74.109.1723 > 10.32.60.245.49223: Flags [P.], seq 1:157, ack 157, win 209, length 156: pptp CTRL_MSGTYPE=SCCRP
PROTO_VER(1.0) RESULT_CODE(1) ERR_CODE(0) FRAME_CAP() BEARER_CAP() MAX_CHAN(1) FIRM_REV(1) HOSTNAME(local) VENDOR(linux)
13:15:18.512947 IP 10.32.60.245.49223 > 37.29.74.109.1723: Flags [P.], seq 157:325, ack 157, win 256, length 168: pptp CTRL_MSGTYPE=OCRQ
CALL_ID(49223) CALL_SER_NUM(23) MIN_BPS(300) MAX_BPS(100000000) BEARER_TYPE(Any) FRAME_TYPE(E) RECV_WIN(64) PROC_DELAY(0)
PHONE_NO_LEN(0) PHONE_NO() SUB_ADDR()
13:15:18.567638 IP 37.29.74.109.1723 > 10.32.60.245.49223: Flags [P.], seq 157:189, ack 325, win 242, length 32: pptp CTRL_MSGTYPE=OCRP
CALL_ID(63232) PEER_CALL_ID(49223) RESULT_CODE(1) ERR_CODE(0) CAUSE_CODE(0) CONN_SPEED(100000000) RECV_WIN(64) PROC_DELAY(0)
PHY_CHAN_ID(0)
13:15:18.575569 IP 10.32.60.245.49223 > 37.29.74.109.1723: Flags [P.], seq 325:349, ack 189, win 256, length 24: pptp CTRL_MSGTYPE=SLI
PEER_CALL_ID(63232) SEND_ACCM(0xffffffff) RECV_ACCM(0xffffffff)
13:15:18.577786 IP 10.32.60.245 > 37.29.74.109: GREv1, call 63232, seq 0, length 64: LCP, Conf-Request (0x01), id 0, length 50
13:15:18.657114 IP 37.29.74.109.1723 > 10.32.60.245.49223: Flags [.], ack 349, win 242, length 0
13:15:20.577458 IP 10.32.60.245 > 37.29.74.109: GREv1, call 63232, seq 1, length 64: LCP, Conf-Request (0x01), id 1, length 50
13:15:23.577748 IP 10.32.60.245 > 37.29.74.109: GREv1, call 63232, seq 2, length 64: LCP, Conf-Request (0x01), id 2, length 50
13:15:27.578069 IP 10.32.60.245 > 37.29.74.109: GREv1, call 63232, seq 3, length 64: LCP, Conf-Request (0x01), id 3, length 50
13:15:31.578450 IP 10.32.60.245 > 37.29.74.109: GREv1, call 63232, seq 4, length 64: LCP, Conf-Request (0x01), id 4, length 50
13:15:35.578286 IP 10.32.60.245 > 37.29.74.109: GREv1, call 63232, seq 5, length 64: LCP, Conf-Request (0x01), id 5, length 50
13:15:39.579232 IP 10.32.60.245 > 37.29.74.109: GREv1, call 63232, seq 6, length 64: LCP, Conf-Request (0x01), id 6, length 50
13:15:43.580117 IP 10.32.60.245 > 37.29.74.109: GREv1, call 63232, seq 7, length 64: LCP, Conf-Request (0x01), id 7, length 50
13:15:47.580822 IP 10.32.60.245 > 37.29.74.109: GREv1, call 63232, seq 8, length 64: LCP, Conf-Request (0x01), id 8, length 50
13:15:48.632986 IP 37.29.74.109.1723 > 10.32.60.245.49223: Flags [F.], seq 189, ack 349, win 242, length 0
13:15:48.633575 IP 10.32.60.245.49223 > 37.29.74.109.1723: Flags [.], ack 190, win 256, length 0
13:15:48.641130 IP 10.32.60.245.49223 > 37.29.74.109.1723: Flags [F.], seq 349, ack 190, win 256, length 0
13:15:48.684009 IP 37.29.74.109.1723 > 10.32.60.245.49223: Flags [.], ack 350, win 242, length 0

GRE в одну сторону - типичный случай для pptp без хелпера потому что оно не натица без него а идет с серого адреса а дальше его тупо дропнет и до сервера оно вообще не дойдет, потому и LCP без ответа - закралось подозрение что сапорт обьебался с роутером.

Уточнил - точно ли оно идет не через тестовый роутер, оказалось таки через него - вопиющий пример херовой диагностики😊

Ну и тут сразу стало понятно что хелперы не работают, и начались разборки:

Learn more...

Linux Filesystems IO Amplification Docs

Попалась тут интересная статейка, есть над чем задумаца...

Вот она, расплата за журналирование, COW, LOG-Структуры и прочие плюшки современных FS.

Learn more...

Nginx frontend backend Docs

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

Многие скажут - купи хостинг за 1$/VPS/etc и ниипи мозга итд - нихачуя😊 У меня это все на работе есть, но всеравно не хочу. Как говорица своя фуфайка ближе к телу😊 Какрас хостинг и впс помоему ни что иное как мозгоебство, на хостинге шаг влево-вправо - наткнешся на стену, а у меня тут perl и шагов там может быть овердохрена, виртуализацию и облачка не признаю впринципе для таких задач, и вам предлагаю тоже спустица с облачков на землю, тут все лучше😊 Да и вообще, кагдато давно-давно, мой самый первый сайт работал у меня дома ваще на диалапе😊

И тут возникли некоторые сложности со всякими натами и PBR. Схемка сети примерно такая - оператор<->мойроутерснатом<->локалкивсякие. В локалкивсякие находица и сервер, но помимо этого у роутера еще неожиданно есть тоннель ко мне на работу, с bgp прямо в ядро сети и прочими шлюхами дабы мне было удобно работать😊

И, получается что ну даже если я прокину порт с роутера, навешу домен на его внешний адрес ну да - будет работать, со всея интернету, НО, тока не из дома и не с работы😊 И вот почему:

Learn more...

2017-12-23 Web-Blog

Web-Blog

Вобщем после создания сего сайта который вы счас читаете, как это водица - одолели спам-боты, коментарии были открыты всем, и вот начали они мне туда "комментировать"😊

Вывод - привернуть регистрацию, а для этого нужна почта, причем на этой же машине где крутица движок сайта.

А ее то тут и нету, вообще, даже локальной, тоесть MTA отсутствует напрочь, а как то мыло для регистрации слать нада. Вобщем то движок при отсылке дергает sendmail как все остальные милионы движков, все стандартно. Поэтому нада чтото что могло бы выступать заменой sendmail'у. Выходы:

  1. поставить MTA и настроить форвардинг всей почты на почтовый сервер. как правило в составе любого MTA есть затычка аля sendmail.
  2. поискать чтото аля fetchmail наоборот, ну или какойнить совсем легкий MTA чтоп всю локальную почту форвардило через акаунт на почтовом сервере, тоесть по сути 1 хрен вариант 1 но только это будет уже не из пушки по воробьям как в случае полноценного MTA

И такие варианты нашлись, аж несколько. Начал смотреть и пробовать:

  1. esmtp отложил как last resort сразу - на страничке проэкта надпись THIS PROJECT IS NO LONGER BEING MAINTAINED.
  2. ssmtp завел, настроил, и exim на почтовом сервере мне сказал SMTP protocol synchronization error, это значит что ssmtp пытается слать команды до того как почтовый сервер выдаст ему приглашение, что в свою очередь значит что ssmtp херова следует стандартам и по сему я его забраковал после этого как поделие какованить очередного криворукого далбаеба, вдобавок он работает в синхронном режиме - тоесть ктото дернул там mail/sendmail, он тут же начинает слать в том же процессе, если не удачно ну чтож - обидно, досадно, но ладно - тоесть никакой очереди и ретраев у него нет. пока не отослал или не получил отлуп процесс блокируется, что опять таки намекает на криворуких далбаебов.
  3. nullmailer завелся не сразу, почемуто localhost в /etc/nullmailer/me ему не понравилось - выплевывал какуюто непонятную ошибку при попытке отправить что либо даже не доходя до smtp, тоесть выплевывал сам еще до того как поместить письмо в свою локальную очередь, хз почему, но после того как туда вписал домен от которого собираюсь слать все наладилось и заработало. Так же он имеет очередь, тоесть доставка асинхронна в отличии от варианта 2, и если сразу доставить не удалось будет пытаца потом сделать это снова.
  4. masqmail последняя версия от 2015 года, в генте вообще отсутствует - отмел так как вариант 3 задачу решает и присутствует в генте штатно, а именно она стоит на этом сервере.

Итак, выбор пал на nullmailer. Далее собсно более подробно о настройке nullmailer ибо она не тривиальна, а очень тривиальна😊 Всего 4 строчки(ну мне просто делать нех и я тут печатаю хрень всякую😊 Рас уж начал - нада дописать до конца😊

Learn more...