Upgrage c opensuse leap 15.3 до 15.4

Sergej Solowjow написал(а) к All в Sep 22 16:29:38 по местному времени:

Привет, All!

Всем привет.
Ну, в общем "проапрейгился". И всё бы ничего, но... на стало интернета. Рутер не пингуется, хотя комп по dhcp получил именно тот адрес, который необходим. Если прописываю DNS, ну, к примеру, 8.8.8.8, интернет появляется. Но рутер не пингуется.


ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
validlft forever preferredlft forever
inet6 ::1/128 scope host
validlft forever preferredlft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWERUP> mtu 1500 qdisc pfifofast state UP group default qlen 1000
link/ether 0c:9d:92:10:fc:36 brd ff:ff:ff:ff:ff:ff
altname enp4s0
inet 192.168.0.101/24 brd 192.168.0.255 scope global eth0
validlft forever preferredlft forever
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWERUP> mtu 1500 qdisc pfifofast state UNKNOWN group default qlen 500
link/none
inet 10.20.10.1 peer 10.20.10.2/32 scope global tun0
validlft forever preferredlft forever

таблица маршрутизации выглядела изначально так:

ip route show
default via 192.168.0.1 dev eth0 proto dhcp
10.20.10.0/24 via 10.20.10.2 dev tun0
10.20.10.2 dev tun0 proto kernel scope link src 10.20.10.1
192.168.0.0/24 via 10.20.10.2 dev tun0


Пока не пробросил внагляк маршруты

ip route show
default via 192.168.0.1 dev eth0 proto dhcp
10.20.10.0/24 via 10.20.10.2 dev tun0
10.20.10.2 dev tun0 proto kernel scope link src 10.20.10.1
192.168.0.0/24 via 10.20.10.2 dev tun0
192.168.0.1 dev eth0 scope link
192.168.0.161 dev eth0 scope link

не заработало.

192.168.0.161 - это смарт TV, который мне по dlna кинушки показывает. Без этого маршрута не заработал. Хотя раньше работало всё. Никакие маршруты специально пробрасывать не приходилось.

Что ещё? Firewall отключен, secureboot - отключен.

