У меня есть развертывание Kubernetes, которое при развертывании в Kubernetes в docker-desktop
для Mac работает нормально, но точно такая же конфигурация (файлы конфигурации, образы Docker) в Azure Kubernetes - нет.
Требования: Pod должен подключаться к VPN-соединению, весь исходящий веб-трафик должен маршрутизироваться через VPN-соединение, сохраняя при этом возможность подключения к «локальным» ресурсам Kubernetes.
Перед установкой VPN-соединения вся сеть работает нормально.
Таблицы маршрутов до установления соединения VPN:
/app # route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 10.244.1.1 0.0.0.0 UG 0 0 0 eth0
10.244.1.0 * 255.255.255.0 U 0 0 0 eth0
Таблицы маршрутов после установления соединения VPN:
/app # route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 10.7.1.1 128.0.0.0 UG 0 0 0 tun0
default 10.7.1.1 0.0.0.0 UG 0 0 0 tun0
10.7.1.0 * 255.255.255.0 U 0 0 0 tun0
10.244.1.0 * 255.255.255.0 U 0 0 0 eth0
107.174.17.243 10.244.1.1 255.255.255.255 UGH 0 0 0 eth0
128.0.0.0 10.7.1.1 128.0.0.0 UG 0 0 0 tun0
По сути, сценарий «up» удаляет шлюз по умолчанию для исходной сети, заменяет его шлюзом VPN, и сценарий «вниз» восстанавливает исходный шлюз по умолчанию.
Основная проблема заключается в том, что после установления VPN-соединения я больше не могу получить разрешение доменного имени. kube-dns
работает в обоих местах, а спецификация модуля имеет явную конфигурацию DNS:
dnsConfig:
nameservers:
- 8.8.8.8
- 8.8.4.4
Опять же, я повторю , что вся сеть работает нормально до установления соединения VPN.
Когда я запускаю nslookup google.com
с подключенным VPN-соединением, он работает
/app # nslookup google.com
Server: 8.8.8.8
Address: 8.8.8.8:53
Non-authoritative answer:
Name: google.com
Address: 172.217.11.238
Non-authoritative answer:
Name: google.com
Address: 2607:f8b0:400f:800::200e
Но когда я запускаю ping google.com
, пока VPN включен, он не работает
/app # ping google.com
ping: bad address 'google.com'
Однако, если я знаю точный IP-адрес сервера, с которым я хочу поговорить, я могу получить от него ответ. Например, вызов CURL для ранее разрешенного IP-адреса Google.
/app # curl "http://172.217.11.238" > output.txt
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 219 100 219 0 0 782 0 --:--:-- --:--:-- --:--:-- 782
/app # cat output.txt
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com/">here</A>.
</BODY></HTML>
/app #
Таким образом, проблема, похоже, связана ТОЛЬКО с разрешением DNS при подключении VPN, но я не знаю, как это исправить.
Итак, мне удалось решить эту проблему, но я не совсем фанат.
В моем сценарии OpenVPN - up
ip route add {IP_OF_KUBE_DNS} via $network_net_gateway
Это добавляет явный маршрут к IP-адресу DNS-сервера во внутренней сети, сообщая ему пройти через исходный сетевой шлюз