OpenVPN va HTTPS 443-portda: tinglovchi kimniki?
TCP va UDP 443 alohida soketlar. Bitta TCP tinglovchini bo'lishish uchun egasi kerak, OpenVPN portini bo'lishish esa tor kelishuv, proxy hiylasi emas.
Ikki xizmat hech qachon raqobatlashmasdan 443-portda javob bera oladi, chunki tinglovchi faqat raqam bilan emas, transport, manzil va port birgalikda belgilanadi. Bitta mashinaga veb-server va OpenVPN qo'ying, va birinchi javob berishga arziydigan yagona savol — har bir jarayon yadrodan qaysi soketni so'raydi. Konfiguratsiyani tahrirlashdan oldin o'sha ro'yxatni yozib qo'ying, va «manzil allaqachon ishlatilmoqda» xatolarining ko'pchiligi o'z-o'zidan tushunarli bo'ladi. Ro'yxatdan keyingi hamma narsa UDP tinglovchi, umumiy TCP soket yoki protokol bo'yicha yo'naltiruvchi old qism o'rtasidagi tanlovdir.
Har bir jarayon so'raydigan soketdan boshlang
bind o'sha uchlikka ko'ra muvaffaqiyatli yoki muvaffaqiyatsiz bo'ladi, shuning uchun ikki demon faqat uch qism ham mos kelganda to'qnashadi. Shuning uchun TCP 443-dagi veb-sayt UDP 443-dagi OpenVPN tinglovchisi bilan cheksiz birga yashaydi, va shuning uchun ularning birini o'sha xostning ikkinchi lokal manziliga ko'chirish ham bahsni tugatadi. Tirik tinglovchilarni o'qing, ularni yaratishi kerak bo'lgan fayllarni emas, chunki eskirgan include yoki unutilgan unit fayl siz eslab qolgan tahrirdan uzoqroq yashaydi.
| 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 sifatida ss -lntup ishga tushiring va 443-ni tilga oladigan har bir satrni, IPv6 yozuvlari bilan birga o'qing. Odatda v6 joker tinglovchisi v4 trafigini ham qabul qiladi, va shu tariqa unutilgan tinglovchi siz javobgar deb hisoblagan faylni o'zgartirgandan keyin ham portni band tutadi. Jarayon nomi sizni hayratlantirsa, biror narsaga tegishdan oldin chiqishni ss -lntup 'sport = :443' bilan toraytiring.
Tarmoq ruxsat berganda tunnelni UDP-ga o'tkazing
UDP tinglovchisi to'qnashuvni butunlay chetlab o'tadi va odatda eng qisqa tuzatish bo'ladi, chunki hech qanday soket bo'lishilmaydi va yo'lga qo'shimcha mahsulot kirmaydi. Ammo bu bepul emas. Ba'zi mijoz tarmoqlari reset yubormasdan UDP 443-ni tashlab yuboradi, shuning uchun tunnel bind-da muvaffaqiyatsiz bo'lish o'rniga o'rnatilishni to'xtatadi, va foydalanuvchi o'qish uchun xatosiz VPN o'chganini xabar qiladi. UDP tinglovchisi veb-qatlamning qayta ishga tushishiga ham bardosh beradi, bu sayti tez-tez qayta joylashtiriladigan mashinada muhim. Foydalanuvchilar o'tirgan tarmoqdan sinab ko'ring, chunki serverdagi shell faqat server o'ziga yeta olishini isbotlaydi.
Transportni server konfiguratsiyasida va mijoz profilida birga o'zgartiring. Hali ham TCP so'raydigan profil faqat UDP tinglovchisiga qarshi qayta ulanish davrlarida aylanadi, va bu ikki faylni solishtirmaguningizcha tarmoq nosozligidek ko'rinadi.
VPN jarayoniga TCP 443 egaligini bering va qolganini uzating
TCP server rejimidagi Community OpenVPN kiruvchi ulanishning birinchi baytlarini o'qiydi va o'z protokoli bo'lmagan hamma narsani HTTPS backendga uzatadi, port-share direktivasi shu uchun. Backend TLS yoqilgan oddiy veb-server bo'lib, u direktivada URL bilan emas, xost va port bilan nomlanadi.
port-share 10.0.0.5 8080
Sayt ikkinchi xususiy manzilga ega mashinada o'sha satr VPN bo'lmagan trafikni 10.0.0.5:8080-ga yuboradi, shuning uchun HTTPS virtual xosti u yerda bog'langan bo'lishi va xavfsizlik devori lokal sakrashga ruxsat berishi kerak. Veb-server TLS-ni o'zi tugatishi kerak, chunki kelayotgan baytlar brauzerning asl qo'l berib ko'rishishi va orada hech narsa ularni shifrdan chiqarmagan. Direktivani oddiy HTTP tinglovchisiga qarating va brauzer noto'g'ri metod xatosini oladi, bu backend noto'g'ri joylashganidek emas, buzilgan sayt kabi o'qiladi. Direktiva faqat TCP server rejimida mavjud, UDP tinglovchisida esa tekshirish uchun oqim yo'q.
VPN jarayoni har bir ulanishni qabul qilgani uchun veb-ilova uzatilgan so'rovni tashrif buyuruvchidan emas, xostning o'z manzillaridan biridan kelayotganini ko'radi. Haqiqiy mijoz manzili kerak bo'lgan hamma narsa backenddagi PROXY protokoli yordamiga yoki uni qo'shadigan old qismga bog'liq. Backendni boshqa lokal manzilga ko'chirish tashrif buyuruvchining manzilini qaytarmaydi; u faqat sayt xostning qaysi manzillarini yozishini o'zgartiradi. Bu cheklovni analitika hisoboti savol ko'tarishidan oldin joylashtirish qaydlariga yozing.
Teskari proxy noto'g'ri vosita; to'rtinchi qatlam marshrutizatori unday emas
HTTP teskari proxy so'rovlarni o'qish uchun TLS-ni tugatadi, ya'ni OpenVPN oqimini tegmasdan o'tkaza olmaydi. SNI yoki birinchi paket tekshiruvi bo'yicha uzatadigan to'rtinchi qatlam marshrutizatori VPN bog'liq bo'lgan sessiyani tugatmasa, ikkalasining oldida tura oladi. Ikki qurilma diagrammada bir xil ko'rinadi, soketda esa butunlay boshqacha harakat qiladi.
Tijorat Access Server o'zining port bo'lishish sozlamalari bilan keladi, va ular jamiyat direktivasiga bir-biriga mos kelmaydi. Boshqasi uchun yozilgan qo'llanmani moslashtirishdan oldin mahsulot va versiyani aniqlang. Jimgina e'tiborsiz qoldirilgan ko'chirilgan sozlama sozlama yo'qligidan ham yomon, chunki keyin ham tinglovchilar ro'yxati ishonchli ko'rinadi.
Veb-sayt va tunnelni ikki alohida yo'l sifatida sinang
Saytni yuklang va tunnelni ulang, so'ngra 443 hozir qaysi jarayonga tegishli ekanini ko'rish uchun tinglovchilar ro'yxatini qayta o'qing. Yuklangan sahifa VPN haqida hech narsani isbotlamaydi, ulanadigan tunnel sayt haqida hech narsani isbotlamaydi, ikkalasi bir xil raqamdan foydalansa ham. Quyidagi uchta buyruq umumiy soketni, veb-yo'lni va VPN xizmatini shu tartibda tekshiradi.
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
Xuddi shu lahza uchun backendning kirish jurnalidagi mijoz manzilini VPN jurnalidagi manzil bilan solishtiring. Sayt har bir tashrif buyuruvchini xostning o'zi sifatida yozsa, uzatish ishlaydi, manzilni qayta ishlash ishlamaydi. Ikkala jurnal ham jim bo'lsa, old qism ulanishni hech qachon topshirmagan. Qanday bo'lsa ham, soketni kim qabul qilishini tinglovchilar ro'yxati hal qiladi, va yana bir faylni o'zgartirishdan oldin tasdiqlanishi kerak bo'lgan fakt shu.
Bu tinglovchilar xaritasini konfiguratsiya yonida qoldiring, shunda 443-ga keyingi tegadigan odam qaysi jarayon qabul qilishini va ikkinchi protokol qayerga ketganini biladi. Tahrir nima qilishi kerakligiga ishonish o'rniga o'zgarishdan keyin egalikni tasdiqlang.