Как я могу определить, какой у меня IP-адрес в другой сети? - PullRequest
0 голосов
/ 13 января 2020

Я пытаюсь запустить SNMP-запрос от модуля, загруженного в облаке Azure, на внутренний хост в сети моей компании. Запросы snmpget хорошо работают, например, с модуля pod на сервер * SNMP publi c, но запрос к моему целевому хосту приводит к:

root@status-tanner-api-86557c6786-wpvdx:/home/status-tanner-api/poller# snmpget -c public -v 2c 192.168.118.23 1.3.6.1.2.1.1.1.0
Timeout: No Response from 192.168.118.23.

NMAP показывает, что порт SNMP открыт | отфильтрован :

Nmap scan report for 192.168.118.23
Host is up (0.16s latency).
PORT    STATE         SERVICE
161/udp open|filtered snmp

Я запросил новое правило, чтобы разрешить 161UDP от моего модуля, но я подозреваю, что я запросил, чтобы правило было сделано для неправильного IP-адреса.

Моя теория такова что я должен быть в состоянии определить IP-адрес, который мой модуль использует для доступа к этому целевому хосту, если я могу попасть внутрь целевого хоста, открыть соединение из модуля и посмотреть, используя netstat, который является IP-адресом моего модуля используя . Проблема в том, что у меня в настоящее время нет доступа к этому хосту. Итак, мой вопрос Как я могу узнать, с какого адреса мой модуль достигает целевого хоста? Очевидно, что используется какой-то публичный c адрес, но я не могу сказать, какой это без вход в целевой хост.

Я почти уверен, что мне не хватает важного сетевого инструмента, который должен помочь мне в этой ситуации. Любое предложение будет высоко оценено.

1 Ответ

0 голосов
/ 13 января 2020

По умолчанию Kubernetes будет использовать ваш ip узла для доступа к другим серверам, поэтому вам нужно создать правило брандмауэра, используя IP-адрес вашего узла.

Я тестировал использование модуля busybox для доступа к другому серверу в моем network

Вот мой IP-адрес узла lab-1 с ip 10.128.0.62:

$rabello@lab-1:~ ip ad | grep ens4 | grep inet
    inet 10.128.0.62/32 scope global dynamic ens4

В этом узле у меня есть модуль busybox с ip 192.168.251.219:

$ kubectl exec -it busybox sh
/ # ip ad | grep eth0 | grep inet
    inet 192.168.251.219/32 scope global eth0

При выполнении теста ping для другого сервера в сети (server-1) мы имеем:

/ # ping 10.128.0.61
PING 10.128.0.61 (10.128.0.61): 56 data bytes
64 bytes from 10.128.0.61: seq=0 ttl=63 time=1.478 ms
64 bytes from 10.128.0.61: seq=1 ttl=63 time=0.337 ms
^C
--- 10.128.0.61 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.337/0.907/1.478 ms

Используя tcpdump на server-1, мы можем видеть запросы ping от моего модуля, используя ip узла из lab-1:

rabello@server-1:~$ sudo tcpdump -n icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
10:16:09.291714 IP 10.128.0.62 > 10.128.0.61: ICMP echo request, id 6230, seq 0, length 64
10:16:09.291775 IP 10.128.0.61 > 10.128.0.62: ICMP echo reply, id 6230, seq 0, length 64
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel

Убедитесь, что у вас есть соответствующее правило брандмауэра, позволяющее вашему узлу (или вашему диапазону vp c) достичь пункта назначения и проверьте, работает ли ваш VPN (если вы есть).

Надеюсь, это поможет! =)

...