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, а не љусци коју ћете затворити.

Проверите одговор друге команде. Ако пријављује клијента као 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 са приватним скоковима доказује прослеђивање, не шифрирање: спољни пут је одвојено посматрање, и само бројачи интерфејса тунела показују шта је кроз њега изашло.