Pull to refresh
6
0

Сетевой администратор

Send message
У меня есть клиенты с rdpwrap на 7-ке. Хоткеи работают, но я всё равно использую RDC Manager с возможностью «виртуальной» посылки 4-х самых распространённых хоткеев.
У меня KeePass работает менеджером подключений. Причем не только RDP, а вообще всех. Реализуется это через его стандартный функционал URL Overrides.
1. Как Вы, вероятно, знаете, в PostgreSQL 12 это работать не будет, т.к. в этой версии изменилась логика восстановления. Файл recovery.conf более не используется.
2. У Вас пишутся логи, когда из systemd-файла вызывается скрипт с перенаправлением?
Об этом сказано в вышеприведённой ссылке:
«Windows will always ignore networks received by split-include and request policy with destination 0.0.0.0/0 (TSr). When IPsec-SA is generated, Windows requests DHCP option 249 to which RouterOS will respond with configured split-include networks automatically.»
Маршруты можно отдать через Mode Config (Split Tunnel). Но, опять же, со стороны ОС в этом вопросе разложена туча граблей.
IKEv2 хорош, но со стороны сервера только EAP (Radius, NPS etc.) или сертификаты, обычным PSK и логин/пароль, как в IKEv1, уже не обойдёшься.
ИМХО HPET не всегда самый «крутой» event timer.
# sysctl kern.eventtimer
kern.eventtimer.periodic: 0
kern.eventtimer.timer: LAPIC
kern.eventtimer.idletick: 0
kern.eventtimer.singlemul: 2
kern.eventtimer.choice: LAPIC(600) HPET(550) HPET1(440) HPET2(440) HPET3(440) HPET4(440) HPET5(440) HPET6(440) i8254(100) RTC(0)
kern.eventtimer.et.i8254.quality: 100
kern.eventtimer.et.i8254.frequency: 1193182
kern.eventtimer.et.i8254.flags: 1
kern.eventtimer.et.RTC.quality: 0
kern.eventtimer.et.RTC.frequency: 32768
kern.eventtimer.et.RTC.flags: 17
kern.eventtimer.et.HPET6.quality: 440
kern.eventtimer.et.HPET6.frequency: 14318180
kern.eventtimer.et.HPET6.flags: 3
kern.eventtimer.et.HPET5.quality: 440
kern.eventtimer.et.HPET5.frequency: 14318180
kern.eventtimer.et.HPET5.flags: 3
kern.eventtimer.et.HPET4.quality: 440
kern.eventtimer.et.HPET4.frequency: 14318180
kern.eventtimer.et.HPET4.flags: 3
kern.eventtimer.et.HPET3.quality: 440
kern.eventtimer.et.HPET3.frequency: 14318180
kern.eventtimer.et.HPET3.flags: 3
kern.eventtimer.et.HPET2.quality: 440
kern.eventtimer.et.HPET2.frequency: 14318180
kern.eventtimer.et.HPET2.flags: 3
kern.eventtimer.et.HPET1.quality: 440
kern.eventtimer.et.HPET1.frequency: 14318180
kern.eventtimer.et.HPET1.flags: 3
kern.eventtimer.et.HPET.quality: 550
kern.eventtimer.et.HPET.frequency: 14318180
kern.eventtimer.et.HPET.flags: 7
kern.eventtimer.et.LAPIC.quality: 600
kern.eventtimer.et.LAPIC.frequency: 2893493164
kern.eventtimer.et.LAPIC.flags: 7
Сейчас в Zabbix существует ровно 2 приличных способа получить нужные имена блочных устройств для LLD:
— system.run для lsblk с выводом в json (zabbix 4.2 и шифрование до агента/прокси)
— нативная поддержка в zabbix 4.4
Все остальные поделки с userparameter и zabbix_sender должны быть списаны в утиль.

Всё ИМХО, конечно же.
Legacy protocol, который используется в версии 1.0:
This legacy authentication protocol has several weaknesses, pointed out by security export Peter Gutmann. First, data is encrypted with RSA without padding. Padding schemes are designed to prevent attacks when the size of the plaintext is not equal to the size of the RSA key. Tinc always encrypts random nonces that have the same size as the RSA key, so we do not believe this leads to a break of the security. There might be timing or other side-channel attacks against RSA encryption and decryption, tinc does not employ any protection against those. Furthermore, both sides send identical messages to each other, there is no distinction between server and client, which could make a MITM attack easier. However, no exploit is known in which a third party who is not already trusted by other nodes in the VPN could gain access. Finally, the RSA keys are used to directly encrypt the session keys, which means that if the RSA keys are compromised, it is possible to decrypt all previous VPN traffic. In other words, the legacy protocol does not provide perfect forward secrecy.


