Я пытаюсь настроить кластер с использованием частной сети в подсети 10. Одна машина имеет два интерфейса: один для подключения к обычной сети, а другой для подключения ко всем узлам в подсети 10. Этот компьютер с CentOS 6 (назовем его «zaza.domain.com») запускает DHCP, DNS, и в настоящее время оба они управляются Cobbler, что может быть, а может и не быть частью проблемы (хотя его отключение и выполнение всех действий вручную по-прежнему вызывает у меня проблемы).
Если я использую SSH в zaza, а затем пытаюсь подключиться по SSH из zaza в node1, я получаю следующее предупреждающее сообщение:
[root@zaza ~]# ssh node1
reverse mapping checking getaddrinfo for node1.cluster.local [10.69.0.1] failed - POSSIBLE BREAK-IN ATTEMPT!
Я все еще получаю запрос на ввод пароля и могу войти в систему ОК.
Я знаю из sshd предупреждение: "ВОЗМОЖНАЯ ПОПЫТКА ВЗЛОМА!" для неудачного обратного DNS и «ВОЗМОЖНА ПОПЫТКА ВКОЛА!» в / var / log / secure - что это значит? и множество других поисков того, что причиной этой ошибки обычно является неустановленная запись PTR. Однако он установлен - учтите следующее:
[root@zaza ~]# nslookup node1.cluster.local
Server: 10.69.0.69
Address: 10.69.0.69#53
Name: node1.cluster.local
Address: 10.69.0.1
[root@zaza ~]# nslookup 10.69.0.1
Server: 10.69.0.69
Address: 10.69.0.69#53
1.0.69.10.in-addr.arpa name = node1.cluster.local.
IP-адрес 10.69.0.69 является вторым интерфейсом zaza.
Если я попробую другой инструмент, например dig, чтобы просмотреть запись PTR, я получу следующий результат:
[root@zaza ~]# dig ptr 1.0.69.10.in-addr.arpa
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6_8.4 <<>> ptr 69.0.69.10.in-addr.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29499
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;1.0.69.10.in-addr.arpa. IN PTR
;; ANSWER SECTION:
1.0.69.10.in-addr.arpa. 300 IN PTR node1.cluster.local.
;; AUTHORITY SECTION:
10.in-addr.arpa. 300 IN NS zaza.cluster.local.
;; ADDITIONAL SECTION: zaza.cluster.local. 300 IN A 10.69.0.69
;; Query time: 0 msec
;; SERVER: 10.69.0.69#53(10.69.0.69)
;; WHEN: Wed Mar 1 17:05:44 2017
;; MSG SIZE rcvd: 110
Мне кажется, что запись PTR установлена, поэтому я не знаю, почему SSH выдает шипение, когда я пытаюсь подключиться к одной из узловых машин. Чтобы предоставить всю информацию, вот соответствующие файлы конфигурации, испорченные, чтобы все выглядело более читабельным ...
/etc/ named.conf
[root@zaza ~]# cat /etc/named.conf
options {
listen-on port 53 { any; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query { any; }; # was localhost
recursion yes;
# setup DNS forwarding
forwarders {1.2.3.4;}; # Real IP goes in here
};
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
zone "cluster.local." {
type master;
file "cluster.local";
# these two lines allow DNS querying
allow-update { any; };
notify no;
};
zone "10.in-addr.arpa." {
type master;
file "10";
# these two lines allow DNS querying
allow-update { any; };
notify no;
};
/var/ named/cluster.local
[root@zaza ~]# cat /var/named/cluster.local
$TTL 300
@ IN SOA zaza.cluster.local. nobody.example.com. (
2017030100 ; Serial
600 ; Refresh
1800 ; Retry
604800 ; Expire
300 ; TTL
)
IN NS zaza.cluster.local.
zaza IN A 10.69.0.69
node1 IN A 10.69.0.1;
node2 IN A 10.69.0.2;
/ var / named / 10
[root@zaza ~]# cat /var/named/10
$TTL 300
@ IN SOA zaza.cluster.local. root.zaza.cluster.local. (
2017030100 ; Serial
600 ; Refresh
1800 ; Retry
604800 ; Expire
300 ; TTL
)
IN NS zaza.cluster.local.
69.0.69 IN PTR zaza.cluster.local.
1.0.69 IN PTR node1.cluster.local.
2.0.69 IN PTR node2.cluster.local.
Если у вас есть идеи, мы будем очень признательны!
Все дело было в Avahi и домене .local, а не в записях PTR.
Я провел еще несколько поисков, осознав, что разрешение хоста работает, но этот хост по FQDN не работает. Это в конечном итоге привело меня https://superuser.com/questions/704785/ping-cant-resolve-hostname-but-nslookup-can и отсюда я был связан с http://www.lowlevelmanager.com/2011/09/fix-linux-dns-issues-with-local.html который решил все для меня.
В конечном итоге проблема в том, что в /etc/nsswitch.conf
там есть строчка:
hosts: files mdns4_minimal [NOTFOUND=return] dns
Изменив это на:
hosts: files dns
Проблема исчезла, и я больше не получал ошибку о возможных попытках взлома.
Другое решение, которое я тестировал, заключалось в простом переименовании домена, поскольку такое поведение характерно для домена .local. При переименовании cluster.local в cluster.bob сообщение об ошибке также исчезло.
Другое решение - переместить Avahi с .local на что-то вроде .alocal, чтобы многоадресный DNS не применялся к домену .local, а конфигурация nsswitch по умолчанию, казалось бы, работала. Я полагаю удаление [NOTFOUND=return]
Параметр также будет работать, поскольку он остановит многоадресный DNS от завершения поиска, если хост .local не найден, однако это, вероятно, плохая идея.
В конечном итоге это был крайний случай, который возник, потому что я не полностью понимал значение домена .local, я просто рассматривал его как хорошее соглашение для внутренней сети.