Далечните корисници не стигнуваат до втората локација преку 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, клиент со поделен тунел го праќа 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 за вашата верзија.