Маршрутталған OpenVPN туннелінде атауларды іздеу неге сәтсіз болады

Хост ping-ке мекенжай бойынша жауап береді, ал атау бойынша әр іздеуде сәтсіздікке ұшырайды. Туннель көтерілген және маршрут бар, сондықтан табиғи қорытынды — VPN дұрыс конфигурацияланбаған. Неғұрлым пайдалы қорытынды: іздеу ешқашан маршрутталатын болмаған, өйткені маршрутталған туннель unicast IP тасымалдайды, ал сұраныс арғы жақта жоқ сегментті іздеген broadcast болатын. Қабаттардың сәйкессіздігі көрінген соң, шешімдер өздігінен құны бойынша реттеледі.

Аңыз: атаулар сәтсіз болғандықтан туннель бұзылған

Симптом сенімді, өйткені атау қабатынан жоғарының бәрі жұмыс істейді. Мекенжайлар маршрутталады, интерфейс көтерілген, серіктес ping-ке жауап береді. Сәтсіздікке ұшырағаны — нүктеден нүктеге байланыс арқылы жолы болмаған анықтау механизмі, және бұл бұзылған туннельден өзге тұжырым. Осы екі тұжырымды ажырату диагностиканың басым бөлігі.

Оны туннель ақауы ретінде қарау көмектесе алмайтын профиль өзгерістеріне әкеледі. Опциялар қосу, шифрлауды өзгерту немесе клиентті қайта орнату broadcast-ты дәл орнында қалдырады.

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

TUN не тасымалдайды және нені тасымалдамайды

TUN құрылғысы — IP интерфейсі, және дәл осы оны маршрутталатын етеді. OpenVPN клиентке мекенжай мен маршруттар жиынын береді, содан кейін клиент серіктеске датаграммалар жібереді. Бұл модельде әр хост әр кадрды еститін ортақ байланыс жасайтын ештеңе жоқ.

Анықтау трафигі бұл модельге мүлде сыймайды. Windows-тың ескі атау сұраныстары, SSDP хабарламалары және mDNS сұраныстары бір мақсатқа емес, сегменттегі барлығына жіберіледі. Маршрутталған байланыста жіберуге «барлығы» жоқ. Осы механизмдердің әрқайсысы ортақ ортаны болжайды.

Сондықтан туннель сау болуы мүмкін, ал анықтау толық сәтсіз аяқталады. Біреу VPN өшіп қалды деп хабарлағанда, дәл осы сөйлемді ұстану керек.

Көпір шекараны алып тастау арқылы жұмыс істейді

TAP құрылғысы кадрларды тасымалдайды, ал көпір оны нақты LAN сегментіне қосады. Сонда клиент сол сегментте мекенжай ұстайды және оның broadcast трафигін естиді. Көпірдің атау мәселесін емдегендей көрінуінің себебі осы. Ол сондай-ақ клиентті мекенжайлау үшін осы сегментке тәуелді етеді.

Ем — маршруттау шекарасын алып тастау, туннель ішіндегі жаңа атау қабілеті емес. Сегмент broadcast ететіннің бәрі енді байланыстан да өтеді.

Кішкентай зертхана үшін бұл әділ айырбас. Тараңқы жұмыс күші үшін сирек.

DNS пен WINS-ті итеру — неғұрлым тар түзету

Клиентке сұрайтын нақты орын беріңіз. dhcp-option DNS және dhcp-option DOMAIN ішкі атауларды аймақты білетін серверге бағыттайды, ал әлі NetBIOS-қа сүйенетін Windows клиенті дәл сол жолмен WINS серверін ала алады. Туннель маршрутталған күйінде қалады, сегмент өз орнында қалады.

Екі шарт оның жұмыс істейтінін шешеді. Аталған сервер аймақ үшін жауап беруі керек, және сұранысқа туннель арқылы рұқсат болуы керек.

Резолверді сервердің өз қабығынан емес, клиенттен тексеріңіз. Жергілікті жұмыс істейтін резолвер туннельдің нені тасымалдайтыны туралы ештеңе айтпайды.

Қай қабат сәтсіз болғанын анықтаңыз

Алдымен мекенжайға ping жасаңыз, сосын атауды шешіп, қай сервер жауап бергенін оқыңыз. Аймақты хостингтемейтін сервердің теріс жауабы машинадан ешқашан шықпаған сұраныстан өзгеше көрінеді. Шешілетін, бірақ қосылымдарды қабылдамайтын атау — мүлде үшінші мәселе.

Multicast сол қабырғаның артында. 224.0.0.251 тәрізді топ әдепкіде маршрутталған туннель арқылы өткізілмейді, және топ үшін маршрут multicast-ты түсінетін жолсыз немесе LAN-дағы шағылыстырғышсыз жеткіліксіз.