Отдалечени потребители не достигат втория сайт през VPN концентратора

Отдалечен потребител се свързва с концентратора, достига файловия сървър в собствената му LAN и всичко изглежда наред. След това отваря споделена папка на 10.20.0.50 в централата, която концентраторът достига през отделен тунел сайт-към-сайт, и изтича времето за изчакване. И двата тунела са вдигнати и двата брояча растат, така че нито един от тунелите не е счупен. Преминаването през концентратора е три решения за маршрутизация на три устройства, и тунелът носи само префиксите, за които е изграден. Ето реда, по който проверявам, и командата, която показва дали всяка стъпка е вярна.

Транзитът изисква три проверки, а не един тунел

Всяко устройство прави собствено съвпадение по най-дълъг префикс и го забравя. Лаптопът трябва да изпраща 10.20.0.50 в тунела, а не към своя локален рутер. Концентраторът трябва да вземе пакет, пристигнал на интерфейса за отдалечен достъп, и да го предаде на интерфейса сайт-към-сайт. Централата трябва да изпрати отговор за адреса на потребителя обратно през тунела. Всеки един от трите отказа изглежда еднакво в браузъра: тишина.

Ето защо тестването на всеки тунел поотделно доказва толкова малко. Пингването на LAN адреса на концентратора упражнява първото решение, а пингването на концентратора от централата — третото. Пакетът, който се проваля, има пула от потребители като източник и втория сайт като дестинация, затова първо запишете тези префикси. Тук пулът е 10.80.0.0/24, LAN на концентратора е 10.10.0.0/24, а централата е 10.20.0.0/24.

Прокарайте далечния префикс към отдалечения клиент

На сървър за отдалечен достъп OpenVPN клиентът научава маршрутите при свързване. Без push клиент със split тунел изпраща 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, базиран на политики, е различен: ядрото на концентратора изпраща пакета към обичайния си LAN шлюз и политиката го прихваща на изхода, така че маршрутът през тунела или не прави нищо, или насочва трафика покрай политиката. Следете източника в командата по-горе, защото 10.10.0.1 вместо адреса на пула означава, че ядрото е избрало адрес, който далечната страна ще отхвърли. iroute също не е отговорът; той казва на сървъра кой клиент притежава подмрежа зад собствения му тунел, а не къде да се изпраща трафик за трети сайт.

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

Централата вече покрива LAN на концентратора, 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 на далечната крайна точка трябва да сочи в тунела. Ако услугата използва LAN рутер като свой шлюз по подразбиране, този рутер също се нуждае от обратния маршрут, иначе отговорът умира там. Изпълнението на 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 за вашата версия.