Отговорът на VPN сайт към сайт не минава през тунела
Отговор, който заобикаля тунела, е решение за маршрутизиране от далечната страна. Проверете таблицата на хостовете, селекторите и rp_filter, след което изберете маршрут или NAT.
Прекарах една сутрин с тунел, който се вдигна чисто и пренасяше трафик точно в една посока: клонът стигаше до файловия сървър в централата, а всяка връзка, отворена от централата към клона, умираше на първия SYN. SA бяха активни, броячите на тунела растяха и ръкостискането никога не беше проблемът. Отговорът се маршрутизираше някъде, където тунелът не покрива, и този избор принадлежи на далечната страна. VPN сайт към сайт пренася само пакетите, които хостът предаде на шлюза, и всеки хост прави този избор отделно, във всяка посока, от своята таблица за маршрутизиране.
Двете посоки се маршрутизират поотделно
IP не пази никаква памет за посоката на разговора. Всеки хост, който изпраща пакет, прави свое търсене на най-дългия префикс, избира един следващ хоп и забравя решението. Заявката и отговорът са два несвързани пакета, които случайно принадлежат на една и съща връзка, а тунелът е един хоп, който всеки от тях може да използва или не. Нищо в обмена IKE не учи отдалечения сървър как да стигне до вашата подмрежа; преговорите само се договарят кои префикси могат да бъдат криптирани.
Това споразумение е втората порта. В strongSwan селекторите за трафик са leftsubnet и rightsubnet, а пакет, чийто източник или дестинация е извън договорената двойка, не се криптира, каквото и да казва таблицата за маршрутизиране. Префикс, който се маршрутизира в тунела, но липсва в селекторите, е тиха еднопосочна повреда: маршрутът изглежда правилен, пакетът все още излиза в открит вид или се изхвърля, и само журналът на charon се оплаква.
Далечният хост не знае нищо за вашия тунел
Вътре в отдалечената локална мрежа отговорът е обикновен пакет, адресиран до вашия клиент. Хостът на дестинацията не вижда заглавка на IPsec и няма причина да предпочита VPN шлюза; той търси вашия префикс, не намира нищо по-конкретно от маршрута си по подразбиране и го следва. Ако маршрутът по подразбиране сочи към основна защитна стена, тя или има маршрут обратно в тунела, или няма. Когато няма, получавате тихо изхвърляне, съобщение ICMP за недостижимост или отговор, който излиза през интерфейса към интернет и умира.
Втори интерфейс е достатъчен да развали това дори когато маршрут съществува. NAS с management връзка в друга 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 )"Изходът посочва изходящия интерфейс и следващия хоп. Ако интерфейсът не е този, който гледа към VPN шлюза, открили сте дефекта и остава да изберете къде да стои маршрутът. 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 интерфейс показва заявката, а същият филтър от страната на тунела показва дали се е върнал отговор. Видима заявка без отговор означава, че отговорът е маршрутизиран другаде или изхвърлен; отговор на грешния интерфейс ви дава виновника, преди да пипнете маршрут.
Когато шлюзът на сървъра не е крайна точка на VPN
Много обекти слагат защитна стена между сървърите и концентратора. Тази стена препраща отговора, затова ѝ трябва маршрут за префикса на вашия клиент, сочещ към VPN шлюза, и политика за препращане в двете посоки. Устройствата със състояние влошават нещата: заявката пресече стената от LAN хост, който тя е разрешила, отговорът сега пристига от друга посока и записът за проследяване на връзката вече не съвпада, така че пакетът се изхвърля като невалиден, а не като забранен. Ето защо журналът на политиките изглежда празен, докато трафикът изчезва.
Шлюзът има свой втори филтър. Обратната филтрация на пътя в Linux изхвърля пакети, чийто източник не е достъпен през интерфейса, по който са пристигнали, а това е точно формата на законен асиметричен обратен път. ръководството на strongSwan за препращане изисква net.ipv4.ip_forward и разхлабен net.ipv4.conf.all.rp_filter точно по тази причина. Строга стойност 1 на който и да е от двата шлюза тихо чупи правилен маршрут, а nstat -az показва изхвърлянията, ако знаете къде да гледате.
| Symptom | Where the reply is most likely lost |
|---|---|
| Gateway ping works, LAN host silent | Source address the far host cannot place in its table |
| SYN arrives, no SYN-ACK, tunnel counters flat | No route to the client prefix on the far host or its gateway |
| Reply counted on the internet-facing interface | Default route or policy rule on the far host |
| Firewall reports invalid state | Asymmetric path through a stateful device |
| Worked until a link failed over | New path is asymmetric, or rp_filter now rejects it |
Маршрут или транслация, после проверете в двете посоки
Двете поправки не са еквивалентни. Добавянето на маршрут запазва адреса на клиента непроменен, така че правилата, базирани на източник, одитните журнали и приложенията, които записват извикващия, продължават да работят; цената е, че всеки хоп, който взема решението, се нуждае от маршрута, което е повече места за грешка. Маскарад на далечния шлюз свива обратния път до един хоп, защото отговорът вече е адресиран до самия шлюз, и скрива кой клиент какво е направил.
iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADEИзберете го съзнателно: щом клиентите се показват като адреса на шлюза, ACL по източник спират да ги различават и conntrack трябва да пази съответствието, за да се пренапише отговорът обратно в тунела. Ако селекторите все още изключват префикса на клиента, NAT не променя нищо, защото заявката никога не е влязла в тунела.
Преди да го обявите за поправено, потвърдете четири неща по ред: маршрута на хоста, който изпраща отговора, маршрута на всеки хоп, който го препраща, селекторите, покриващи двата префикса, и запис, който показва отговора да влиза в тунела с очаквания източник. След това повторете теста от другия обект. Една минаваща посока е полуотворен дизайн, а втората посока обикновено се проваля по различна причина от тази, която току-що поправихте.