VPN клијент на LAN серверу: зашто одговори одлазе погрешним путем

Симптоми прате један образац: хост ради, затим се као клијент повеже на VPN, и сада га LAN клијенти достижу док његови одговори нестају. Снимак на хосту показује да одговори излазе кроз уређај тунела уместо кроз LAN интерфејс. Ништа на тунелу није покварено, а поправка је рута, не поновно повезивање. Прођите четири провере испод редом и зауставите се на првој која не успе.

Одговор је нови пакет, не преокрет пута

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

Зато клијент пуног тунела на машини која такође служи LAN ствара тако збуњујућу грешку. Клијент инсталира подразумевану руту, или две полуподразумеване руте које неки клијенти преферирају, и одговор LAN клијенту сада одговара тунелу. Он одлази добављачу, који нема разлога да га проследи, а LAN клијент види истек времена иако је хост подигнут и одговара локално. Снимак то чини очигледним, а табела рутирања то објашњава.

Држите две подмреже у глави док читате остатак. Једна је VPN базен адреса из којег долазе удаљени клијенти, у овом примеру 10.64.0.0/24. Друга је LAN који мора да настави да ради, 172.16.24.0/24 са својим рутером на 172.16.24.1. Грешка је у томе што саобраћај између њих одлучује подразумевана рута.

Докажите то снимком и претрагом

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

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

Прочитајте одговор у два дела. Ако наведе dev tun0, хост ће одговор инкапсулирати и предати га добављачу, а LAN клијент га никада неће видети. Ако наведе dev eth0 али клијент ипак добије истек времена, рута је већ исправна и пакет се одбацује касније, што је други проблем са другом поправком.

Снимак у истом кораку решава сумњу коју ping не може. Долазак ехо одговора до LAN клијента доказује да неки пут ради, а не који га је интерфејс носио, зато снимак изводите на самом хосту и гледајте одакле оквири излазе. Штампач на истој подмрежи наставља да одговара, јер је његова директна рута специфичнија од подразумеване руте тунела. Прослеђени порт не успева баш као и сваки други ток, јер интерфејс бира табела, а не веза.

Инсталирајте најужу руту која надјачава тунел

Дужина префикса одлучује, не метрика, па рута за базен клијената преко LAN рутера побеђује сваку подразумевану руту коју VPN клијент инсталира. Операција на метрици није потребна, а подразумевана рута може да остане тачно тамо где ју је клијент поставио.

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

Користите replace уместо add, јер је клијент који се поново повеже већ инсталирао свој запис, а други add не успева са грешком да рута већ постоји, која звучи као проблем са дозволама. На Windows хосту еквивалент је route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, где -p чува запис кроз поновна покретања, јер клијент може поново да састави табелу кад се тунел врати. На савременом Windows хосту подржани еквивалент је New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, а старија наредба route задржана је као наслеђени облик.

Један детаљ одлучује да ли је то исправно или само уверљиво: следећи скок мора бити рутер који заиста поседује пут назад до клијената. Усмеравање руте на адресу до које се и сам долази кроз тунел ствара петљу која се појављује као повремени губитак, а не као чист неуспех. Потврдите да је следећи скок на LAN подмрежи пре него што унесете ред.

Задржите одговор након поновног повезивања

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

Заштитни зид са стањем ипак може да победи исправну руту. Ако снимак сада показује да одговор излази кроз eth0, а клијент и даље добија истек времена, проверите одбацује ли хост пакет пре слања. Строго филтрирање обрнутог пута и net.ipv4.conf.all.rp_filter постављен на 1 одбацују пакете чији се извор не би рутирао назад кроз интерфејс на који су стигли, а то је управо тај асиметрични случај који сте управо створили и затим поправили, а стање conntrack прича исту причу за прослеђене портове.

Последња провера је она коју људи прескачу: поновите претрагу након што је тунел пао и поново се подигао. Четири вредности треба да одговарају ономе што сте записали: одредиште, следећи скок, уређај и изабрани извор. Ако се било која померила, клијент је преписао табелу и поправка припада његовим кукама, а не историји љуске.