OpenVPN және HTTPS 443 портында: тыңдаушы кімдікі?
TCP және UDP 443 бөлек сокеттер. Бір TCP тыңдаушысын бөлісу үшін иесі қажет, ал OpenVPN портын бөлісу — тар келісім, прокси айласы емес.
Екі қызмет те 443 портында ешқашан бәсекелеспей жауап бере алады, өйткені тыңдаушы тек нөмірмен емес, көлік, мекенжай және порт үшеуі бірге анықталады. Бір машинаға веб-сервер мен OpenVPN қойыңыз, және бірінші жауап беруге тұрарлық жалғыз сұрақ — әрбір процесс ядродан қай сокетті сұрайды. Конфигурацияны өңдеуден бұрын сол тізімді жазып қойыңыз, сонда «мекенжай әлдеқашан қолданыста» қателерінің көбі өзін өзі түсіндіреді. Тізімнен кейінгінің бәрі UDP тыңдаушысы, ортақ TCP сокеті немесе протокол бойынша маршруттайтын алдыңғы бөлік арасындағы таңдау.
Әрбір процесс сұрайтын сокеттен бастаңыз
Bind осы үштік бойынша сәтті немесе сәтсіз аяқталады, сондықтан екі демон үш бөлік түгел сәйкес келгенде ғана соқтығысады. Сондықтан TCP 443-тегі веб-сайт UDP 443-тегі OpenVPN тыңдаушысымен шексіз қатар өмір сүреді, және сондықтан олардың бірін сол хосттың екінші жергілікті мекенжайына көшіру де дауды аяқтайды. Тірі тыңдаушыларды оқыңыз, оларды жасауы тиіс файлдарды емес, өйткені ескірген include немесе ұмытылған unit файлы сіз есте сақтаған өңдеуден ұзақ өмір сүреді.
| Line in the listener list | What it establishes | What to do next |
|---|---|---|
| One udp row and one tcp row, each on 443 | Separate transport sockets, nothing contested | Point the VPN profile at udp and stop editing |
| A single tcp address and port listed by two processes | A real bind collision between two daemons | Move one service, or put a dispatcher in front of both |
| A proxy process owns the socket, no vpn process | The proxy accepts and has to hand off correctly | Check that its backend speaks the protocol it forwards |
root ретінде ss -lntup іске қосып, 443-ті атайтын әрбір жолды, IPv6 жазбаларын қоса, оқыңыз. Әдетте v6 жабайы тыңдаушысы v4 трафигін де қабылдайды, және осылайша ұмытылған тыңдаушы сіз жауапты деп санаған файлды өзгерткеннен кейін де портты босатпайды. Процесс атауы сізді таңқалдырса, бірдеңеге тиіспей тұрып шығысты ss -lntup 'sport = :443' арқылы тарылтыңыз.
Желі рұқсат етсе, туннельді UDP-ке көшіріңіз
UDP тыңдаушысы қақтығысты толығымен айналып өтеді және әдетте ең қысқа жөндеу болып табылады, өйткені ешбір сокет бөліспейді және жолға қосымша өнім кірмейді. Бірақ бұл тегін емес. Кейбір клиент желілері reset жібермей UDP 443-ті тастайды, сондықтан туннель bind-те сәтсіздікке ұшыраудың орнына орнатылуын тоқтатады, ал пайдаланушы оқитын қатесіз VPN өшкенін хабарлайды. UDP тыңдаушысы веб-қабаттың қайта іске қосылуына да шыдайды, бұл сайты жиі қайта орналастырылатын машинада маңызды. Пайдаланушылар отырған желіден сынаңыз, өйткені сервердегі shell тек сервердің өзіне жете алатынын дәлелдейді.
Көлікті сервер конфигурациясында және клиент профилінде бірге өзгертіңіз. Әлі TCP сұрайтын профиль тек UDP тыңдаушысына қарсы қайта қосылу циклінде айналады, және бұл екі файлды салыстырғанша желі ақауына ұқсайды.
VPN процесіне TCP 443-ті иеленуге рұқсат етіп, қалғанын жіберіңіз
TCP сервер режиміндегі Community OpenVPN кіріс қосылысының алғашқы байттарын оқып, өз протоколы болып табылмайтынның бәрін HTTPS бэкендіне жібереді, port-share директивасы осыған арналған. Бэкенд — TLS қосылған кәдімгі веб-сервер, ол сол директивада URL-мен емес, хост және порт арқылы аталады.
port-share 10.0.0.5 8080
Сайттың екінші жеке мекенжайы бар машинада бұл жол VPN емес трафикті 10.0.0.5:8080-ге жібереді, сондықтан HTTPS виртуалды хосты сол жерде байланыстыру керек және брандмауэр жергілікті секіріске рұқсат беруі керек. Веб-сервер TLS-ті өзі аяқтауы керек, өйткені келетін байттар браузердің түпнұсқа қол алысуы және арасында ешнәрсе оларды шифрдан шығармаған. Директиваны кәдімгі HTTP тыңдаушысына бағыттасаңыз, браузер жарамсыз әдіс қатесін алады, ол бэкенд дұрыс орнатылмағандай емес, сынған сайт сияқты оқылады. Директива тек TCP сервер режимінде бар, ал UDP тыңдаушысында тексеруге арналған ағын жоқ.
VPN процесі әрбір қосылысты қабылдайтындықтан, веб-қолданба жіберілген сұраныстың келушіден емес, хосттың өз мекенжайларының бірінен келетінін көреді. Нақты клиент мекенжайы қажет нәрсенің бәрі бэкендтегі PROXY протоколын қолдауға немесе оны қосатын алдыңғы бөлікке тәуелді. Бэкендті басқа жергілікті мекенжайға көшіру келушінің мекенжайын қайтармайды; ол сайттың хосттың қай мекенжайларын жазатынын ғана өзгертеді. Бұл шектеуді аналитикалық есеп сұрақ көтермей тұрып орналастыру жазбаларына жазыңыз.
Кері прокси — дұрыс емес құрал; төртінші қабат маршрутизаторы олай емес
HTTP кері прокси сұраныстарды оқу үшін TLS-ті аяқтайды, яғни OpenVPN ағынын тиіспестен өткізе алмайды. SNI немесе бірінші пакетті тексеру бойынша жіберетін төртінші қабат маршрутизаторы VPN тәуелді сессияны аяқтамаса, екеуінің алдында тұра алады. Екі құрылғы диаграммада ұқсас көрінеді, ал сокетте мүлде басқаша әрекет етеді.
Коммерциялық Access Server өзінің портты бөлісу параметрлерімен келеді, және олар қауымдастық директивасымен бір-біріне сәйкес келмейді. Екіншісі үшін жазылған нұсқаулықты бейімдеу алдында өнім мен нұсқаны анықтаңыз. Үнсіз еленбеген көшірілген параметр параметрдің жоқтығынан да нашар, өйткені одан кейін де тыңдаушылар тізімі сенімді көрінеді.
Веб-сайт пен туннельді екі бөлек жол ретінде сынаңыз
Сайтты жүктеп, туннельді қосыңыз, содан кейін 443-ке қазір қай процесс ие екенін көру үшін тыңдаушылар тізімін қайта оқыңыз. Жүктелген бет VPN туралы ештеңе дәлелдемейді, ал қосылған туннель сайт туралы ештеңе дәлелдемейді, екеуі бір нөмірді қолданса да. Төмендегі үш команда ортақ сокетті, веб-жолды және VPN қызметін осы ретпен тексереді.
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
Сол сәт үшін бэкендтің кіру журналындағы клиент мекенжайын VPN журналындағымен салыстырыңыз. Сайт әрбір келушіні хосттың өзі ретінде жазатын болса, жіберу жұмыс істейді, ал мекенжайды өңдеу жұмыс істемейді. Екі журнал да үнсіз болса, алдыңғы бөлік қосылысты ешқашан бермеген. Қалай болғанда да тыңдаушылар тізімі сокетті кім қабылдайтынын шешеді, және тағы бір файлды өзгерту алдында дәл осы фактіні растау керек.
Бұл тыңдаушылар картасын конфигурацияның қасында қалдырыңыз, сонда 443-ке келесі тиісетін адам қай процесс қабылдайтынын және екінші протокол қайда кеткенін біледі. Өңдеу не істеуі керек еді соған сенудің орнына өзгерістен кейін иелікті растаңыз.