Одговор ВПН-а између локација не пролази кроз тунел

Провео сам јутро на тунелу који се чисто подигао и превозио саобраћај тачно у једном смеру: огранак је стизао до сервера датотека у централи, а свака веза отворена из централе према огранку умирала је на првом SYN. SA су били активни, бројачи тунела су расли, а руковање никада није било проблем. Одговор се рутирао негде што тунел не покрива, и тај избор припада далекој страни. ВПН између локација преноси само пакете које хост преда шљузу, и сваки хост ту одлуку доноси засебно, у сваком смеру, из своје табеле рутирања.

Оба смера се рутирају засебно

IP не памти смер разговора. Сваки хост који шаље пакет извршава сопствену претрагу најдужег префикса, бира један следећи скок и заборавља одлуку. Захтев и одговор су два неповезана пакета која случајно припадају истој вези, а тунел је један скок који било који од њих може користити или не. Ништа у IKE размени не учи далеки сервер како да дође до ваше подмреже; преговори се само слажу који префикси смеју бити шифровани.

Тај договор су друга капија. У strongSwan селектори саобраћаја су leftsubnet и rightsubnet, а пакет чији извор или одредиште падне изван договореног пара није шифрован, шта год каже табела рутирања. Префикс који се рутира у тунел али недостаје у селекторима је тиха једносмерна грешка: рута изгледа исправно, пакет ипак излази отворен или се одбацује, и само се дневник charon-а жали.

Далеки хост не зна ништа о вашем тунелу

Унутар далеке локалне мреже одговор је обичан пакет упућен вашем клијенту. Одредишни хост не види никакво IPsec заглавље и нема разлог да преферира ВПН шљуз; тражи ваш префикс, не налази ништа конкретније од своје подразумеване руте и следи је. Ако подразумевана показује на основни заштитни зид, он или има руту назад у тунел или нема. Када нема, добијате тихо одбацивање, ICMP unreachable или одговор који изађе кроз интерфејс окренут интернету и умре.

Други интерфејс је довољан да то поквари чак и када рута постоји. NAS са управљачком везом на другом VLAN-у, сервер са резервним uplink-ом, правило политике које шаље један опсег извора у другу табелу: било шта од тога може да ухвати одговор. На Linux-у ip rule show и ip route show table all показују правила и табеле које подразумевани списак крије.

Прочитајте одлуку на машини која шаље одговор

Питајте језгро пре него што било шта промените, и дајте му адресу извора, јер правила зависна од извора мењају одговор.

ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"

Излаз наводи излазни интерфејс и следећи скок. Ако интерфејс није онај окренут ВПН шљузу, пронашли сте дефект, а преостали посао је да изаберете где рута припада. Ping са шљуза овде мало доказује: одговара адресом коју далеки хост може да смести, не адресом вашег лаптопа.

На Windows-у еквиваленти су Find-NetRoute -RemoteIPAddress 10.10.5.10 за одлуку и Get-NetRoute за табелу. Рута додата са New-NetRoute која носи вишу метрику од подразумеване тихо губи, зато читајте колону метрике, не запис. Затим потврдите пакетима: tcpdump -ni any "host 10.10.5.10 and tcp port 445" на далеком LAN интерфејсу показује захтев, а исти филтер на страни тунела показује да ли се одговор вратио. Захтев видљив без одговора значи да је одговор рутиран другде или одбачен; одговор на погрешном интерфејсу даје вам кривца пре него што дотакнете руту.

Када шљуз сервера није крајња тачка ВПН-а

Многе локације стављају заштитни зид између сервера и концентратора. Тај зид прослеђује одговор, зато му треба рута за префикс вашег клијента ка ВПН шљузу и политика прослеђивања у оба смера. Уређаји са стањем погоршавају: захтев је прошао кроз зид са LAN хоста који је дозволио, одговор сада долази из другог смера, и запис праћења везе више не одговара, па се пакет одбацује као невалидан, а не као забрањен. Зато дневник политике изгледа празан док саобраћај нестаје.

Шљуз има свој други филтер. Обрнуто филтрирање пута у Linux-у одбацује пакете чији извор није достижан кроз интерфејс на који су стигли, а то је тачно облик законитог асиметричног повратног пута. упутство strongSwan-а за прослеђивање захтева net.ipv4.ip_forward и олакшан net.ipv4.conf.all.rp_filter управо због тога. Строга вредност 1 на било ком шљузу тихо квари исправну руту, и nstat -az показује одбацивања ако знате где да гледате.

Рутирајте или преведите, па проверите у оба смера

Две поправке нису еквивалентне. Додавање руте чува адресу клијента нетакнутом, па правила заснована на извору, ревизорски дневници и апликације које бележе позиваоца настављају да раде; цена је да сваки скок који доноси одлуку треба руту, то јест више места за грешку. Маскирање на далеком шљузу сажима повратни пут на један скок, јер је одговор сада упућен самом шљузу, и скрива који је клијент шта урадио.

iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADE

Изаберите га свесно: чим клијенти почну да се појављују као адреса шљуза, ACL-ови засновани на извору престају да их разликују, и conntrack мора да држи мапирање да би се одговор уписао назад у тунел. Ако селектори и даље искључују префикс клијента, NAT ништа не мења, јер захтев никада није ушао у тунел.

Пре него што ово прогласите поправљеним, потврдите четири ствари по реду: руту на хосту који шаље одговор, руту на сваком скоку који је прослеђује, селекторе који покривају оба префикса и запис који показује да одговор улази у тунел са извором који очекујете. Затим поновите тест са друге локације. Један смер који пролази је полуотворени дизајн, а други смер обично пада због другог разлога од оног који сте управо поправили.