Маршрут във VPN и следващ хоп: защо шлюзът трябва да е достъпен локално

Маршрутът към VPN мрежа носи два адреса, които лесно се бъркат: префиксът на дестинацията, който пакетът се опитва да достигне, и следващият хоп, който ще го премести една стъпка по-близо. На LAN хост този следващ хоп трябва да е рутер, до който наистина можете да достигнете по същата връзка. Отдалеченият VPN адрес не е следващ хоп, колкото и точно да съвпада с дестинацията, която имате предвид.

Това ръководство покрива обичайния случай: лаптоп на 192.168.20.0/24, VPN шлюз с LAN адрес 192.168.20.5 и отдалечена мрежа 10.70.0.0/24 зад този шлюз. Всички команди по-долу предполагат, че сте на лаптопа, освен ако не е казано друго.

Два адреса, един маршрут

Предвиденият запис е 10.70.0.0/24 via 192.168.20.5. Префиксът казва накъде отива пакетът; адресът via казва кой го носи там. Ядрото отказва да инсталира маршрут, чийто шлюз не може да достигне през интерфейса, който посочите, и този отказ е целият смисъл: следващ хоп, който се нуждае от тунела, за да е достъпен, не може да бъде следващият хоп, който изгражда тунела.

Затова първата проверка не е «дали шлюзът работи», а «дали шлюзът е на тази връзка». Собствената подмрежа на лаптопа, неговият ARP или съседски запис и интерфейсът в маршрута трябва да съвпадат. Адрес, който съществува само в 10.70.0.0/24, може да е дестинация на втори маршрут, но никога via на първия.

Към какво следващият хоп задължава шлюза

Инсталирането на маршрута на лаптопа решава само първото предаване. След това шлюзът се нуждае от собствен път: включено препращане, тунелен маршрут за 10.70.0.0/24 и всяка политика за достъп, която определя кой може да го използва. На Linux това е net.ipv4.ip_forward=1 плюс тунелен маршрут; защитна стена пред него се нуждае от правило, което разрешава препращания поток.

Обратната посока е частта, която хората забравят. Отдалечената страна трябва да има маршрут обратно към 192.168.20.0/24, или проектът трябва да преобразува източника на лаптопа в нещо, което отдалечената страна познава. Работещ ping от шлюза доказва, че шлюзът може да достигне отдалечената мрежа; той не казва нищо за това дали пакетите на лаптопа оцеляват при връщането.

Проверете търсенето от хоста, който изпраща

Попитайте ядрото кой следващ хоп би избрало и прочетете интерфейса в отговора:

ip route get 10.70.0.10
ip route show 10.70.0.0/24
ip neigh show 192.168.20.5

Ако търсенето показва шлюза и LAN интерфейса, първият участък е конфигуриран както трябва. Ако показва тунелното устройство, нещо по-рано в таблицата е по-конкретно и печели. Ако маршрутът изобщо не се инсталира, ядрото ви казва, че шлюзът е недостъпен, и това съобщение е по-полезно от всеки захват на пакети.

След това повторете теста от правилното място. Заявка, създадена на шлюза, използва собствения адрес на източника на шлюза, което може да скрие липсващ обратен маршрут или политика, която разрешава само определени източници. Ръководството за ip-route разделя дестинацията, шлюза и замяната onlink, и замяната си струва да бъде разбрана, преди да я използвате.

Не използвайте onlink, за да симулирате достъпност

onlink казва на ядрото да пропусне проверката за достъпност на шлюз и да изпрати до него въпреки това. Той не създава път, не разрешава ARP за адрес, който не съществува, и не кара отдалечен рутер да отговори на вашия Ethernet сегмент. Той е законен за шлюзове, които отговарят, но не се намират в свързана подмрежа, и е капан, когато се използва да заглуши грешка, която не сте обяснили.

Ако маршрутът се инсталира само с onlink, следващият въпрос е защо шлюзът не е там, където мислите. Грешен VLAN, втори адрес на грешния интерфейс или печатна грешка в последния октет дават това, и всяко от тях също чупи обратния път, щом трафикът започне да тече.

Тунелите точка-точка не са Ethernet

Тунелното устройство не прави ARP и често няма значима подмрежа от съседи. Маршрутите му често изглеждат като 10.70.0.0/24 dev tun0, без никакъв via, защото партньорът е единствената друга крайна точка. Копирането на via в LAN стил в тази таблица създава маршрут, който ядрото може да отхвърли или, по-лошо, такъв, който сочи към адрес, на който партньорът никога не отговаря.

Дръжте двата модела отделно в ръководството: LAN маршрутът има достъпен шлюз, тунелният маршрут има интерфейс и партньор. WireGuard, OpenVPN и IPsec показват малко по-различни форми, затова записвайте формата, която наистина сте използвали, вместо да обобщавате от един хост.

Добавете, потвърдете, върнете назад

Цялата промяна е три команди и една проверка и трябва да бъде записана в този ред:

sudo ip route add 10.70.0.0/24 via 192.168.20.5
ip route get 10.70.0.10
ping -c 3 10.70.0.10
sudo ip route del 10.70.0.0/24 via 192.168.20.5

Потвърдете пътя, потвърдете една дестинация, после дръжте реда за изтриване под ръка, в случай че промяната направи хоста недостъпен по начин, който не сте предвидили. Ако маршрутът трябва да оцелее след рестарт, сложете го в мрежовата конфигурация на хоста, а не в профил на обвивката, и тествайте рестарта, преди да разчитате на него. Маршрут, който съществува само в обвивката, която го е добавила, е маршрут, който ще отстранявате два пъти.