Хоёр үйлчилгээ хоёулаа 443 порт дээр хэзээ ч өрсөлдөхгүйгээр хариулж чадна, учир нь сонсогч нь зөвхөн дугаараар бус, тээвэр, хаяг, порт гурав нийлж тодорхойлогддог. Нэг машин дээр вэб сервер ба OpenVPN тавь, тэгээд хамгийн түрүүнд хариулах ёстой цорын ганц асуулт бол процесс бүр цөмөөс аль сокетыг хүсч байгаа юм. Тохиргоог засахын өмнө тэр жагсаалтыг бичиж тавь, тэгвэл «хаяг аль хэдийн ашиглагдаж байна» гэсэн алдааны ихэнх нь өөрөө тайлбарлагдана. Жагсаалтын дараах бүхэн нь UDP сонсогч, хуваалцсан TCP сокет эсвэл протоколоор чиглүүлэх урд хэсгийн хоорондын сонголт юм.

Процесс бүрийн хүсдэг сокетоос эхэл

bind энэ гурваар амжилттай эсвэл бүтэлгүй болдог тул хоёр демон зөвхөн гурван хэсэг бүгд давхцах үед мөргөлддөг. Тиймээс TCP 443 дээрх вэбсайт UDP 443 дээрх OpenVPN сонсогчтой хязгааргүй зэрэгцэн оршдог, мөн тиймээс тэдний нэгийг нэг хост дээрх хоёр дахь локал хаяг руу зөөх нь маргааныг мөн дуусгадаг. Амьд сонсогчдыг унш, тэднийг үүсгэх ёстой байсан файлуудыг биш, учир нь хуучирсан include эсвэл мартагдсан unit файл чиний санаж байгаа засвараас урт насалдаг.

Line in the listener listWhat it establishesWhat to do next
One udp row and one tcp row, each on 443Separate transport sockets, nothing contestedPoint the VPN profile at udp and stop editing
A single tcp address and port listed by two processesA real bind collision between two daemonsMove one service, or put a dispatcher in front of both
A proxy process owns the socket, no vpn processThe proxy accepts and has to hand off correctlyCheck 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-т дараагийн хүрэх хүн аль процесс хүлээж авах, нөгөө протокол хаашаа явсныг мэдэх болно. Засвар юу хийх ёстой байсанд итгэхийн оронд өөрчлөлтийн дараа эзэмшлийг баталгаажуул.

Холбоотой нийтлэлүүд