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-кө кийинки тийген адам кайсы процесс кабыл аларын жана экинчи протокол кайда кеткенин билет. Оңдоо эмне кылышы керек болгонуна ишенүүнүн ордуна өзгөртүүдөн кийин ээликти ырастаңыз.