Я не могу выполнить команду ping в контейнере, когда на моем хост-компьютере запущена VPN.
Я пытаюсь сделать это:
docker run adiazmor/docker-ubuntu-with-ping ping 8.8.8.8
Он не работает при запуске VPN, но это работает:
docker run --net=host adiazmor/docker-ubuntu-with-ping ping 8.8.8.8
Я не всегда могу иметь --net=host варианты, потому что мы не можем использовать links в docker-compose.
Я использую IKE для запуска своего VPN. Вот конфигурация VPN (без видимых данных):
n:version:4
n:network-ike-port:500
n:network-mtu-size:1380
n:client-addr-auto:1
n:network-natt-port:4500
n:network-natt-rate:10
n:network-frag-size:540
n:network-dpd-enable:1
n:client-banner-enable:1
n:network-notify-enable:1
n:client-dns-used:1
n:client-dns-auto:0
n:client-dns-suffix-auto:1
n:client-splitdns-used:1
n:client-splitdns-auto:1
n:client-wins-used:1
n:client-wins-auto:1
n:phase1-dhgroup:2
n:phase1-keylen:256
n:phase1-life-secs:86400
n:phase1-life-kbytes:0
n:vendor-chkpt-enable:0
n:phase2-keylen:256
n:phase2-life-secs:28800
n:phase2-life-kbytes:0
n:policy-nailed:0
n:policy-list-auto:0
b:auth-mutual-psk:----
n:phase2-pfsgroup:-1
s:network-host:[network-host-ip]
s:client-auto-mode:pull
s:client-iface:virtual
s:network-natt-mode:enable
s:network-frag-mode:enable
s:client-dns-addr:8.8.8.8,8.8.4.4
s:auth-method:mutual-psk-xauth
s:ident-client-type:address
s:ident-server-type:any
s:phase1-exchange:main
s:phase1-cipher:aes
s:phase1-hash:sha1
s:phase2-transform:esp-aes
s:phase2-hmac:sha1
s:ipcomp-transform:disabled
s:policy-level:auto
s:policy-list-include:0.0.0.0 / 0.0.0.0
Вот результаты route -n :
На хосте, когда VPN не запущен:
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.254 0.0.0.0 UG 100 0 0 enp4s0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 enp4s0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
172.18.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-c57946727b62
172.19.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-e5b5cdaf12ea
172.20.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-0f8aa3757cdc
172.21.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-89f7a8041283
172.22.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-9313de2b3cda
172.23.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-5eb78801c6be
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 enp4s0
Когда VPN работает:
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.226.1 0.0.0.0 UG 0 0 0 tap0
0.0.0.0 192.168.1.254 0.0.0.0 UG 100 0 0 enp4s0
78.109.86.184 192.168.1.254 255.255.255.255 UGH 0 0 0 enp4s0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 enp4s0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
172.18.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-c57946727b62
172.19.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-e5b5cdaf12ea
172.20.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-0f8aa3757cdc
172.21.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-89f7a8041283
172.22.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-9313de2b3cda
172.23.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-5eb78801c6be
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 enp4s0
На контейнере (без изменений, установлен контейнер или нет):
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.19.0.1 0.0.0.0 UG 0 0 0 eth0
172.19.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
Я проверил другие вопросы и не обнаружил, что в моем случае что-то работает. Я не думаю, что это связано с DNS, потому что я пытаюсь получить доступ к IP-адресу.
Что я могу сделать?
Факты:
Соображения:
Когда хост отправляет исходящий трафик для нового соединения (то есть не отвечает на входящее), он должен решить, какой маршрут применить, а также какой интерфейс подходит для этого трафика.
На основе приведенной выше таблицы маршрутов трафик, сгенерированный на хосте, будет выбирать интерфейс с ответвлением, поскольку у него более низкая метрика, чем у интерфейса en4ps0.
Основная причина проблемы:
Трафик, генерируемый внутри контейнера, будет транслироваться на IP-адрес хоста в интерфейсе en4ps0, поэтому он будет применять маршрут, подходящий для этого интерфейса, таким образом полностью пропуская VPN.
Пинг может завершиться неудачно из-за асимметричного трафика, вашего программного обеспечения VPN, блокирующего трафик к / от en4ps0 и т. Д., Но дело в том, что трафик вашего контейнера не проходит через туннель из-за NAT / PAT.
В зависимости от вашей базовой сети и других требований драйвер macvlan может быть лучшим выбором, чем мост или хост. В качестве альтернативы вам придется переосмыслить свою архитектуру или необходимость разместить VPN на хосте (а не на отдельном хосте / устройстве).