Как я диагностирую соединение VPN, которое не передаст запросы DNS?

Как я диагностирую соединение VPN, которое не передаст запросы DNS?

Моя конфигурация сети без выполнения VPN работает, как желаемый. Я сделал, чтобы Centos вышел напрямую исходящие запросы NAT'ing через IPTables. Внутренний маршрутизатор (Cisco 2600) настроен к

маршрут IP router-2600#show
Коды: - отрезанный
Шлюз последней инстанции 192.168.1.1 к сети 0.0.0.0

 192.168.200.0/26 is subnetted, 1 subnets                                   

C 192.168.200.0 непосредственно соединен, FastEthernet0/0
S 192.168.1.0/24 [1/0] через 192.168.200.2
C 192.168.3.0/24 непосредственно соединен, FastEthernet1/0
S* 0.0.0.0/0 [1/0] через 192.168.1.1

Internet                                                                     
               192.168.200.0                192.168.3.0                  
 +----------+                +-----------+                 +------------+
 |          |.2            .1|           |.1             .3|            |
 |          +----------------+           +-----------------+            |
 | IPTables |                |     Cisco |                 |     Laptop |
 | NAT/Masq |                |      2600 |                 |            |
 +----------+                +-----------+                 +------------+

Эта установка работает точно как ожидалось и желаемый.

Но, когда я выполняю vpnc на 192.168.200.2 хостах, основанные на UDP функции, кажется, перестали работать. А именно, я не могу сделать запросов DNS против сервера DNS, который находится в пространстве имен VPN'd, хотя я могу проверить с помощью ping-запросов тот хост.

eth0      Link encap:Ethernet  HWaddr 00:E0:4C:77:4B:32  
          inet addr:192.168.200.2  Bcast:192.168.200.63  Mask:255.255.255.192
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:256616278 errors:0 dropped:0 overruns:0 frame:0
          TX packets:428976874 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1941010246 (1.8 GiB)  TX bytes:1236389787 (1.1 GiB)
          Interrupt:169 Base address:0x8400 

eth1     -snipped-

eth2      Link encap:Ethernet  HWaddr 00:14:D1:2B:86:9F  
          inet addr:192.168.100.252  Bcast:192.168.100.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:546051427 errors:0 dropped:0 overruns:0 frame:0
          TX packets:318999693 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1296057751 (1.2 GiB)  TX bytes:3330532283 (3.1 GiB)
          Interrupt:193 Base address:0xac00 

lo       -snipped-

tunvpn    Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:172.31.252.222  P-t-P:172.31.252.222  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1412  Metric:1
          RX packets:162 errors:0 dropped:0 overruns:0 frame:0
          TX packets:249 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:13756 (13.4 KiB)  TX bytes:14324 (13.9 KiB)

Сценарий конфигурации VPN:

#!/bin/bash

IPT="/sbin/iptables"
ROUTE="/sbin/route"
INSIDE="eth0"
OUTSIDE="eth2"

SCRIPT_HOME=/opt/vpn-scripts
PIDFILE=${SCRIPT_HOME}/vpn.pid


if [ -e ${PIDFILE} ] && pgrep vpnc | grep $(cat ${PIDFILE}) ; then
        echo vpnc is already running.  Killing process. >> ${SCRIPT_HOME}/vpn.log
        kill $(cat ${PIDFILE})
        sleep 3
fi

cp /etc/resolv.conf ${SCRIPT_HOME}/resolv.conf.bak

/sbin/vpnc --debug 3 --pid-file ${PIDFILE} vpn 2>&1 >> ${SCRIPT_HOME}/vpn.log

cp ${SCRIPT_HOME}/resolv.conf.bak /etc/resolv.conf

$ROUTE del default dev tunvpn
$ROUTE add -net 172.31.252.0 netmask 255.255.255.0 dev tunvpn metric 50

echo "Deleting routes - clear previous entries"
$IPT -t nat -D POSTROUTING -o tunvpn -j MASQUERADE
$IPT -D FORWARD -i tunvpn -o $INSIDE -j ACCEPT
$IPT -D FORWARD -i $INSIDE -o tunvpn -j ACCEPT

echo "Creating routes"
$IPT -t nat -A POSTROUTING -o tunvpn -j MASQUERADE
$IPT -A FORWARD -i tunvpn -o $INSIDE -j ACCEPT
$IPT -A FORWARD -i $INSIDE -o tunvpn -j ACCEPT

Дамп TCP, работающий на сервере Centos, показывает запросы, прибывающие в предназначенный для целевого сервера DNS, но никаких ответов, когда-либо возвращаясь.

Кроме того, от маршрутизатора Centos я могу запросить внутренний DNS и получить ответ.

Когда я запрашиваю сервер DNS от Cisco 2600, хотя, он испытывает таймаут. (Когда маршрутизатор делает попытку запроса, TCPDump на шоу сервера Centos:

[root@localhost:~] sudo tcpdump src 172.31.252.11 or dst 172.31.252.11
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
15:35:39.861291 IP 192.168.200.1.50242 > 172.31.252.11.domain:  46+ X25? internal.lab. (28)
15:35:42.862844 IP 192.168.200.1.55077 > 172.31.252.11.domain:  47+ A? internal.lab. (28)
15:35:45.861379 IP 192.168.200.1.55077 > 172.31.252.11.domain:  47+ A? internal.lab. (28)
15:35:48.861533 IP 192.168.200.1.55077 > 172.31.252.11.domain:  47+ A? internal.lab. (28)

)

0
задан 8 August 2015 в 22:41
1 ответ

Я обычно использую tcpdump bejesus из всего, что я могу достать; это обычно связывает проблему либо с межсетевым экраном, либо с сетевым соединением. Я не использую устройства, на которых не могу запустить tcpdump , поэтому, если окажется, что эта Cisco замешана, у вас могут быть проблемы.

Проблема в сетевом соединении. , Я обычно просто начинаю заменять компоненты один за другим, пытаясь изолировать причину. Для решения проблем с брандмауэром нет ничего лучше, чем хороший iptables -t raw -I OUTPUT -j TRACE , который точно покажет вам, что делает ваш брандмауэр - и, следовательно, что он делает неправильно.

0
ответ дан 5 December 2019 в 12:29

Теги

Похожие вопросы