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 ја раскажува истата приказна за препратените порти.

Последната проверка е онаа што луѓето ја прескокнуваат: повторете го пребарувањето откако тунелот паднал и повторно се подигнал. Четири вредности треба да се совпаѓаат со тоа што сте го запишале: целта, следниот скок, уредот и избраниот извор. Ако некоја од нив се поместила, клиентот ја препишал табелата и поправката припаѓа на неговите куки, а не на историјата на shell.