Re: [freebsd] TCP vs UDP в контексте туннеля.
On 28.06.2022 09:23, Nick Kostirya via freebsd wrote:
> On Tue, 28 Jun 2022 03:03:35 +0700
> Eugene Grosbein wrote:
>
>> On 27.06.2022 10:11, Nick Kostirya via freebsd wrote:
>>> On Mon, 27 Jun 2022 01:36:39 +0700
>>> Eugene Grosbein wrote:
>>>
25.06.2022 13:47, Nick Kostirya via freebsd пишет:
> Привет.
>
> В туннель заворачивается на сервере X (192.168.10.1) вот так
>
> ${fwcmd} nat 2 config if vmx0 same_ports reset redirect_port udp
> 192.168.10.111:8080 8080 redirect_port tcp 192.168.10.111:8080 8080
>
>
> На сервере Y (192.168.10.111) запросы tcpdump показывает приходят на
> 192.168.10.111, но вот ответы...
>
> UDP ответ идет с 192.168.0.111 (вне туннеля) по внешнему интерфейсу rl0
> а
> TCP ответ идет с 192.168.10.111 (адрес туннеля), но тоже по внешнему
> интерфейсу rl0
>
>
> Почему так?
>
>
> Для UDP заворачиваю в туннель вот так
> ${fwcmd} add fwd 192.168.10.1 all from me 8080 to any out via rl0
>
> И все работает. Сервер видит ответ X и пересылает дальше.
>
> А вот с TCP forward не работает.
Нужен полный вывод ipfw show без каких-либо редактирований, разве что
можешь заменить публичные адреса.
>>>
>>> На W.W.W.W делаю запрос, который X.X.X.X перенаправляет в тeннель
>>> 192.168.10.1 -> 192.168.10.111
>>> # echo hello | nc -w 1 X.X.X.X 8080
>>>
>>>
>>>
>>> Ответ на дальнем конце туннеля (192.168.10.111), где стоит TCP сервер
>>>
>>>
>>> # tcpdump -A -i rl0 'port 8080'
>>
>> Я просил вывод ipfw show, а не tcpdump.
>
>
> Прошу прошение.
>
> UDP
>
> Начало туннеля.
>
> # ipfw show
> 001001 34 nat 1 ip from any to me 8080 in via vmx0
> 002002 62 nat 1 ip from any 8080 to any
> 65000 563352 allow ip from any to any
> 65535 8928 1279978 deny ip from any to any
>
>
>
> ${fwcmd} nat 1 config if vmx0 same_ports reset redirect_port udp
> 192.168.10.111:8080 8080 redirect_port tcp 192.168.10.111:8080 8080
> ${fwcmd} add nat 1 ip from any to me 8080 in via vmx0
> ${fwcmd} add nat 1 ip from any 8080 to any
>
>
>
> Сервер в конце туннеля
>
> # ipfw show
> 00100 0 0 fwd 192.168.10.1 ip from 192.168.10.111 8080 to any via rl0
> 00200 131 fwd 192.168.10.1 ip from me 8080 to any out via rl0
> 65000 120 11064 allow ip from any to any
> 65535 122 10052 allow ip from any to any
>
>
> ${fwcmd} add fwd 192.168.10.1 all from 192.168.10.111 8080 to any via rl0
> ${fwcmd} add fwd 192.168.10.1 all from me 8080 to any out via rl0
>
>
>
> TCP
>
> Начало туннеля.
>
> # ipfw show
> 001001 60 nat 1 ip from any to me 8080 in via vmx0
Лучше писать in recv vmx0 (хотя функционально это одно и то же).
> 002000 0 nat 1 ip from any 8080 to any
А вот тут большая ошибка: транслировать исходящие пакеты надо,
только если они уходят обратно в тот же интерфейс, то есть пропущено out xmit
vmx0 в конце правила, добавь.
> 65000 1047636 allow ip from any to any
> 65535 8928 1279978 deny ip from any to any
>
> Сервер в конце туннеля
>
> # ipfw show
> 00100 4 240 fwd 192.168.10.1 ip from 192.168.10.111 8080 to any via rl0
> 00200 0 0 fwd 192.168.10.1 ip from me 8080 to any out via rl0
> 65000 63 4599 allow ip from any to any
> 65535 122 10052 allow ip from any to any
Если тебе надо безусловно направлять ответные пакеты через 192.168.10.1, то
правило нужно только одно
и чем оно будет короче, тем лучше:
ipfw add 100 fwd 192.168.10.1 ip from any 8080 to any out
Это если сервер не выполняет функции роутера и исходящий трафик у него есть
только свой собственный
и форвард нужен безусловный, независимо от того, в какой интерфейс пакеты
таблица маршрутизации
направила бы ответные пакеты.
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] AWS Tech Conference
On 28.06.2022 13:33, Vladimir Sharun wrote: > Привет, > > Jail это chroot плюс опционально виртуализированный сетевой стек > плюс запрет руту из клетки влиять на хост. Не виртуальная машина даже > близко, > для этого bhyve. > > > Чуть больше: > > * процессы работают в собственном jailspace назовем его так, которые > грохаются вместе с jail В клетке они работают, понятия jailspace я не видел. Разумеется, убиваются при уничтожении клетки, но убийство группы или групп процессов не уникальная фича для jail :-) Просто удобно убивать пачку возможно неродственных процессов, согласен. > * affinity Process affinity уж точно не уникальная фича клеток, cpuset универсален. > * Limit the number of commands from exec.* Это о чём? > * Следующие sysctl'ки дают приблизительный обзор ограничений: > > > security.bsd.see_jail_proc: 1 > security.jail.mount_tmpfs_allowed: 0 > security.jail.mount_zfs_allowed: 0 > security.jail.mount_procfs_allowed: 0 > security.jail.mount_devfs_allowed: 0 > security.jail.param.sysvshm.: 0 > security.jail.param.sysvsem.: 0 > security.jail.param.sysvmsg.: 0 > security.jail.param.allow.mount.tmpfs: 0 > security.jail.param.allow.mount.zfs: 0 > security.jail.param.allow.mount.procfs: 0 > security.jail.param.allow.mount.devfs: 0 > security.jail.param.allow.mount.: 0 > security.jail.param.allow.suser: 0 > security.jail.param.allow.unprivileged_proc_debug: 0 > security.jail.param.allow.read_msgbuf: 0 > security.jail.param.allow.reserved_ports: 0 > security.jail.param.allow.mlock: 0 > security.jail.param.allow.socket_af: 0 > security.jail.param.allow.quotas: 0 > security.jail.param.allow.chflags: 0 > security.jail.param.allow.raw_sockets: 0 > security.jail.param.allow.sysvipc: 0 > security.jail.param.allow.set_hostname: 0 > security.jail.param.ip6.saddrsel: 0 > security.jail.param.ip6.: 0 > security.jail.param.ip4.saddrsel: 0 > security.jail.param.ip4.: 0 > security.jail.param.cpuset.id: 0 > security.jail.param.host.hostid: 0 > security.jail.param.host.hostuuid: 64 > security.jail.param.host.domainname: 256 > security.jail.param.host.hostname: 256 > security.jail.param.host.: 0 > security.jail.param.children.max: 0 > security.jail.param.children.cur: 0 > security.jail.param.dying: 0 > security.jail.param.vnet: 0 > security.jail.param.persist: 0 > security.jail.param.devfs_ruleset: 0 > security.jail.param.enforce_statfs: 0 > security.jail.param.osrelease: 32 > security.jail.param.osreldate: 0 > security.jail.param.securelevel: 0 > security.jail.param.path: 1024 > security.jail.param.name: 256 > security.jail.param.parent: 0 > security.jail.param.jid: 0 > security.jail.devfs_ruleset: 0 > security.jail.enforce_statfs: 2 > security.jail.mount_allowed: 0 > security.jail.chflags_allowed: 0 > security.jail.allow_raw_sockets: 0 > security.jail.sysvipc_allowed: 0 > security.jail.socket_unixiproute_only: 1 > security.jail.set_hostname_allowed: 1 > security.jail.jail_max_af_ips: 255 > security.jail.vnet: 0 Это уже пошла детализация того же, о чем я упомянул, про ограничение влияния на хост (и на соседнией jail тоже). Плюс ещё Mandatory Access Control (MAC) тоже может влиять на клетки. ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] AWS Tech Conference
hi, Tue, Jun 28, 2022 at 04:14:26, eugen wrote about "Re: [freebsd] AWS Tech Conference": > Jail это chroot плюс опционально виртуализированный сетевой стек > плюс запрет руту из клетки влиять на хост. Судя по тому, что можно видеть в комплекте всяких cgroup, в опциях clone и так далее, параметров сильно больше: 1. chroot (уже сказано) 2. своё пространство pidʼов 3. шейперы разных шедулеров (CPU, IO, память) и пространства учёта 4. ограничения на набор допустимых устройств (тех что в /dev) 5. сетевой стек (инстанс, интерфейсы) 6. идентификация ядра (ответ на uname) 7. отдельное пространство IPC (если не сделано через FS) 8. CPU affinity (ограничение сверху и возможно маппинг) 9. таки да, запрет "влиять на хост", и это может быть сложно (что можно монтировать, а что нет) И это я наверняка мог ещё что-то потерять (если заглянуть в /proc/cgroup в podʼе под k8s, видны hugetlb и какой-то freezer). В принципе повторить всё это не проблема, но конкретный механизм... > Не виртуальная машина даже близко, > для этого bhyve. Кэп:) > Насколько я ничего не понимаю, всего хватает. > В 13.1 допилили LinuxKPI, чтобы запускать современный линуксовый userland в > jail, > включая Docker. Сам не пробовал. Звучит хорошо, но наличие нативного было бы лучше. Серьёзно, лозунг типа "вы не заметите разницы для своего любимого кубера" тут бы что-то дал. -netch- ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] anacron daemon vs cron call
Собственно, проверил. Таки да -- anacron запускается, выполняет задания и выходит, так что в crontab не помешает. Ещё вижу одно преимущество скрипта перед @reboot в crontab -- в скрипте стоит resume. Похоже, что он также будет запускаться после выхода из S3 (поправьте, если ошибаюсь). В целом же вопрос закрыт. On Mon, Jun 27, 2022 at 5:12 PM Paul Tatarenko wrote: > > Я просто не вижу, что написано перед . Может, "или" [в|о]писано именно > там. :) > > Хотя предложенный патч, похоже, всё объясняет. > > > On 27.06.2022 15:55, Anton Saietskii wrote: > > Не-не-не, там же нет "или". Кажись нашёл PR: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=142275 > Похоже, что оно у нас вообще не демон (что странно, в CentOS видел постоянно > работающий процесс, например). > Зачем тогда скрипт rc -- непонятно, можно ж (и нужно, чтобы одинаково) всё > тогда в cron вписать, вместо rc -- @reboot. > > On Mon, Jun 27, 2022, 15:48 Paul Tatarenko wrote: >> >> Привет! >> >> Может, это просто перечисление возможных вариантов запуска, а не >> инструкция с полным перечнем необходимых действий? >> >> >> On 27.06.2022 11:21, Anton Saietskii wrote: >> > Приветствую, коллеги. >> > Меня давно огорчало отсутствие чего-то подобного anacron в базе, и вот >> > после долгих лет страданий время наконец пришло. Однако, возник >> > наиглупейший вопрос, который только можно придумать: а как его >> > запускать-то кошерно? В pkg-message говорят так: >> > >> > - Add a call to anacron to /etc/crontab >> > - Add anacron_enable="YES" to /etc/rc.conf >> > >> > >> > Но... >> > - Если я его запускаю демоном -- зачем дёргать каждый час из cron? >> > - Если я его дёргаю из cron -- зачем мне демон? >> > >> > Наверняка я что-то упустил, но что? >> > ___ >> > freebsd mailing list >> > freebsd@uafug.org.ua >> > http://mailman.uafug.org.ua/mailman/listinfo/freebsd >> >> -- >> Best regards, >> Paul Tatarenko http://tatarenko.kiev.ua >> [listening to coolest sound - silence] >> [Silence is sexy - Einsturzende Neubauten] >> >> ___ >> freebsd mailing list >> freebsd@uafug.org.ua >> http://mailman.uafug.org.ua/mailman/listinfo/freebsd > > -- > Best regards, > Paul Tatarenko http://tatarenko.kiev.ua > [listening to coolest sound - silence] > [Silence is sexy - Einsturzende Neubauten] > > ___ > freebsd mailing list > freebsd@uafug.org.ua > http://mailman.uafug.org.ua/mailman/listinfo/freebsd ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] AWS Tech Conference
> On 28 Jun 2022, at 00:14, Eugene Grosbein wrote: > > On 27.06.2022 15:36, Valentin Nechayev wrote: >> hi, >> >> Mon, Jun 27, 2022 at 11:18:53, vladimir.sharun wrote about "Re: [freebsd] >> AWS Tech Conference": >> >> Вообще хотелось бы увидеть актуальную сводку "чего именно сейчас в >> FreeBSD не хватает, чтобы запустить Docker" (ну или его полноценный >> аналог). > > Насколько я ничего не понимаю, всего хватает. > В 13.1 допилили LinuxKPI, чтобы запускать современный линуксовый userland в > jail, > включая Docker. Сам не пробовал. Вот здесь возникает вопрос: а зачем там собственно фря? > >> Если оно есть, можно её рекламировать в плане, например, "у нас то >> же самое, но линуксовый вирус не сработает". Если нет - то понимать, >> чего именно не хватает. >> Я уровня изоляции в jail уже не понимаю совсем, что именно там есть, >> чего нет. > > Jail это chroot плюс опционально виртуализированный сетевой стек > плюс запрет руту из клетки влиять на хост. Не виртуальная машина даже близко, > для этого bhyve. > ___ > freebsd mailing list > freebsd@uafug.org.ua > http://mailman.uafug.org.ua/mailman/listinfo/freebsd -- Taras Heichenko ta...@academ.kiev.ua ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] releng/13.1, vt(4) kernel messages color
On Mon, Jun 27, 2022 at 8:53 PM wrote: > > 29 мая 2022 г., 12:39, "Anton Saietskii" написал: > > > Приветствую, товарищи. > > Пришло время обновляться и заодно окончательно переходить на vt(4). > > Для тестирования этого дела взял я VirtualBox 6.1, водрузил туда > > releng/13.1 и пошёл компилять-собирать. Однако, после перезагрузки > > меня постигло разочарование, т.к. годами работавшая в sc(4) опция по > > изменению цвета сообщений ядра и её наследник в новой консоли > > перестали работать. > > > > Изначально текст юзерленда и ядра серый. Добавил свои любымые опции: > > root@localhost:~ # config -x /boot/kernel/kernel | grep TERM > > options TERMINAL_KERN_ATTR=(FG_GREEN|BG_BLACK) > > options TERMINAL_NORM_ATTR=(FG_LIGHTGREY|BG_BLACK) > > > > Текст ядра стал вместо серого белым, а не зелёным, как я хотел. Собрал > > GENERIC с этими опциями -- ничего не изменилось. Собрал GENERIC с > > этими опциями, в точности взятыми из NOTES -- опять ничего не > > изменилось. Перепробовал все 3 контроллера видео в VBox -- > > естественно, и в этот раз ничего не изменилось. > > Получается, что при наличии к конфиге ядра опции TERMINAL_KERN_ATTR > > цвет изменяется с серого на белый вне зависимости от значения самой > > опции. > > > > Вот сижу теперь, чешу репу и думаю -- ЧЯДНТ? > > Внезапно обнаружилось, что эта расцветка работает только после > загрузки модуля i915kms.ko. > (Только у меня эти опции не в опциях ядра, а в loader.conf: > kern.vt.color.7.rgb="#00ff00" > kern.vt.color.15.rgb="#008800" > ) > > Но есть нюанс :) > если запилить в loader.conf: > > iicbus_load="YES" > iicbb_load="YES" > iic_load"YES" > drm2_load"YES" > i915kms_load="YES" > > два последних модуля не грузятся. > Причем если их грузить руками из loader prompt, тогда грузятся, и расцветка > работает. > > Нюанс2: если сделать: > cp drm2.ko drmn.ko > cp i915kms.ko innnkms.ko > и вставить в loader.conf загрузку этих модулей по этим именам, > то все грузится. > > Нюанс3: по необнаруженному принципу эти переименованные модули иногда видны > в kldstat как drm2/i915kms, а иногда как drmn/innnkms. > > Система 12.3-RELEASE. Поскольку для VirtualBox нет драйвера KMS (или уже есть?), я пробовал vt_vga + hw.vga.textmode. Ожидаемо не работает ни в текстовом, ни в графическом режиме. Смешно то, что загрузчик своё меню в текстовом режиме прекрасно выводит цветным. ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] releng/13.1, vt(4) kernel messages color
On Mon, May 30, 2022 at 2:37 PM Volodymyr Kostyrko wrote: > > On May 29, 2022 12:39:41 PM Anton Saietskii wrote: > > > Приветствую, товарищи. > > Пришло время обновляться и заодно окончательно переходить на vt(4). > > Для тестирования этого дела взял я VirtualBox 6.1, водрузил туда > > releng/13.1 и пошёл компилять-собирать. Однако, после перезагрузки > > меня постигло разочарование, т.к. годами работавшая в sc(4) опция по > > изменению цвета сообщений ядра и её наследник в новой консоли > > перестали работать. > > > > Изначально текст юзерленда и ядра серый. Добавил свои любымые опции: > > root@localhost:~ # config -x /boot/kernel/kernel | grep TERM > > options TERMINAL_KERN_ATTR=(FG_GREEN|BG_BLACK) > > options TERMINAL_NORM_ATTR=(FG_LIGHTGREY|BG_BLACK) > > > > Текст ядра стал вместо серого белым, а не зелёным, как я хотел. Собрал > > GENERIC с этими опциями -- ничего не изменилось. Собрал GENERIC с > > этими опциями, в точности взятыми из NOTES -- опять ничего не > > изменилось. Перепробовал все 3 контроллера видео в VBox -- > > естественно, и в этот раз ничего не изменилось. > > Получается, что при наличии к конфиге ядра опции TERMINAL_KERN_ATTR > > цвет изменяется с серого на белый вне зависимости от значения самой > > опции. > > > > Вот сижу теперь, чешу репу и думаю -- ЧЯДНТ? > > ___ > > freebsd mailing list > > freebsd@uafug.org.ua > > http://mailman.uafug.org.ua/mailman/listinfo/freebsd > > У loader.conf: > > kern.vt.color.7.rgb="#00ff00” > kern.vt.color.15.rgb="#008800” > > Десь так мабуть… Гм, так а что -- указанные опции ядра уже поломали и теперь только через редактирование палитры? А чего из NOTES тогда не убрано? Впрочем, у меня оно в виртуалке ни с опциями ядра, ни с палитрой не взлетело. Железа, на котором я бы мог видеть экран и проверить там пока нет, к сожалению. > -- https://t.me/freebsd_ua > Sphinx of black quartz judge my vow. > > ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] anacron daemon vs cron call
On 28.06.2022 19:40, Anton Saietskii wrote: > Собственно, проверил. Таки да -- anacron запускается, выполняет > задания и выходит, так что в crontab не помешает. Ещё вижу одно > преимущество скрипта перед @reboot в crontab -- в скрипте стоит > resume. Похоже, что он также будет запускаться после выхода из S3 > (поправьте, если ошибаюсь). Да. В rcorder(8) есть ссылка на acpiconf(8), где этот момент документирован. ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] AWS Tech Conference
On 28.06.2022 18:32, Valentin Nechayev wrote: > hi, > > Tue, Jun 28, 2022 at 04:14:26, eugen wrote about "Re: [freebsd] AWS Tech > Conference": > >> Jail это chroot плюс опционально виртуализированный сетевой стек >> плюс запрет руту из клетки влиять на хост. > > Судя по тому, что можно видеть в комплекте всяких cgroup, в опциях > clone и так далее, параметров сильно больше: Придумать можно неограниченное число параметров, но перечисленное ниже явно не про jail. > 6. идентификация ядра (ответ на uname) Сразу нет. Всё-таки jail это клетки над общим ядром. ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] AWS Tech Conference
On 28.06.2022 19:58, Taras Heichenko wrote: >> Насколько я ничего не понимаю, всего хватает. >> В 13.1 допилили LinuxKPI, чтобы запускать современный линуксовый userland в >> jail, >> включая Docker. Сам не пробовал. > > Вот здесь возникает вопрос: а зачем там собственно фря? Фря может исполнять фрёвый софт параллельно с линуксовым jail. ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] AWS Tech Conference
> On 28 Jun 2022, at 23:16, Eugene Grosbein wrote: > > On 28.06.2022 19:58, Taras Heichenko wrote: > >>> Насколько я ничего не понимаю, всего хватает. >>> В 13.1 допилили LinuxKPI, чтобы запускать современный линуксовый userland в >>> jail, >>> включая Docker. Сам не пробовал. >> >> Вот здесь возникает вопрос: а зачем там собственно фря? > > Фря может исполнять фрёвый софт параллельно с линуксовым jail. Да, конечно. Но это не промышленное решение. Т.е. да, можно запускать там линух, а там докер. А рядом еще маленький свечной заводик под фрей. И я даже готов согласиться, что в некоторых случаях это действительно нужно и удобно. Беда в том, что случаи действительно _некоторые_. Это не промышленное решение. Чем хороши докер с кубернетисом – подготовил нужные докер контейнеры, пристроил над этим всем кубернетис, и в таком виде сравнительно просто управлять кучей инстансов. Легко добавлять, если нужно, понижать количество, если не нужно, перемещать и т.д. Т.е. это уже где-то от массового обслуживания. Докеры с кубернетисами имеют свои недостатки, с которыми можно мириться ради тех преимуществ, которые они дают. А в таком виде – докеры под линуховым userland в jail я преимуществ как-то не особо. Т.е. это хорошо, что оно есть, но это куда-то не туда IMO. > > > ___ > freebsd mailing list > freebsd@uafug.org.ua > http://mailman.uafug.org.ua/mailman/listinfo/freebsd -- Taras Heichenko ta...@academ.kiev.ua ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
