LAN серверіндегі VPN клиенті: жауаптар неге дұрыс емес жолмен шығады

Симптомдар бір пішінді ұстанады: хост жұмыс істейді, содан кейін ол клиент ретінде 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

Екінші add орнына replace қолданыңыз, себебі қайта қосылған клиент өз жазбасын орнатып қойған болады, ал екінші 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 тарихында емес.