Что-то я в непонятках. Торможу. Причем такое ощущение, что где-то что-то элементарное пропускаю :-(

Что бы это могло быть?

Спасибо.

С наилучшими пожеланиями, Sergej.

--- GoldED+/LNX 1.1.5-b20170303

Dmitriy Romanov написал(а) к Sergej Solowjow в Sep 22 08:49:36 по местному времени:


Приветики, Sergej!


Писал как-то Sergej Solowjow к All примерно 16 Сен 22 в 16:29
А я смотрю и фигею.



а каким образомо вот это

SS> 2: eth0: <BROADCAST,MULTICAST,UP,LOWERUP> mtu 1500 qdisc pfifofast
SS> state
SS> UP group default qlen 1000
SS> link/ether 0c:9d:92:10:fc:36 brd ff:ff:ff:ff:ff:ff
SS> altname enp4s0
SS> inet 192.168.0.101/24 brd 192.168.0.255 scope global eth0
SS> validlft forever preferredlft forever

совместимо с вот этим
SS> 192.168.0.0/24 via 10.20.10.2 dev tun0
?

У тебя локальная подсеть 192.168.0.0/24, а ты на нее маршрут в тунель прописал.


SS> Пока не пробросил внагляк маршруты

SS> 192.168.0.0/24 via 10.20.10.2 dev tun0
SS> 192.168.0.1 dev eth0 scope link
SS> 192.168.0.161 dev eth0 scope link
SS> не заработало.
Поздравляю, ты поставил костыли.


SS> Что-то я в непонятках. Торможу. Причем такое ощущение, что где-то
SS> что-то
SS> элементарное пропускаю :-(
SS> Что бы это могло быть?
Убери процитированный маршрут в тунель, и будет счастье. А если там есть адреса из этой сети - то меняй адресацию.

На сем разрешите письмо закончить. Elec (RA2FDR)
--- NoSFeRaTU's GoldED+/W32-MINGW 1.1.5-b20090603

Sergej Solowjow написал(а) к Dmitriy Romanov в Sep 22 09:43:12 по местному времени:


* Ответ на сообщение из carbonArea (Карбонка не пустая).

Привет, Dmitriy!

17 сен 22 08:49, Dmitriy Romanov -> Sergej Solowjow:

DR> Приветики, Sergej!


DR> Писал как-то Sergej Solowjow к All примерно 16 Сен 22 в 16:29
DR> А я смотрю и фигею.



DR> а каким образомо вот это

SS>> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
SS>> pfifo_fast state UP group default qlen 1000
SS>> link/ether 0c:9d:92:10:fc:36 brd ff:ff:ff:ff:ff:ff
SS>> altname enp4s0
SS>> inet 192.168.0.101/24 brd 192.168.0.255 scope global eth0
SS>> validlft forever preferredlft forever

DR> совместимо с вот этим

SS>> 192.168.0.0/24 via 10.20.10.2 dev tun0

DR> ?

DR> У тебя локальная подсеть 192.168.0.0/24, а ты на нее маршрут в тунель
DR> прописал.

А Это наказуемо? В смысле раньше нормально работало. И таки да, я со смартфона по VPN периодически (давно) на комп залезаю.

SS>> Пока не пробросил внагляк маршруты

SS>> 192.168.0.0/24 via 10.20.10.2 dev tun0
SS>> 192.168.0.1 dev eth0 scope link
SS>> 192.168.0.161 dev eth0 scope link
SS>> не заработало.

DR> Поздравляю, ты поставил костыли.


Дык я не собирался, но иначе не осилил :-) Собственно поэтому за помощью и обратился.

SS>> Что-то я в непонятках. Торможу. Причем такое ощущение, что где-то
SS>> что-то
SS>> элементарное пропускаю :-(
SS>> Что бы это могло быть?

DR> Убери процитированный маршрут в тунель, и будет счастье. А если там
DR> есть адреса из этой сети - то меняй адресацию.

Может я что сделал и неправильно, но почему ж раньше работало (пусть даже и не по феншую)

С наилучшими пожеланиями, Sergej.

--- GoldED+/LNX 1.1.5-b20170303

Dmitriy Romanov написал(а) к Sergej Solowjow в Sep 22 21:24:38 по местному времени:


Приветики, Sergej!


Писал как-то Sergej Solowjow к Dmitriy Romanov примерно 17 Сен 22 в 09:43
А я смотрю и фигею.




DR>> а каким образомо вот это

SS>>> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
SS>>> pfifo_fast state UP group default qlen 1000
SS>>> link/ether 0c:9d:92:10:fc:36 brd ff:ff:ff:ff:ff:ff
SS>>> altname enp4s0
SS>>> inet 192.168.0.101/24 brd 192.168.0.255 scope global eth0
SS>>> validlft forever preferredlft forever
DR>> совместимо с вот этим
SS>>> 192.168.0.0/24 via 10.20.10.2 dev tun0
DR>> ?
DR>> У тебя локальная подсеть 192.168.0.0/24, а ты на нее маршрут в тунель
DR>> прописал.
SS> А Это наказуемо? В смысле раньше нормально работало. И таки да, я со
SS> смартфона по VPN периодически (давно) на комп залезаю.
Если ты хочешь, чтобы по всем подсетям была прозрачная адресация, то по крайней мере они не должны пересекаться. А если
прописан машрут
SS>>> 192.168.0.0/24 via 10.20.10.2 dev tun0
значит наверное хочешь. Так что поменяй адресацию либо в подсети за eth0, либо в той, которая живет за интерфейсом
tun0, к которой стучишься через этот маршрут.
Это тебе еще крупно повезло, что линукс - гибкая системе и легко принимает кривизну рук администратора. В винде бы
например такая конструкция вообще не заработала.


SS>>> Что-то я в непонятках. Торможу. Причем такое ощущение, что где-то
SS>>> что-то
SS>>> элементарное пропускаю :-(
SS>>> Что бы это могло быть?
DR>> Убери процитированный маршрут в тунель, и будет счастье. А если там
DR>> есть адреса из этой сети - то меняй адресацию.
SS> Может я что сделал и неправильно, но почему ж раньше работало (пусть
SS> даже и не по феншую)
"а я вот раньше всегда на красный свет переходил, и все было хорошо. А тут пошел - а меня задавили".

На сем разрешите письмо закончить. Elec (RA2FDR)--- NoSFeRaTU's GoldED+/W32-MINGW 1.1.5-b20090603
---

Sergej Solowjow написал(а) к Dmitriy Romanov в Sep 22 00:43:18 по местному времени:

Нello, Dmitriy Romanov.
On 17.09.22 21:24 you wrote:

DR> Приветики, Sergej!
SS>> А Это наказуемо? В смысле раньше нормально работало. И таки да, я
SS>> со смартфона по VPN периодически (давно) на комп залезаю.
DR> Если ты хочешь, чтобы по всем подсетям была прозрачная адресация,
DR> то по крайней мере они не должны пересекаться.

Погоди, что-то я не очень понимаю, что значит "не должны пересекаться"?
Что экстраординарного в желании связать две локалки?
Какая разница за каким интерфейсом? VPN в конце концов просто вируальна "проволока". Нет?


А если
DR> прописан машрут
SS>>>> 192.168.0.0/24 via 10.20.10.2 dev tun0
DR> значит наверное хочешь.

Да, хочу.

Так что поменяй адресацию либо в подсети за eth0, либо в той, которая живет за интерфейсом
DR> tun0, к которой стучишься через этот маршрут.

Да не стучусь я в нее. Это она стучится в мою локалку. Этот маршрут прописывает openvpn Server. Если я его (сервер) отключу, то и маршрут из таблицы пропадёт. Проверить - дело пяти минут, но я сейчас не дома. Завтра попробую. В результате (вернее в отсутствии оного) я практически уверен.


DR> Это тебе еще крупно повезло, что линукс - гибкая системе и легко
DR> принимает кривизну рук администратора. В винде бы например такая
DR> конструкция вообще не заработала.
SS>>>> Что-то я в непонятках. Торможу. Причем такое ощущение, что
SS>>>> где-то что-то элементарное пропускаю :-( Что бы это могло быть?
DR>>> Убери процитированный маршрут в тунель, и будет счастье. А если
DR>>> там есть адреса из этой сети - то меняй адресацию.
SS>> Может я что сделал и неправильно, но почему ж раньше работало
SS>> (пусть даже и не по феншую)
DR> "а я вот раньше всегда на красный свет переходил, и все было
DR> хорошо. А тут пошел - а меня задавили".

Спасибо, что откликнулся, за помощь, но вот последняя фраза, она сильно конструктивна.

PS Слышал когда-то, полагаю у Лукьяненко, что сравнения и метафоры идут в ход, когда (не в обиду тебе) сказать нечего?
:-)

Ладно, ещё раз спасибо.


DR> На сем разрешите письмо закончить. Elec (RA2FDR)---
DR> NoSFeRaTU's GoldED+/W32-MINGW 1.1.5-b20090603
DR> --- * Origin: В свинарнике не стыдно быть свиньей (2:6078/1)

--
С наилучшими пожеланиями!
Сергей
--- Нotdoged/2.13.5/Android

Eugene Grosbein написал(а) к Dmitriy Romanov в Sep 22 07:44:16 по местному времени:

17 сент. 2022, суббота, в 21:24 NOVT, Dmitriy Romanov написал(а):

DR> Это тебе еще крупно повезло, что линукс - гибкая системе и легко принимает
DR> кривизну рук администратора. В винде бы
DR> например такая конструкция вообще не заработала.

Работает такая конструкция в винде, как минимум с Win10, а то и раньше,
называется ForcedTunnel: при создании VPN-туннеля штатными средствами винды
и в настройках VPN-подключения стоит галка "использовать основной
шлюз в удаленной сети", то если IP-пакет идёт к IP-адресу из локалки,
но в ARP-таблице этого адреса нет и нет ответов на ARP-запросы,
то винда автоматически создаёт "статическую" запись для такого IP-адреса
в туннель.

Таким образом, даже если есть формальный конфликт адресации между локалкой местной
и удалённой сетью, доступной через VPN, но в удаленной сети есть хосты
с IP-адресами, не используемыми в местной локалке, то связь с ними будет,
если удалённый VPN-сервер тоже выдаёт на туннель не конфликтующие IP-адреса
(например, совсем из другого диапазона) и роутит ответные пакеты обратно
в туннель.

Например, для большей ясности: у юзера домашний роутер 192.168.1.1/24
и Win10 с адресом 192.168.1.5 и нет хостов с адресами 192.168.1.6
и 192.168.1.11. Юзер поднимает такой VPN-туннель (для определенности, pptp)
до удаленной сети, где есть роутер 192.168.1.6/23, который на свою сторону
туннеля назначает адрес 192.168.1.6, а юзеру выдаёт адрес 192.168.16.100.

И тогда юзер с этого адреса вполне успешно подключается к RDP-серверу
в удаленной сети с адресом 192.168.1.11, который ответные пакеты шлет
через роутер 192.168.1.6, который их роутит обратно в туннель.
Всё работает, несмотря на явный конфликт адресации.

Eugene
--- slrn/1.0.3 (FreeBSD)

Sergej Solowjow написал(а) к Eugene Grosbein в Sep 22 06:06:06 по местному времени:

Нello, Eugene Grosbein.
On 18.09.22 07:44 you wrote:

DR>> Это тебе еще крупно повезло, что линукс - гибкая системе и легко
DR>> принимает кривизну рук администратора. В винде бы например такая
DR>> конструкция вообще не заработала.
EG> Работает такая конструкция в винде, как минимум с Win10, а то и
EG> раньше, называется ForcedTunnel: при создании VPN-туннеля штатными
EG> средствами винды и в настройках VPN-подключения стоит галка
EG> "использовать основной шлюз в удаленной сети", то если IP-пакет
EG> идёт к IP-адресу из локалки, но в ARP-таблице этого адреса нет и
EG> нет ответов на ARP-запросы, то винда автоматически создаёт
EG> "статическую" запись для такого IP-адреса в туннель. Таким
EG> образом, даже если есть формальный конфликт адресации между
EG> локалкой местной и удалённой сетью, доступной через VPN, но в
EG> удаленной сети есть хосты с IP-адресами, не используемыми в
EG> местной локалке, то связь с ними будет, если удалённый VPN-сервер
EG> тоже выдаёт на туннель не конфликтующие IP-адреса (например,
EG> совсем из другого диапазона) и роутит ответные пакеты обратно в
EG> туннель. Например, для большей ясности: у юзера домашний роутер
EG> 192.168.1.1/24 и Win10 с адресом 192.168.1.5 и нет хостов с
EG> адресами 192.168.1.6 и 192.168.1.11. Юзер поднимает такой
EG> VPN-туннель (для определенности, pptp) до удаленной сети, где есть
EG> роутер 192.168.1.6/23, который на свою сторону туннеля назначает
EG> адрес 192.168.1.6, а юзеру выдаёт адрес 192.168.16.100. И тогда
EG> юзер с этого адреса вполне успешно подключается к RDP-серверу в
EG> удаленной сети с адресом 192.168.1.11, который ответные пакеты
EG> шлет через роутер 192.168.1.6, который их роутит обратно в
EG> туннель. Всё работает, несмотря на явный конфликт адресации.

Отлично.
Только где у меня конфликт то?


--
С наилучшими пожеланиями!
Сергей
--- Нotdoged/2.13.5/Android

Sergej Solowjow написал(а) к Sergej Solowjow в Sep 22 08:33:56 по местному времени:

Am 18.09.2022 um 00:43 schrieb Sergej Solowjow:
SS> Нello, Dmitriy Romanov.
SS> On 17.09.22 21:24 you wrote:
DR>> Приветики, Sergej!
SS>>> А Это наказуемо? В смысле раньше нормально работало. И
SS>>> таки да, я со смартфона по VPN периодически (давно) на
SS>>> комп залезаю.
DR>> Если ты хочешь, чтобы по всем подсетям была прозрачная
DR>> адресация, то по крайней мере они не должны пересекаться.
SS> Погоди, что-то я не очень понимаю, что значит "не должны
SS> пересекаться"? Что экстраординарного в желании связать две
SS> локалки? Какая разница за каким интерфейсом? VPN в конце концов
SS> просто вируальна "проволока". Нет? А если
DR>> прописан машрут
SS>>>>> 192.168.0.0/24 via 10.20.10.2 dev tun0
DR>> значит наверное хочешь.
SS> Да, хочу.
SS> Так что поменяй адресацию либо в подсети за eth0, либо в той,
SS> которая живет за интерфейсом
DR>> tun0, к которой стучишься через этот маршрут.
SS> Да не стучусь я в нее. Это она стучится в мою локалку. Этот
SS> маршрут прописывает openvpn Server. Если я его (сервер)
SS> отключу, то и маршрут из таблицы пропадёт. Проверить - дело пяти минут,
SS> но я сейчас не дома. Завтра попробую. В результате (вернее в отсутствии
SS> оного) я практически уверен.
DR>> Это тебе еще крупно повезло, что линукс - гибкая системе и
DR>> легко принимает кривизну рук администратора. В винде бы
DR>> например такая конструкция вообще не заработала.
SS>>>>> Что-то я в непонятках. Торможу. Причем такое
SS>>>>> ощущение, что где-то что-то элементарное
SS>>>>> пропускаю :-( Что бы это могло быть?
DR>>>> Убери процитированный маршрут в тунель, и будет
DR>>>> счастье. А если там есть адреса из этой сети - то
DR>>>> меняй адресацию.
SS>>> Может я что сделал и неправильно, но почему ж раньше
SS>>> работало (пусть даже и не по феншую)
DR>> "а я вот раньше всегда на красный свет переходил, и все
DR>> было хорошо. А тут пошел - а меня задавили".
SS> Спасибо, что откликнулся, за помощь, но вот последняя фраза,
SS> она сильно конструктивна. PS Слышал когда-то, полагаю у
SS> Лукьяненко, что сравнения и метафоры идут в ход, когда (не в
SS> обиду тебе) сказать нечего? :-) Ладно, ещё раз спасибо.


Э... отвечая на своё сообщение обращаюсь к Dmitriy Romanov.
Приношу свои извинения. "Был неправ, вспылил"(С). Поменял настройки
openvpn сервера.
Помогло.

Нынче
ip route show
default via 192.168.0.1 dev eth0 proto dhcp
10.20.10.0/24 via 10.20.10.2 dev tun0
10.20.10.2 dev tun0 proto kernel scope link src 10.20.10.1

И всё работает. Значит я много лет назад не разобрался до конца, а
работоспособность (почему?) системы не сподвигла меня к дальнейшим
разбирательствам.

Спасибо ещё раз.



--
С наилучшими пожеланиями, Sergej
--- InterSquish NNTP Server/FTN Gate