Следен скок во VPN рута: зошто портата мора локално да биде достапна

Адресата via на рутата мора да биде достапна на врската од која што праќате. Следете го предавањето, проверете го пребарувањето и тестирајте од домаќинот што го поседува сообраќајот.

Рутата кон 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

Потврдете го патот, потврдете едно одредиште, потоа држете ја линијата за бришење подготвена ако промената го направи домаќинот недостапен на начин што не сте го предвиделе. Ако рутата треба да преживее рестарт, ставете ја во мрежната конфигурација на домаќинот, а не во профил на shell, и тестирајте го рестартот пред да се потпрете на неа. Рута што постои само во shell-от што ја додал е рута што ќе ја дебагирате двапати.

Поврзани статии