Удаљени корисници не стижу до друге локације кроз 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 за вашу верзију.