Віддалені користувачі не потрапляють на другий сайт через VPN-концентратор

Віддалений користувач підключається до концентратора, добирається до файлового сервера в його власній локальній мережі, і все виглядає здоровим. Потім він відкриває спільний ресурс на 10.20.0.50 у головному офісі, куди концентратор потрапляє через окремий тунель «сайт — сайт», і запит завершується тайм-аутом. Обидва тунелі підняті, і обидва лічильники зростають, тож жоден із тунелів не зламаний. Прохід через концентратор — це три рішення маршрутизації на трьох пристроях, і тунель несе лише ті префікси, для яких він побудований. Ось порядок, у якому я перевіряю, і команда, яка показує, чи виконується кожен крок.

Транзиту потрібні три пошуки, а не один тунель

Кожен пристрій виконує власне зіставлення за найдовшим префіксом і забуває його. Ноутбук має надсилати 10.20.0.50 у тунель, а не своєму локальному маршрутизатору. Концентратор має взяти пакет, що прийшов на інтерфейс віддаленого доступу, і передати його інтерфейсу «сайт — сайт». Головний офіс має надіслати відповідь на адресу користувача назад через тунель. Будь-яка з трьох невдач виглядає в браузері однаково: тиша.

Саме тому перевірка кожного тунелю окремо доводить так мало. Пінг адреси локальної мережі концентратора задіює перше рішення, а пінг концентратора з головного офісу — третє. Пакет, який не проходить, має джерелом пул користувачів, а призначенням — другий сайт, тому спершу запишіть ці префікси. Тут пул — 10.80.0.0/24, локальна мережа концентратора — 10.10.0.0/24, а головний офіс — 10.20.0.0/24.

Проштовхніть далекий префікс віддаленому клієнту

На сервері віддаленого доступу OpenVPN клієнт вивчає маршрути під час підключення. Без push клієнт із розділеним тунелем надсилає 10.20.0.50 на свій власний шлюз, і пакет ніколи не входить у тунель.

push "route 10.20.0.0 255.255.255.0"

Проштовхнутий маршрут набуває чинності, коли клієнт підключається, тож користувач, який залишається онлайн, нічого не бачить до перепідключення. Перевірте на клієнті: ip route get 10.20.0.50 у Linux, route print у Windows. Вивід має називати інтерфейс тунелю.

push не допомагає концентратору. Це повідомлення клієнту, а не маршрут на сервері й не дозвіл на пересилання, тож концентратор з ідеальним рядком push усе одно відкидає потік на один крок пізніше. Це звичайна причина, чому люди роблять висновок, що push не спрацював.

Дайте концентратору справжній маршрут виходу

Концентратору потрібен власний наступний крок для префікса головного офісу. На маршрутизованому тунелі це звичайний маршрут через інтерфейс «сайт — сайт», і одна команда показує і вибраний маршрут, і вибране джерело:

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

Там, де плече «сайт — сайт» саме є OpenVPN, маршрут може жити в цій конфігурації з адресою тунелю партнера як шлюзом: route 10.20.0.0 255.255.255.0 172.30.0.2. Шлюз не є необов'язковим. Якщо його опустити, наступний крок впаде на реалізаційне значення за замовчуванням, яке різниться між клієнтом з однією віддаленою точкою і концентратором з кількома партнерами.

IPsec на основі політик поводиться інакше: ядро концентратора надсилає пакет на свій звичайний шлюз локальної мережі, і політика перехоплює його на виході, тож маршрут тунелю або нічого не робить, або веде трафік в обхід політики. Стежте за джерелом у команді вище, бо 10.10.0.1 замість адреси пулу означає, що ядро вибрало адресу, яку далека сторона відхилить. iroute теж не відповідь; він каже серверу, який клієнт володіє підмережею за власним тунелем, а не куди надсилати трафік для третього сайту.

Розширте далеку сторону до пулу користувачів

Головний офіс уже покриває локальну мережу концентратора, 10.10.0.0/24. Пул користувачів — це другий префікс, і він теж має бути в селекторах, інакше жодна політика не покриває відповідь, адресовану 10.80.0.25. Кожен партнер називає ту саму пару наборів префіксів зі свого боку:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

local_ts одного пристрою — це remote_ts іншого. Скопіюйте блок концентратора в головний офіс, і пара перевернеться, тож дочірній SA ніколи не підніметься.

Старіший синтаксис ipsec.conf використовує leftsubnet, розділений комами. Робоча асоціація безпеки зберігає селектори, про які домовилася, тож переустановіть тунель після правки. Селектор, змінений о 10:00 і перевірений проти SA, піднятої о 09:40, усе одно не проходить, хоча файл конфігурації весь час виглядає правильним.

Потім перевірте останній крок. ip route get 10.80.0.25 на далекому кінці має вказувати в тунель. Якщо служба використовує маршрутизатор локальної мережі як свій шлюз за замовчуванням, цьому маршрутизатору теж потрібен зворотний маршрут, інакше відповідь помирає там. Запуск tcpdump -ni eth1 host 10.80.0.25 на цьому сегменті показує, чи відповідь узагалі залишила далекий кінець.

Дозвольте потік на концентраторі

Пересилання має бути ввімкнене, а шлях — дозволений. Обмежте правила двома префіксами замість того, щоб приймати все між інтерфейсами.

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

Фільтрація зворотного шляху — це тиха невдача поряд: коли два плеча на різних інтерфейсах, rp_filter=1 може відкинути відповідь, тоді як лічильник дозвільного правила не рухається. Порівняйте iptables -vnL FORWARD до і після спроби. Правило, яке ніколи не зростає, не досягається, тож подивіться на рівень нижче, а не переписуйте його.

Якщо транзит потрібен лише одній групі, покладіть маршрут у файл для окремого клієнта в client-config-dir замість розширення глобального push. Source NAT на концентраторі також прибирає потребу у зворотному маршруті на далекій стороні, але він приховує адресу користувача, тож журнали далекого сайту й правила на основі адрес перестають розрізняти користувачів.

Перевірте з клієнта, потім відкотіть у зворотному порядку

Перевірте TCP-порт, а не лише ICMP, бо ping може проходити, поки служба лишається заблокованою. nc -vz 10.20.0.50 445 і traceroute -n 10.20.0.50 з клієнта показують, чи другий крок — це адреса тунелю концентратора. На концентраторі tcpdump -ni tun0 host 10.20.0.50 і той самий фільтр на інтерфейсі «сайт — сайт»: запит на обох без відповіді на жодному переносить проблему на далеку сторону.

Потім перевірте те, що має лишитися заблокованим. Якщо хост, до якого пул ніколи не повинен доходити, теж відповідає, ви відкрили більше, ніж транзит, і правила слід звузити. Концентратор, який пересилає все кожній гілці, проходить першу перевірку і провалює другу.

Тримайте список відкату, бо змінилися чотири об'єкти, і три легко забути: проштовхнутий маршрут, маршрут концентратора, селектори та правила міжмережевого екрана. Скасуйте їх у зворотному порядку, переустановіть SA і дозвольте одному користувачеві перепідключитися. Частковий відкат залишає маршрут, що вказує на тунель, який більше не відповідає, і це читати важче, ніж початкову тишу. Посібник OpenVPN 2.6 документує push, route і iroute для вашої версії.