SPTPS, который используется в версии 1.1.
Самое забавное, что выход версии 1.1 был направлен именно на решение проблемы с безопасностью протокола, выявленной в версии 1.0.
Поэтому, вы себе противоречите.
+1 за версию 1.1. За всё время чтения статьи мне давал покоя вопрос «Зачем всё это, если есть tinc invite/join»? Запуск клиента — это 4 команды. Tinc join, ExperimentalProtocol yes, Subnet для текущего узла и tinc start.
Плюс tinc invite на условном «сервере».
По поводу доступности. Свежая FreeBSD:
# pkg search tinc
tinc-1.0.35_1 Virtual Private Network (VPN) daemon
tinc-devel-1.1pre17_3 Virtual Private Network (VPN) daemon
Поддерживает. Не любая модель, конечно, но поддерживает. Причем как PD, так и PSE.
Спасибо.
Текущая конфигурация сети — VPS и два Location. Все они имеют единственное подключение к провайдеру в своих городах и FreeBSD в качестве «роутерной» ОС. Сделать full-mesh для iBGP на vpn-линках труда не составляет, но кол-во Location может возрасти на 1-2 и хотелось бы сразу выбрать адекватное BGP-решение (или может на OSPF?).
И второй момент. Как я понимаю, использовать маршрутизацию через loopback-интерфейсы имеет смысл тогда, когда хотя бы на одном Location появится подключение ко второму провайдеру?
Огромная благодарность автору! Очень полезная и интересная статья.
Можете показать примерный конфиг bird, который работает на PC-роутере со стороны «клиента», и который не только принимает актуальные маршруты с VPS, но и анонсирует две серых сетки (пусть это будут 172.16.16.0/24 и 10.0.2.0/24)?
Спасибо за ваш труд.
ЕМНИП с версии 10.1 во FreeBSD уже есть «родной» iSCSI-target (CTL — CAM Target Layer), поэтому использование istgt от уважаемого Д.Аоямы совсем не очевидно и, паче чаяния, не обязательно.
Принцип атаки, осуществляемой ТТК, довольно подробно описан здесь (способ с TCP-битом RST). Т.к. ТТК является провайдером доступа в Интернет, то для него осуществлять подобный вид MITM-атаки не представляет никакой технической или организационной сложности.
Совершенно верно, если выставлены провайдерские DNS, то картина, возможно, именно такая. Но ТТК не подменяет ответы от других публично доступных DNS-серверов, а уж разрулить запросы по форвардерам умеет любой кеширующий DNS, будь то unbound, bind или др. Разумеется, удобнее всего делать это на границе подконтрольной вам сети, например, на домашнем роутере.
Для борьбы с подменой вообще всех DNS-ответов существует dnscrypt.
Пакет от заблокированного ресурса вам наверное прилетит, только вы его уже не будете ждать.

После провайдерского FPA ни ACK, ни HTTP-ответ от заблокированного ресурса уже не приходят. Специально tcpdump-ом искал их на внешнем интерфейсе роутера.
На маршрутизаторе оператора зеркалится трафик на небольшой сервачок и если система увидит запрос к ресурсу из списка — она вот такое вытворяет.

ЕМНИП трафик зеркалируется только для СОРМа, блокировки каждый провайдер реализует в меру своих технических возможностей. У ТТК возможностей хоть отбавляй, поэтому не удивлюсь, если они под свой DPI зарегистрировали отдельную AS и глобально сливают туда весь трафик к заблокированным ресурсам. Для них — это проще всего.
У нас Google DNS так же заворачиваются на Filter-gw, но ответы не подменяются:
# host rutracker.org
rutracker.org has address 195.82.146.214
rutracker.org has IPv6 address 2a02:4680:22::214
rutracker.org mail is handled by 5 mail.rutracker.org.
# host rutracker.org 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:
rutracker.org has address 195.82.146.214
rutracker.org has IPv6 address 2a02:4680:22::214
rutracker.org mail is handled by 5 mail.rutracker.org.

Первый запрос ходит не через провайдерский DNS, а через unbound с такой записью:
forward-zone:
    name: "rutracker.org"
    forward-addr: 77.88.8.8
    forward-addr: 193.58.251.251

Information

Rating
Does not participate
Location
Ульяновск, Ульяновская обл., Россия
Registered
Activity