OpenVPN клиентінің трафигін шлюзде қайдан бақылау керек

Қосылған клиент қандай межелерге жететінін білгіңіз келеді, сондықтан VPN серверінде қабық ашып ss тересіз. Пайдалы ештеңе көрінбейді, ал туннель бұзылды деген қорытынды сәл тым оңай келеді. Маршруттаушы OpenVPN шлюзі клиенттің пакеттерін жібереді; ол олардың TCP қосылыстарын аяқтамайды және олар үшін сокет ұстамайды. Дәлел басқа жерде тұрады, ал қай жерде екені трафиктің туннельден шыққаннан кейін қалай өңделетініне байланысты.

Қай конфигурацияны қарап отырғаныңызды анықтаңыз

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

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

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

Алдымен мекенжайды сессияға байланыстырыңыз

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

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

ip -4 addr show dev tun0
journalctl -u [email protected] --since '-10 min' | tail -n 40

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

Маршруттаушы шлюзде ағын кестесін оқыңыз

Мекенжай мен аралық белгіленгеннен кейін бақыланатын қосылыстардың тек оқуға арналған тізімі шлюздің ол үшін не жіберіп жатқанын көрсетеді. Бүкіл кестені оқымау үшін бастапқы көз бойынша сүзіңіз.

sudo conntrack -L -p tcp -f ipv4 --orig-src 10.8.0.37

Әр жазба екі tuple ұстайды, бастапқы және жауап, бұлар бір ағынның екі бағыты, екі қолданба емес. Бастау көзінің NAT жолында бастапқы tuple туннель мекенжайын сақтайды, ал жауап жағы аударылған шлюз мекенжайын көрсетеді, және дәл осы шығысты бірінші көзқараста қате көрінетін етеді.

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

Оқуды растау үшін бір шектеулі түсірілім

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

sudo tcpdump -ni tun0 -nn -c 50 'host 10.8.0.37 and tcp'

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

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

Прокси журналдары және көргеніңіздің шектері

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

Әр сұрау әдепкі бойынша журналданады деп болжаудың орнына орналастырылған нұсқаның журналдау конфигурациясын тексеріңіз.

Соңында, ауқым туралы нақты болыңыз. Меже мекенжайы мен порт метадеректер, URL да емес, бет мазмұны да емес, өйткені ішкі HTTPS сессиясы туннельге қарамастан өз қорғанысын сақтайды. Нені бақылағаныңызды, қай бақылау нүктесінен және қай уақытта екенін хабарлаңыз.