LAN рутер и VPN клиент: два уреда, две табели за рутирање

Два уреда го препраќаат пакетот и секој води своја табела. LAN рутерот знае дека оддалечениот префикс му припаѓа на VPN клиентот, а VPN клиентот знае како да го достигне тој префикс преку својот тунел. Конфигурирајте само првата табела и пакетот пристигнува на машина без соодветна рута, па излегува повторно по стандардната. Тоа е целиот дефект, и од страната на LAN изгледа како рутирачка јамка, зашто речиси и е.

Нацртајте ги двата хопа пред да допрете рута

Земете илустративен распоред: LAN домаќини на 192.168.50.0/24, обичниот рутер на 192.168.50.1, посветен клиент на 192.168.50.15 и оддалечен LAN на 10.60.0.0/24 достапен само преку тунелот што го држи тој клиент. Ниту еден од двата приватни опсези не се преклопува со другиот, а тунелот има свој план за адреси.

Двата приватни опсези се важни зашто тие одлучуваат кој уред може да одговори. Оддалечената страна ќе види дека пакетот доаѓа од тунелската адреса на клиентот, а нејзиниот одговор мора да најде пат назад до 192.168.50.0/24. Ако е конфигуриран само излезниот правец, барањето може да работи додека одговорот исчезнува.

Чекор 1: насочете го рутерот кон клиентот, не кон тунелот

На LAN рутерот, додајте рута за дестинација чиј следен хоп е LAN адресата на клиентот:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

Тој запис вели „достави го до машината што може да тунелира“. Не кажува ништо за тоа како се гради тунелот и не ја заменува сопствената рута на клиентот. На управуван рутер еквивалентот живее на страницата за статични рути на уредот; на Linux рутер припаѓа на конфигурацијата на интерфејсот што го поседува LAN, не во shell што ќе го затворите.

Проверете го одговорот на втората команда. Ако го пријавува клиентот како gateway, а LAN интерфејсот како device, првиот хоп е точен и останатата работа е на другата машина.

Чекор 2: дајте му на клиентот сопствена рута од страната на тунелот

Клиентот сега прима пакет за 10.60.0.0/24 и ја прегледува својата табела. Ако неговата тунелска конфигурација инсталирала рута за тој префикс, пакетот продолжува шифриран. Ако не, пакетот се совпаѓа со обичната стандардна и се враќа на 192.168.50.1, кој го испраќа повторно до клиентот.

Погледнете пред да додадете нешто:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

Недостаток на префиксна рута во сите табели е наодот што го барате. Додајте ја преку сопствената конфигурација на тунелот, за да ја инсталира повторно следното преповрзување; рачната ip route add исчезнува со сесијата и го враќа дефектот во најнезгодниот момент. Следниот хоп е тунелскиот интерфејс или адресата што VPN-от ја доделува како свој партнер, зависно од клиентот, а адресата на партнерот треба да доаѓа од тековниот профил, не од стара белешка.

Јамката, кога се случува, во практика не е бесконечна: TTL паѓа на секое поминување и пакетот умира со порака за надминато време. Затоа повторуван traceroute може да укаже на циклус, додека клиент што едноставно не препраќа го испушта истиот пакет тивко.

Чекор 3: дозволете препраќање и изберете ја повратната патека

Примањето и препраќањето се различни дозволи. net.ipv4.ip_forward=1 на клиентот дозволува транзит на ниво на кернел, а правилото на огнениот ѕид сепак мора да го дозволи помеѓу LAN интерфејсот и тунелот. Правило што дозволува пристап до сопствената страница за управување на клиентот нема да дозволи транзит до оддалечениот LAN, а разликата лесно се пропушта кога истиот домаќин одговара на ping локално.

Оддалечената страна го има огледалниот проблем. Мора да знае дека 192.168.50.0/24 е достапна преку овој автентициран клиент. Со OpenVPN тоа обично значи рута по клиент што ја турка конфигурацијата на серверот, или датотека специфична за клиентот на серверот што го објавува LAN-от зад клиентот. Без тоа, оддалечениот LAN или го отфрла одговорот или го испраќа до својата стандардна порта, односно до интернет.

Преводот на изворот е алтернативата кога LAN префиксот не може да се објави. Ограничено masquerade правило на клиентот го препишува изворот на тунелската адреса, и одговорите потоа се враќаат природно. Тоа исто така крие кој LAN домаќин го поднел барањето и само по себе не му дозволува на оддалечената страна да започнува врски навнатре. Изберете го тој компромис свесно, наместо да додадете сеопфатно masquerade и да ја откриете несаканата последица подоцна.

Чекор 4: направете ги двете одлуки трајни, потоа тестирајте ја вистинската патека

Секоја рута има сопственик, а сопственик е конфигурацијата што се создава повторно при подигање или при преповрзување. На рутерот тоа може да биде запис за статична рута; на клиентот тоа може да биде VPN профилот, NetworkManager или systemd-networkd. Проверете со повторно поврзување на тунелот и рестартирање на клиентот, потоа прочитајте ја табелата повторно наместо да ѝ верувате на измената.

Чувајте ја недопрена стандардната рута што го носи надворешното поврзување на тунелот. Нејзината замена за да се „поедностави“ поставката ја крши шифрираната патека пред било кој внатрешен сообраќај да може да ја искористи, а симптомот е тунел што никогаш повторно не се воспоставува по промената.

Тестирајте од обичен LAN домаќин, не од клиентот, зашто барање создадено на клиентот никогаш не го вежба првиот хоп на рутерот. Донесете услуга што постои само на оддалечениот LAN и потврдете го телото на одговорот, потоа проверете ги бројачите или дневниците на клиентот за да го видите транзитот. Внатрешен traceroute што покажува приватни хопови докажува препраќање, не шифрирање: надворешната патека е одделно набљудување, и само сопствените бројачи на тунелскиот интерфејс покажуваат што излегло низ него.