Неге LAN хосты OpenVPN клиентінің мекенжайына ARP жібереді

LAN хосты мен VPN клиенті арасындағы қолжетімділік мәселелері көбінесе мекенжай жоспарының өзіне әкеледі. Ол хостқа 10.0.100.0/22 мекенжайында интерфейс берсеңіз, ол 10.0.100.0-ден 10.0.103.255-ке дейінгі әрбір мекенжайды тікелей қосылған деп есептейді, соның ішінде 10.0.101.0/24-те тыныш орналасқан клиенттер пулын. Жауап ешқашан маршрутизаторға бармайды, өйткені хост тұрғысынан ешбір маршрутизатор қатыспайды. Пакет көршіге адрестеліп, сыммен сұралады.

Бұл механизм тұтас есептер тобының артында тұр: туннель қосулы, серверде маршрут бар, бірақ LAN хосты клиентке жете алмайды.

/24-ті жұтып қоятын /22

Префиксті диапазон ретінде оқыңыз, жол ретінде емес. /22 префиксінде 1024 мекенжай бар, ал 10.0.100.0/22 10.0.100.0-ден 10.0.103.255-ке дейін созылады, сондықтан 10.0.101.0/24-тегі пул толығымен ішінде жатыр. Қате тексеруден өтеді, өйткені пулдың бірінші октеттері LAN-ның бірінші октеттерінен өзгеше көрінеді және тек үшінші октет ішкі орналасуды ашады. Екі диапазонды да санмен жазып, содан кейін оларды бөлек деп жариялаңыз.

Сол ішкі орналасу керісінше де көрінуі мүмкін. Қазір ешкім пайдаланбағандықтан бос көрінетін пул қандай да бір сайт маршрутизаторы жариялаған префикстің ішіне түсуі мүмкін, және мекенжай жоспары мұны көрсететін жалғыз құжат.

Тікелей байланыс ARP дегенді білдіреді, маршруттау емес

/22 интерфейсі бар хост 10.0.101.25-ке жібергенде, ядро межелі мекенжайды интерфейс префиксімен салыстырып, сәйкестік табады. Пакет маршрутталған пакеттің орнына көрші іздеуге айналады, ал Ethernet-те көрші іздеу сол мекенжайға ARP сұранысы болып табылады. Егер мекенжай маршрутталған шлюздің артындағы VPN клиентіне тиесілі болса, LAN-дағы ешбір хост оған ие емес, сондықтан сұраныс жауапсыз қалады және пакеттер тасталады. Туннель кінәлі емес, және клиент трафикті ешқашан көрмейді.

Сондықтан ақау асимметриялы және кейде үзілісті көрінеді. VPN хосты LAN-ға жиі жетеді, өйткені оның өз маршруттары дұрыс бағытты көрсетеді, ал LAN хосты жауап бере алмайды, ескі ARP жазбасын кэштегеннің бәрі симптомды жыпылықтатады.

TUN, TAP және әрқайсысы нені тасымалдайды

TUN құрылғысы IP пакеттерін, ал TAP құрылғысы Ethernet кадрларын тасымалдайды. Маршрутталған TUN байланысы IP қолжетімділігін қамтамасыз ету үшін ARP тасымалдауға міндетті емес, сондықтан жоғарыдағы жауапсыз сұраныс күтілетін нәрсе, бұзылған емес. TAP арнайы көпірмен broadcast доменін кеңейтіп, ARP-ны іске қоса алады, бірақ клиенттің нені көретінін өзгертеді, сол кадрлауды қолдайтын шеткі нүктелерді талап етеді және қабаттасқан префикс үшін жөндеу емес, желілік модельді қайта жобалау болып табылады. Мекенжай жоспарының қатесін емдеу үшін маршрутталған орналастыруды TAP-қа ауыстыру шағын мәселені үлкеніне айырбастайды.

Қорытынды жасамас бұрын ARP сұранысы қайда пайда болғанын және оны қай жүйе жібергенін белгілеңіз. Жіберуші сізге межелі мекенжай туралы не ойлайтынын айтады, туннельдің не істейтінін емес.

Қабаттаса алмайтын пул жобалаңыз

Әрбір қосылған префикстен және әрбір жарияланған сайт префиксінен тыс пул таңдап, содан кейін оны екі бағытта да қолжетімді ететін маршруттарды қосыңыз. Жоспардың пайдаланылмаған бөлігіндегі 10.8.0.0/24 тәрізді диапазонды ойлау оңай, ал оған жетуі керек LAN VPN серверіне бағытталған статикалық маршрут алады. Бөлуді, жарияланған маршруттарды, рұқсат етілген бастапқы мекенжайларды және брандмауэр ережелерін бірге өзгертіңіз, өйткені олар төрт параметр емес, бір жобаны сипаттайды.

Сервердегі Source NAT пулды LAN-нан маршрутталатын мекенжайдың артына жасыра алады және бұл заңды көшіру құралы. Ол көзді де қайта жазады, сондықтан LAN қосылымдарды жекелеген клиенттерге телу және клиент бойынша ережелерді қолдану мүмкіндігінен айырылады.

Қабылдау үшін нақты клиенттің іс жүзінде берілген мекенжайын және LAN хосттан нақты қолданба сұранысын пайдаланып, содан кейін жауаптың сыммен емес, жоспарланған шлюзбен жүргенін растаңыз.