Не удается проверить связь между интерфейсами на одном устройстве в одной сети
Есть устройство, назовем его 1, в сети A
Устройство 1 имеет два интерфейса, eth5 и eth7
Есть устройство 2 в сети A
pinging от eth5 к устройству 2 works
Ping от eth7 к устройству 2 works
Устройство 2 может ping eth5 и eth7
НО, pinging от eth5 к
[root@ipfrmk /]# ping -I eth5 192.168.10.42
PING 192.168.10.42 (192.168.10.42) from 192.168.10.43 eth5: 56(84) bytes of data.
^C
--- 192.168.10.42 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2006ms
и
[root@ipfrmk /]# ping -I eth7 192.168.10.43
PING 192.168.10.43 (192.168.10.43) from 192.168.10.42 eth7: 56(84) bytes of data.
^C
--- 192.168.10.43 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 1999ms
Почему я не могу выполнить эхо-тестирование между двумя интерфейсами, которые оба находятся на устройстве 1 которые оба подключены к сети A?
Я могу выполнить эхо-тестирование других устройств в сети A, но я не могу выполнить эхо-тестирование интерфейсов соответственно.
Возможно, статический маршрут для каждого интерфейса?
Я попробовал следующую команду без удачи..
ip route add 192.168.0.0/16 via 192.168.10.42 dev eth5
Вывод
[root@ipfrmk /]# ping -I eth5 192.168.10.42
PING 192.168.10.42 (192.168.10.42) from 192.168.10.43 eth5: 56(84) bytes of data.
From 192.168.10.43 icmp_seq=1 Destination Host Unreachable
From 192.168.10.43 icmp_seq=2 Destination Host Unreachable
From 192.168.10.43 icmp_seq=3 Destination Host Unreachable
^C
--- 192.168.10.42 ping statistics ---
6 packets transmitted, 0 received, +3 errors, 100% packet loss, time 5002ms
pipe 3
Должно быть что-то, чего мне не хватает?
[root@ipfrmk /]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth5
192.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth7
192.168.0.0 192.168.10.42 255.255.0.0 UG 0 0 0 eth5
Для первого возвращается:
Non-authoritative answer:
YAHOO.COMYAHOO.COMOO.COM MX preference = 5, mail exchanger = mail.h-email.net
Также если вы просто дублируете tld как
C:\Users\dmorri>nslookup -type=mx gmail.com.com.com.com.
Вы получаете нечетный обменник почты:
Non-authoritative answer:
gmail.com.com.com.com MX preference = 10, mail exchanger = mx203.inbound-mx.net
gmail.com.com.com.com MX preference = 10, mail exchanger = mx203.inbound-mx.org
Как вы собираетесь знать, когда его действительно недействительный домен?
Мы не хотим, чтобы домен выглядел действительным, когда его действительно нет!
Я не знаю, есть ли на самом деле так много "почему", чтобы говорить об этом, вероятно, больше изменения перспективы, чтобы увидеть это таким, какое оно есть.
Кто-то зарегистрировал comoo.com, кто-то зарегистрировал com.com.
Эти домены существуют в реальном мире, и хотя вам они явно не нравятся, это не делает их недействительными в каком-либо техническом смысле.
Как и в случае с любым доменом, владелец может добавить любые записи, которые ему нравятся (в вашем примере для поддоменов это.)
Ответ довольно прост.
Доменное имя yahoo.comyahoo.comoo.com принадлежит владельцам comoo.com , поэтому эти люди могут делать с ним все, что захотят. Причина того, что yahoo.comyahoo.comoo.com возвращает запись MX, заключается в том, что владельцы comoo.com решили заставить его это сделать.
Точно так же доменное имя gmail.com.com.com.com принадлежит владельцам com.com , и эти люди могут делать с ним все, что захотят. Они решили заставить gmail.com.com.com возвращать запись MX.
Я не уверен, почему вы думаете, что эти доменные имена недействительны, или что здесь есть какая-то проблема. Эти доменные имена полностью действительны, и это не проблема. Все работает именно так, как должно.
Возможно, вы думаете, что первая часть доменного имени является наиболее важной частью, а последние части не имеют большого значения. На самом деле все наоборот: последние части наиболее значимы, а первая часть наименее значима.
Это похоже на то, как если вы отправите письмо в Мичиган-Сити, штат Индиана, оно отправится в штат Индиана, а не в штат Мичиган. Тот факт, что адрес начинается со слова «Мичиган», не имеет значения, потому что наиболее значимая часть адреса - это конец, а не начало.
Вы спрашиваете о другом домене:
# dig YAHOO.COMYAHOO.COMOO.COM MX @9.9.9.9
; <<>> DiG 9.16.8 <<>> YAHOO.COMYAHOO.COMOO.COM MX @9.9.9.9
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5554
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;YAHOO.COMYAHOO.COMOO.COM. IN MX
;; ANSWER SECTION:
YAHOO.COMYAHOO.COMOO.COM. 3595 IN MX 5 mail.h-email.net.
;; Query time: 16 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: (...) 2021
;; MSG SIZE rcvd: 85
Вы получаете ответ DNS для почтового обмена для COMOO.COM, последний бит (и действительное имя домена) для вашего запроса с ошибкой :
# dig COMOO.COM MX @9.9.9.9
; <<>> DiG 9.16.8 <<>> COMOO.COM MX @9.9.9.9
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3094
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;COMOO.COM. IN MX
;; ANSWER SECTION:
COMOO.COM. 3600 IN MX 5 mail.h-email.net.
;; Query time: 24 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: (...) 2021
;; MSG SIZE rcvd: 70
То же самое для gmail.com.com.com - домен com.com существует и имеет запись MX, которую вы можете запросить. gmail.com.com.com выглядит как компьютер в субдомене этого основного домена.