У меня есть машина с двумя сетевыми интерфейсами eth0 и eth1. Я хочу использовать интерфейс eth0 для Интернета и eth1 для моей интрасети, подключенной к внутреннему маршрутизатору.
Интернет-соединение работает нормально, когда только интерфейс eth0 готов и интерфейс eth1 не работает. Таблица маршрутизации показана ниже, когда eth1 не работает.
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.24.140.1 0.0.0.0 UG 0 0 0 eth0
10.24.140.0 0.0.0.0 255.255.252.0 U 1 0 0 eth0
Когда я приношу интерфейс eth1 вверх, запись маршрутизации по умолчанию добавляется в таблицу маршрутизации с пунктом назначения как 192.168.1.0 и шлюз как 0.0.0.0 и это создает проблемы.
Теперь, когда я пытаюсь пинговать общественное достояние, например www.google.com, результаты пинга всегда показывают, что система пыталась пинговать 192.168.1.1. Даже "nslookup" для www.google.com приводит к IP-адресу домена как 192.168.1.1.
Я не понимаю, почему nslookup терпит неудачу, просто принося eth1 вверх. Я больше не могу получить доступ к Интернету, и все в порядке.
Я попытался удалить запись маршрутизации для 192.168.1.0, но это не помогает. Простая перезагрузка машины снова добавит запись маршрутизации, и все снова будет в беспорядке.
Пожалуйста, предложите, что я могу попробовать, чтобы обе сети работали на моем компьютере.
Вы видите один симптом (поиск DNS возвращает неправильный IP-адрес), но путаете это с маршрутизацией. Сама маршрутизация не имеет ничего общего с вашей проблемой, поиск DNS имеет. Тот факт, что включение второго сетевого адаптера означает, что что-то в этой второй сети вызывает это.
Что вам нужно сделать, так это узнать, что происходит с вашими DNS-запросами. Где-то у вас возвращается DNS-сервер 192.168.0.1 для всех ваших запросов.
Дополнительно, nslookup на самом деле не лучший инструмент для работы в Linux. Вы должны попробовать использовать dig. dig +trace google.com предоставит вам полную разбивку запросов, которые он делает для разрешения IP-адреса, и может показать вам, где что-то идет не так.
В качестве альтернативы вы можете запустить pcap и проанализировать свой захват в чем-то вроде Wireshark. Это покажет вам точные пакеты, которые передаются по сети, и может дать вам некоторое представление о том, что происходит.