Следећи скок у 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

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