При возникновении сетевых проблем, наилучшим сценарием обнаружения причин и дальнейшее их исправление - следование модели osi
1ый уровень, а вообще линк есть ? (есть) 2ой, ip адрес есть (есть), в arp mac адреса локальной сети есть ? 3ий ping?, traceroute? - и сразу все становится понятно (wg перенаправляет весь трафик в свои интерфейсы) Далее включаем мозг, читаем документацию и решаем проблему.
Ок, сейчас без обид и пр. 1. вы не понимаете модель OSI и по этой причине начали troubleshooting не с того уровня OSI. 2. не имеет смысла " предполагать что я прав" - см. п.1 3. Ваша попытка(пост) а-ля troubleshooting`а не поможет никому и ни в чем, а только запутает и даст превратное представление. 4. потому что это азы ip маршрутизации, на хабре куча статей есть, зачем периливать из пустого в порожние ? )
Оставьте кесарю кесарево - вы не сетевик, вы пограммист/сисадмин. Сетевики поржали и закрыли пост(ну парочка отписалась)
Ваш пост о том как не надо делать, а не о том как надо. Что-бы не засорять каметы не весь чем - в личку.
Видимо именно из-за отсутствия знаний, вы выбрали неправильный путь и начали ходить по граблям, при этом не получив каких либо нужных знаний и потратив свое время на фиг знает что.
Ещё раз, "если что-то не получается" - rtfm.
Коротко: ваша ситуация не стоила написания этого поста, ну или поста о том "как не зная сетевой части современных OS долго и упорно ходить по граблям"
Ну так чисто для справки, писать маршрут к сети 192.168.1.0/24 ( условно) через какой либо gw имея адрес на интерфейсе в той же сети просто бессмысленно)
Не следует искать черную кошку в темной комнате, особенно когда там не нет ))
Для справки в виде ip стэк целого тянутый из bsd.
То есть абсолютно точно такой-же как и любом *nix.
А все ваши проблемы, с которыми вы столкнулись просто от недостатка знаний в сетевых технологиях.
Забавно, что получив первую полезную информацию "без vpn все работает, а с ним нет" вы полезли не в настройки самого vpn клиента, а в систему маршрутизации ОС. Посчитав видимо, что если это всегда, значит там и накосячили горе программисты )))
Случаи бывают разные: от ... и до ...)) Проверять какой-либо критерий по некоему другому косвенному критерию - прямая дорога к длительному траблшутингу )
Существенный косяк в проверке файлов локальных сертификатов, а именно по времени создания самого файла. Более правильный путь - openssl проверяет expiration date самого сертификата и если ему осталось менее 30 дней запускает renewal процесс для этого сертификата.
Это особенно полезно когда у тебя стопка wildcard сертификатов для разных доменов.
Какие-то совсем неудачные решения учитывая недостаток ресурсов у ESP32 Будет правильнее (с моей точки зрения): - хранить статическую html zip-ованую страницу на fs контроллера - в самом html описывать всю логику работы на javascript - принимать и отправлять данные на МК через web-socket в формате json например. Такой подход позволит существенно сократить использование памяти у МК, снимет с него нагрузку по генерации html, сократит объем передаваемых данных и ускорит скорость их обработки.
опять полное непонимание:"Когда IPsec используется в сочетании с GRE, это всегда осуществляется в туннельном режиме, что приводит к созданию не двух, а трех IP-заголовков. " Нет, в классическом применение ipsec over gre, ipsec использует в transport mode, ipsec tunnel mode необходимо использовать если одна сторона находится за NAT. Если честно, я бы удалил эту статью, тем более с тегом CCNP. Это какое-то позорище просто....
Тогда вообще непонятно, зачем вы пишете "... я отмечаю отсутствие реального практического применения GRE (Generic Routing Encapsulation), поскольку существуют более эффективные альтернативы." и не приводите более эффективных альтернатив. кстати для чего более эффективных ? Вы правде не знаете про "реальное практическое применение GRE" , или вся статья написана каким-то ИИ ?)
Дело в основном заключается в том, что большинство сотрудников ИБ имеют крайне низкую квалификацию. Многие понятия не имеют какой протокол к какому уровню OSI относится, не знают чем tcp от udp отличается, про маршрутизацию вообще лучше не вспоминать... )
При возникновении сетевых проблем, наилучшим сценарием обнаружения причин и дальнейшее их исправление - следование модели osi
1ый уровень, а вообще линк есть ? (есть)
2ой, ip адрес есть (есть), в arp mac адреса локальной сети есть ?
3ий ping?, traceroute? - и сразу все становится понятно (wg перенаправляет весь трафик в свои интерфейсы)
Далее включаем мозг, читаем документацию и решаем проблему.
Ок, сейчас без обид и пр.
1. вы не понимаете модель OSI и по этой причине начали troubleshooting не с того уровня OSI.
2. не имеет смысла " предполагать что я прав" - см. п.1
3. Ваша попытка(пост) а-ля troubleshooting`а не поможет никому и ни в чем, а только запутает и даст превратное представление.
4. потому что это азы ip маршрутизации, на хабре куча статей есть, зачем периливать из пустого в порожние ? )
Оставьте кесарю кесарево - вы не сетевик, вы пограммист/сисадмин.
Сетевики поржали и закрыли пост(ну парочка отписалась)
Ваш пост о том как не надо делать, а не о том как надо.
Что-бы не засорять каметы не весь чем - в личку.
Видимо именно из-за отсутствия знаний, вы выбрали неправильный путь и начали ходить по граблям, при этом не получив каких либо нужных знаний и потратив свое время на фиг знает что.
Ещё раз, "если что-то не получается" - rtfm.
Коротко: ваша ситуация не стоила написания этого поста, ну или поста о том "как не зная сетевой части современных OS долго и упорно ходить по граблям"
Ну так чисто для справки, писать маршрут к сети 192.168.1.0/24 ( условно) через какой либо gw имея адрес на интерфейсе в той же сети просто бессмысленно)
Не следует искать черную кошку в темной комнате, особенно когда там не нет ))
Для справки в виде ip стэк целого тянутый из bsd.
То есть абсолютно точно такой-же как и любом *nix.
А все ваши проблемы, с которыми вы столкнулись просто от недостатка знаний в сетевых технологиях.
Забавно, что получив первую полезную информацию "без vpn все работает, а с ним нет" вы полезли не в настройки самого vpn клиента, а в систему маршрутизации ОС. Посчитав видимо, что если это всегда, значит там и накосячили горе программисты )))
вот абсолютно в точку!!!
Достаточно было просто прочитать документацию к wg ))
"Просто душит смех"(с)
За столько лет не понять как работают блокировки "это просто, что-то с чем-то" (с)
)))
Случаи бывают разные: от ... и до ...))
Проверять какой-либо критерий по некоему другому косвенному критерию - прямая дорога к длительному траблшутингу )
Существенный косяк в проверке файлов локальных сертификатов, а именно по времени создания самого файла. Более правильный путь - openssl проверяет expiration date самого сертификата и если ему осталось менее 30 дней запускает renewal процесс для этого сертификата.
Это особенно полезно когда у тебя стопка wildcard сертификатов для разных доменов.
неверное все таки manual/static keying ?)
Проверяли, см. мое предыдущее сообщение)
Уже потрогали ) не сам proto 50, а механизм обмена ключей ike/ikev2 (udp 500/4500)
Блокируются или будут заблокированы со временем все трансграничные vpn соединения основанные на tcp/udp.
Ставиться куча ненужного софта, вернее смысл его установки неясен от слова совсем.
Чем больше запущенных процессов, тем больше потенциальных уязвимостей.
Какие-то совсем неудачные решения учитывая недостаток ресурсов у ESP32
Будет правильнее (с моей точки зрения):
- хранить статическую html zip-ованую страницу на fs контроллера
- в самом html описывать всю логику работы на javascript
- принимать и отправлять данные на МК через web-socket в формате json например.
Такой подход позволит существенно сократить использование памяти у МК, снимет с него нагрузку по генерации html, сократит объем передаваемых данных и ускорит скорость их обработки.
опять полное непонимание:"Когда IPsec используется в сочетании с GRE, это всегда осуществляется в туннельном режиме, что приводит к созданию не двух, а трех IP-заголовков. "
Нет, в классическом применение ipsec over gre, ipsec использует в transport mode, ipsec tunnel mode необходимо использовать если одна сторона находится за NAT.
Если честно, я бы удалил эту статью, тем более с тегом CCNP.
Это какое-то позорище просто....
Статья вводит в заблуждение читателей и содержит многочисленные фактические ошибки.
Я подробно их расписал в личном сообщении.
Тогда вообще непонятно, зачем вы пишете "... я отмечаю отсутствие реального практического применения GRE (Generic Routing Encapsulation), поскольку существуют более эффективные альтернативы."
и не приводите более эффективных альтернатив.
кстати для чего более эффективных ?
Вы правде не знаете про "реальное практическое применение GRE" , или вся статья написана каким-то ИИ ?)
Мне кажется автор не понимает для чего, когда и как используятся протоколы семейства xGRE.
(Gre, egre, nvgre, etc)
И совсем непонятно, зачем в bgp применяются фильтры.
Дело в основном заключается в том, что большинство сотрудников ИБ имеют крайне низкую квалификацию. Многие понятия не имеют какой протокол к какому уровню OSI относится, не знают чем tcp от udp отличается, про маршрутизацию вообще лучше не вспоминать... )