Бір NIC пе әлде екеу ме? VPN серверінің интерфейстер орналасуын шешу

Көптеген VPN сервері үшін бір физикалық адаптер жеткілікті, және бұл әмбебап шешім де емес. Шифрланған қосылым сол адаптерге келеді, VPN процесі оны шифрдан шығарады, содан кейін ішкі трафик виртуалды интерфейс арқылы шығады, жергілікті қызметке немесе маршрутталған LAN-ға жетпей тұрып. Бұл жұмыс істей ме, үш шартқа байланысты: меже қайда орналасқан, LAN-ның клиенттер пулына қайту жолы бар ма, және бір ортақ физикалық байланыс сіз мәлімдеген оқшаулауды бере ме. Осы үшеуіне жауап беріңіз, адаптер саны өзі шығады.

Мұны шешетін үш шарт

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

Үшінші шарт — бөлу. Бір адаптер әр пакеттің, шифрланған немесе емес, бір байланысты және әдетте бір саясат тізбегін бөлісетінін білдіреді, сондықтан бөлек аппараттық құралға тәуелді оқшаулау мәлімдемесін бір интерфейс қанағаттандырмайды. Бұл жол туралы факт, операциялық жүйенің конфигурациясы туралы емес. Туннель трафигін сүзуді жалғастыра аласыз, бірақ сізде жоқ шекараны мәлімдей алмайсыз.

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

Физикалық аймақтар, бөлек аплинктер, өткізу қабілеті немесе белдеуден тыс қалпына келтіру жолы оны ақтаса, екі адаптер заңды таңдау болып қалады. Бұл нақты талаптар және біреу аппараттық құрал тапсырыс беруден бұрын оларды айтуға тұрарлық.

Қызмет VPN хостінде жұмыс істегенде

Ең қарапайым жағдайда қайта бағыттау мүлдем қажет емес. Демон клиенттің пакеттерін туннель интерфейсінде қабылдап, жергілікті сокетке тапсырады, ал жауап сол интерфейспен қайтады. Хост үшін клиенттер пулының мекенжайы нағыз жергілікті мекенжай.

Екі нәрсе бәрібір дұрыс болуы керек: қызмет туннель жете алатын мекенжайда тыңдауы керек, ал хосттың тұрманы туннель интерфейсіне келетін трафикті қабылдауы керек. Екеуі де төмендегі командаларда көрінеді.

ss -lntup | grep -E "5432|8080"
ip -brief addr show
ip route get 10.8.0.6 from 10.8.0.1

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

Меже LAN-да болғанда

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

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

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A4 'chain forward'
ip route show table main | grep 10.8.0

Асимметриялық жол — классикалық симптом: клиент сұранысы келеді, жауап басқа маршрутизатор арқылы шығады, қосылым екі шетінде де қатесіз уақыты бітеді. Туннель туралы қандай да бір қорытынды жасамас бұрын екі жақтан да ұстап алыңыз.

Неліктен alias екінші аймақ құрмайды

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

Бөлек аймақ жолда нақты бөлуді қажет етеді, ал бұл талапты екінші адаптер қанағаттандырады. Егер ереже VPN-ге қарайтын трафиктің LAN-ға қарайтын трафикпен ешқашан хабар тарату доменін бөліспеуіне тәуелді болса, бір кабель бұл қасиетті бере алмайды, хост қалай мекенжайдалса да.

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

Орналасуды рұқсат еткен трафигіңізбен салыстырып тексеріңіз

Сервер тасымалдауы тиіс трафик кластарын тізіңіз: клиенттен хостқа, клиенттен LAN-ға, хосттан LAN-ға және шифрланған сыртқы қосылым. Әр кластың көзі, межесі және интерфейсі бар, ал орналасу төртеуін бірден қанағаттандыруы керек. Үшеуін өңдейтін жоба әдетте билет тудыратын жоба.

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

ip -brief addr
ip route
tcpdump -ni any udp port 51820 -c 5
tcpdump -ni tun0 -c 5

Егер сыртқы ұстап алу шифрланған трафикті, ішкі ұстап алу туннель интерфейсіндегі шифрдан шыққан трафикті көрсетсе, физикалық адаптер екеуін де тасымалдаса, бір NIC жұмысты атқарып тұр. Егер ішкі ұстап алу бос болса, мәселе туннельде немесе қайта бағыттау ережелерінде, адаптер санында емес. Топологияны сол екі ұстап алу мен маршруттау кестесінен шешіңіз, келесі өзгерістің салыстырар нәрсесі болады.