Назад | Перейти на главную страницу

Устранение неполадок сломанного TCP от клиента OpenVPN к серверу; Но пинг, traceroute Работает

Я пытаюсь устранить неполадки при настройке сервера OpenVPN на OS X Mavericks. До обновления 10.9 все это работало, и я пытаюсь изолировать проблему от чего-то фундаментального или от настройки моего сервера / клиента.

Клиенты VPN могут устанавливать TCP-соединения со всем Интернетом и каждым устройством в локальной сети, за исключением самого VPN-сервера. Кроме того, клиенты VPN могут успешно проверять связь и трассировать сервер, что находится на расстоянии одного прыжка.

Я в растерянности и буду признателен за любые указатели.

Мой сервер - 10.0.1.3 на интерфейсе 10.0.1 / 24 en0. Мой VPN находится на 10.8.0 / 24 на tun0. Брандмауэр отключен, но необходимо включить NAT на брандмауэре на основе pf для доступа клиентов в Интернет, что делается с помощью строк pfctl pf.conf,

nat on en0 from { 10.8.0.0/24 10.0.1.0/24 } to any -> (en0)
pass all

Неисправная обратная ссылка TCP, наблюдаемая между сервером и клиентом, существует независимо от того, включен ли брандмауэр, что заставило меня исключить брандмауэр как причину. Пересылка пакетов включается командами BSD:

/usr/sbin/sysctl -w net.inet.ip.fw.enable=1
/usr/sbin/sysctl -w net.inet.ip.forwarding=1

Похоже, что VPN не возвращает правильно пакеты [SYN, ACK] от сервера к VPN-клиенту через tun0. Что может помешать пакетам от клиентов VPN достигать LAN через интерфейс tun0? Пакеты к VPN-клиенту возвращаются на en0, а не на tun0, и это разрывает соединение. Это проиллюстрировано в приведенном ниже примере с использованием wirehark для захвата пакетов порта 22 на tun0 и en0. Вот что я вижу на wirehark:

server [10.0.1.3]$ ssh mobile@10.8.0.10   # Successful

tun0:

10.8.0.1 -> 10.8.0.10 ssh [SYN]
10.8.0.10 ssh -> 10.8.0.1 [SYN,ACK]
10.8.0.1 -> 10.8.0.10 ssh [ACK]
...

en0:

<No packets>


iPhone [10.8.0.10]$ ssh user@10.0.1.3   # Unsuccessful

tun0:

10.8.0.10 -> 10.0.1.3 ssh [SYN]
10.8.0.10 [TCP Retransmission] -> 10.0.1.3 ssh [SYN]
10.8.0.10 [TCP Retransmission] -> 10.0.1.3 ssh [SYN]
10.8.0.10 [TCP Retransmission] -> 10.0.1.3 ssh [SYN]
10.8.0.10 [TCP Retransmission] -> 10.0.1.3 ssh [SYN]
...

en0:

10.0.1.3 ssh -> 10.8.0.10 [SYN,ACK]
10.0.1.3 [TCP Retransmission] ssh -> 10.8.0.10 [SYN,ACK]
10.0.1.3 [TCP Retransmission] ssh -> 10.8.0.10 [SYN,ACK]
10.0.1.3 [TCP Retransmission] ssh -> 10.8.0.10 [SYN,ACK]
10.0.1.3 [TCP Retransmission] ssh -> 10.8.0.10 [SYN,ACK]
10.0.1.3 [TCP Retransmission] ssh -> 10.8.0.10 [SYN,ACK]
...

Я работаю по книге Инструменты устранения неполадок сети пытаюсь отследить это. Его первый пример использования netstat показывает таблицу маршрутизации, которая выглядит следующим образом, с явным разрешением для адресов 172.16.2.1 и 172.16.2.255.

bsd1# netstat -rn
Routing tables
Internet:
Destination
…
172.16.1/24 172.16.2.1 xl1
172.16.2/24 link#2 xl1
172.16.2.1 0:10:7b:66:f7:62 xl1
172.16.2.255 ff:ff:ff:ff:ff:ff xl1

Но моя фактическая таблица маршрутизации для tun0 выглядит так:

server$ netstat -rn
default 10.0.1.1 UGSc 157 21721 en0
…
10.8/24 10.8.0.2 UGSc 1 6 tun0
10.8.0.2 10.8.0.1 UH 2 0 tun0

Нет ничего явного для 10.8.0.1 или 10.8.0.255 в интерфейсе tun0 - а должно быть? Если да, то как добавить этот маршрут? Может быть, именно поэтому ответные пакеты с сервера отправляются обратно через интерфейс en0 по умолчанию?

Приветствуются любые указатели.

Как вы правильно указали в своем последнем комментарии, это проблема маршрутизации. У меня была аналогичная ситуация, когда я хотел, чтобы все мои клиенты OpenVPN (в моем случае сеть 10.8.0.0/24 на tun0) были NAT-ed (или замаскированы) с интерфейсом en0 (в моем случае 172.16.172.2/24) адресом мой OpenVPN сервер при доступе к локальной сети 172.16.172.0/24

Симптомом было то, что я мог получить доступ ко всем хостам в сети 172.16.172.0/24, но не к самому 172.16.172.2, и мне пришлось вернуться к подключению к серверу OpenVPN через его адрес интерфейса tun0, но проблема меня беспокоила.

После многих попыток и ошибок я нашел решение. Строка пропуска ниже в pf.conf гарантирует, что пакеты, поступающие на интерфейс VPN из сети VPN, адресованные внутреннему интерфейсу сервера OpenVPN, маршрутизируются обратно на интерфейс VPN. Обратите внимание также на мои строки nat - я, по сути, предотвращаю NAT, если трафик предназначен для внутреннего интерфейса.

int_if="en0"
vpn_if="tun0"
vpnnet="10.8.0.0/24"
no nat on ! $vpn_if from $vpnnet to ($int_if)
nat on ! $vpn_if from $vpnnet to any -> ($int_if)
pass in log quick on $vpn_if reply-to $vpn_if from $vpnnet to $int_if