Хорошим инструментом для просмотра различий является diff
, вам просто нужно немного поиграть с его нетривиальными опциями, чтобы правильно оформить вывод:
diff --unchanged-group-format= --new-group-format="%>" a b.txt
Если a
не является файлом по трубе, то вместо него следует использовать -
:
echo 'apple
car' | diff --unchanged-group-format= --new-group-format='%>' - b.txt
Выход:
apple
banana
dog
Или, если вам не важен контекст появления строки в файле:
echo 'apple
car' | sort | diff --unchanged-group-format= --new-group-format='%>' - <(sort b.txt)
Вы говорите о слабой/сильной модели хоста , а в Linux по умолчанию используется слабая.
Is there a way to check if a packet intended to interface eth1 did reach that interface?
Я бы сказал, что брандмауэр позволяет поставить такое ограничение.
I have cases where a packet arrives on an interface of a host (the first one on its way) but does not seem to reach the intended interface (the actual application is not brought up). Such a test would ensure that the firewalling/forwarding is OK and that the problem is elsewhere (in the configuration of the app, a bug in the app, etc)
Ранее в своем примере вы упомянули ICMP. Что плохого в том, чтобы использовать именно его, чтобы проверить, есть ли связь на самом деле?
Кроме того, на данный момент вы довольно близко подошли к практике использования петлевых интерфейсов для сервисов — в основном они используются в сочетании с динамической маршрутизацией, но основная идея довольно проста :не имеет значения, какой интерфейс запрашивал. пришло, важно только то, что оно вообще нашло свой путь, и ответ также может быть отправлен. Интерфейсы Loopback никогда не отключаются, если об этом не сообщается вручную — «настоящие» интерфейсы OTOH могут изменить свое состояние из-за потери связи и так далее.
В Linux входящий пакет маршрутизируется путем проверки того, должен ли пакет обрабатываться локальным компьютером или нет. Если это необходимо, он обрабатывается напрямую, без предварительной маршрутизации через «правильный интерфейс». IP-адрес — это своего рода псевдоним для машины, и не имеет значения, на какой интерфейс пришел пакет.
То же самое происходит, если вы выполняетеtelnet 10.0.1.1
-локально, он отображается не на eth1
, а на lo
, который обрабатывает все пакеты, идущие с локальной машины на себя.
Однако для исходящих пакетов имеет значение, к какому интерфейсу принадлежит адрес.Ядро сначала решает, как направить пакет, а затем выбирает лучший исходный IP-адрес для пакетов на основе этого.
Если вам нужно увидеть «все пакеты» с tcpdump
, вы можете сделать tcpdump -i any icmp
. Он не покажет вам интерфейс (с ), но вы увидите все пакеты, идущие, например. 10.0.1.1
.