OpenVPN 443 портунда дагы эле бөгөттөлүп жатабы? Тармак эмнени текшерерин караңыз
443 порту номурду өзгөртөт, протоколдун формасын эмес. Эгер жол TLSди текшерсе же аяктаса, кийинки сыноо — каптама жана туура хост маршруту.
Туннель үй линиясынан туташып, мейманкана же кеңсе тармагында токтоп калат, ал эми серверди 443 портуна которуу эч нерсени өзгөрткөн жок. Бул натыйжа формасы болгудай кеңири таралган: порт жеңил бөлүгү эле, чечимдин калганы кардар менен сервердин ортосунда отургандардын баарына таандык. Эки суроо учурлардын көбүн чечет, жана алардын экөө тең шифрлер жөнүндө эмес. Тармак ошол дарекке TLS кол алышууну кабыл алабы, жана туннель турганда кардар өз каптамасына маршрутту сактайбы?
Кол алышуу номурдан көбүрөөк ачып берет
TCP 443төгү жергиликтүү VPN угуучусу биринчи пакеттен эле өз протоколунда сүйлөйт. ClientHelloдо версия талаасы, туш келди маани жана кеңейтүүлөрдүн тизмеси бар, ал эми бир нече жүз байт окуган түзмөк эч нерсени дешифрлебей эле айырманы көрө алат. Порт номурларын канааттандыруу арзан, ал эми чыпка чындыгында протоколдун формасын текшерет. Эрежелер адатта протокол боюнча да жазылат, ошондуктан TLSди текшерген саясат UDP жөнүндө эч нерсе айтпайт.
Жарактуу TLS сессиясын талап кылган ачык прокси орнотуу учурунда эле байланышты үзөт, көбүнчө TCP кол алышуу аяктагандан кийин. Бул деталь кийинчерээк маанилүү, анткени сокет түзүлгөндөн кийин кардардын журналы токтойт дегенди билдирет.
Агымды каптоо эки ийгиликсиздик чекитин түзөт
stunnel сыяктуу TLS каптамасы күтүлгөн форманы калыбына келтирет: кардар жергиликтүү угуучуга туташат, каптама сервер менен 443тө чыныгы TLS сессиясын ачат, ал эми сервердеги экинчи каптама дешифрленген байттарды VPN демонуна өткөрөт. Сырткы сессия эми башка ар кандай HTTPS байланышындай көрүнөт. Сервердеги VPN демону loopbackте гана угуусу керек, анткени каптамадан тышкары эч нерсе ага жетүүгө муктаж эмес.
Бул курулуш үчүн үч өзүнчө нерсе дал келиши керек. Кардар профили жергиликтүү угуучуга көрсөтөт, сервер сертификаты кардар текшерген атка дал келет, ал эми сервер тараптагы өткөрүү демон чындыгында колдонгон портту бутага алат. Алардын биринде жаңылсаңыз, байланыш VPN катмарына жетпей эле өлөт. Анда сертификат дал келбестиги VPN катасы катары эмес, каптама катасы катары көрүнөт, ошондуктан эки журналды катар окуган жөн.
Каптамага барган жол — тузак
Туннель көтөрүлгөндөн кийин демейки маршрут анын ичине көрсөтөт, ал эми сырткы TLS сессиясы өзү ташыган туннелге кирбеген жолду талап кылат. Кадимки VPN кардары өзү чалган даректи коргойт; капталган кардар өз loopbackине чалат, ошондуктан каптаманын барар дареги бул коргоого көрүнбөйт.
sudo ip route add 198.51.100.20 via 192.168.0.1
sudo openvpn --config client.ovpn
sudo ip route del 198.51.100.20
Так даректерди өзүңүз толтурасыз, ал эми маршрут байланыштын бүт өмүрүндө болушу керек, иштетилгенде гана эмес. Маршрутту кардардан мурун кошуп, кийин өчүргөн кичинекей каптама скрипти эсте калган буйруктан ишенимдүү.
Androidде бул өзгөчөлүктүн баламасы — ар бир колдонмо үчүн жөндөө: каптама колдонмосун туннелден чыгарыңыз, анын өз трафиги уюлдук байланыш аркылуу чыксын. Чыгарбасаңыз, каптама курууга аракет кылган туннелдин ичине багытталат, ал эми кайра туташуу цикли сервер маселесиндей көрүнөт.
Бир нерсени өзгөртүүдөн мурун убакытты окуңуз
Ар жолу бирдей аралыктан кийин өлгөн сессия криптографиялык бузулуу эмес, саясаттын кол тамгасы, ал эми узак мөөнөттүү агым чектөөлөрү так ушундай үлгүнү берет. Кол алышуудан кийин дароо кайра коюлган байланыш сертификаттар чынжырын жактырбаган проксиге ишарат кылат.
Эки тармактан тең кадимки HTTPS сайтынын сертификат берүүчүсүн салыштырыңыз. Чектелген тармакта берүүчү башка болсо, бир нерсе TLSди ортодо аяктап жатат, жана эч бир каптама бул тоскоолдуктан өзгөрүүсүз өтпөйт. Ошол эле салыштыруу бөгөт сервер атыңызгабы же ошол даректеги ар бир TLS сессиясынабы багытталганын айтат.
Байкалган жүрүм-турумду жазыңыз: сессия канча турду, сокет ачылдыбы, каптама кол алышууну жазып алдыбы. Алардын ар бири кийинки сыноону тарытат.
Бир убакта бир өзгөрмөнү сынаңыз
Алгач UDPни текшериңиз, анткени кээ бир тармактар аны толук таштайт, ал эми UDP бузулушу 443 жөнүндө эч нерсе айтпайт. Анан каптамасыз TCP 443тү, андан кийин 443төгү каптаманы сынап көрүңүз. Ар бир кадамда кардар журналын окуп, жүрүм-турум өзгөргөндө эле токтоңуз.
Ар бир аракетте бир элементти өзгөртүңүз. Жаңы порт, жаңы каптама жана жаңы шифр бир эле жүгүртүүдө болсо, үчөөнүн кайсынысы маанилүү болгонун айта албайсыз.