Thực đơn
trang chủSự liên quan

Giao thức SOCKS. Máy chủ proxy phổ quát

Khi làm việc với proxy, điều quan trọng là phải chọn đúng loại proxy cho nhiệm vụ của bạn để tránh vấn đề có thể xảy ra và đạt được mục tiêu của bạn. Được sử dụng phổ biến nhất là proxy HTTP và proxy Vớ5. Sự khác biệt giữa chúng nằm ở mức độ ẩn danh, giao thức được sử dụng, phương thức truyền dữ liệu được sử dụng khi hoạt động như một proxy, cũng như trong một số trường hợp. chức năng bổ sung. Chúng ta hãy xem xét từng loại proxy riêng biệt.

Các tính năng của proxy HTTP

Hãy bắt đầu với proxy HTTP. Trong quá trình làm việc, họ sử dụng giao thức HTTP, được thiết kế để truy cập các trang web, tải xuống và truyền tệp cũng như khi làm việc với một số chương trình sử dụng giao thức này để kết nối thông qua proxy. Các yêu cầu được đưa ra khi làm việc với máy chủ proxy HTTP không được gửi trực tiếp mà sử dụng máy chủ proxy làm trung gian, thay mặt nó gửi yêu cầu.

Ngoài ra, trong giao thức proxy HTTP còn có bộ đệm, giúp tăng tốc độ tải trang thông qua việc sử dụng các tệp đã lưu, cũng như giám sát và lọc lưu lượng mạng, đặt giới hạn tốc độ, chặn các tài nguyên không mong muốn, thu thập số liệu thống kê bằng cách lưu nhật ký, v.v.

Proxy của giao thức này khác nhau về mức độ ẩn danh. Nổi bật các loại sau Proxy HTTP để ẩn danh:

Proxy minh bạch không che giấu địa chỉ IP thực và cũng không che giấu sự thật rằng máy chủ proxy được sử dụng để truy cập tài nguyên. Những proxy như vậy hiếm khi được sử dụng, chủ yếu để chuyển hướng người dùng đến một máy chủ proxy khác,

Proxy ẩn danh. Chúng truyền thông tin mà proxy được sử dụng, tuy nhiên, địa chỉ IP của bạn bị che và thay thế bằng một địa chỉ IP khác, cung cấp mức độ bảo mật đáng tin cậy.

Proxy ưu tú. Chúng che giấu việc sử dụng proxy và cũng che giấu địa chỉ IP một cách đáng tin cậy, điều này khiến chúng trở nên an toàn nhất trong số các proxy HTTP. Máy chủ bạn đang cố truy cập sẽ cho rằng kết nối của bạn là trực tiếp mà không cần sử dụng máy chủ proxy.

Chúng ta cũng nên nêu bật các proxy HTTPS sử dụng giao thức SSL. Chúng là một kiểu con của giao thức HTTP sử dụng kết nối an toàn. Lưu lượng mạng được truyền bởi các proxy này được mã hóa an toàn, đảm bảo mức độ ẩn danh cao nhất. Theo quy định, các proxy như vậy được sử dụng để đảm bảo an ninh cho mạng lưới ngân hàng, trong các tổ chức thương mại để tạo ra sự an toàn mạng công ty và trong các kết nối khác yêu cầu bảo mật. Các tính năng khác giống như các tính năng của giao thức HTTP.

Các tính năng của proxy Vớ5

Một giao thức khác được người dùng phổ biến là Socks5. Các máy chủ proxy làm việc với giao thức này ban đầu được ẩn danh vì chúng truyền lưu lượng mạng vào thể tinh khiết mà không để lộ tiêu đề HTTP. Do đó, máy chủ bạn đang cố truy cập sẽ không biết rằng bạn đang sử dụng máy chủ proxy và sẽ không nhận được địa chỉ IP của bạn.

Proxy của Vớ5, hỗ trợ như sau giao thức mạng: HTTP, HTTPS, FTP và các tính năng của chúng: bộ nhớ đệm, Kết nối SSL, xác thực. Ngoài ra, proxy giao thức của Vớ5 sử dụng kết nối UDP và TPC, giúp mở rộng phạm vi ứng dụng và khiến chúng trở thành máy chủ proxy hiện đại có nhiều chức năng nhất. Ban đầu, giao thức Vớ5 được dự định hoạt động với phần mềm. Vì lý do này, hầu hết các chương trình đều hỗ trợ giao thức này để kết nối qua proxy. Máy chủ proxy của Vớ5 cũng có một tính năng hay cho phép bạn xây dựng chuỗi máy chủ proxy, tính năng này rất hữu ích để giải quyết một số vấn đề khi làm việc trên Internet.

Nếu bạn so sánh proxy HTTP và Socks5, tốt nhất nên sử dụng proxy sau. Vì họ ẩn danh hơn nên họ hỗ trợ nhiều tính năng hơn, đồng thời hoạt động với mọi trang web và chương trình hỗ trợ kết nối thông qua proxy. Bạn có thể truy cập trang web của chúng tôi bằng cách đặt hàng trong tài khoản cá nhân của bạn.

Bài viết dành cho giao thức SOCKS5 - cấu trúc bên trong, ứng dụng thực tế của nó, cũng như các máy chủ và máy khách SOCKS có sẵn cho nền tảng Unix

[Valentin Sinitsyn (val AT linuxcenter DOT ru)]

“Xin lỗi, Pooh,” SAVA nói. - Cọp nhai hết dây từ máy chủ thư, thư đã lâu không đến...
“Dây điện,” Pooh giận dữ nghĩ. - Đan tất từ ​​những sợi dây này.

Andrey Shcherbkov “9600 baud và thế là xong, thế thôi, thế thôi…”

Trong bài viết này chúng ta sẽ nói về giao thức SOCKS[ chú thích cuối trang: "vớ" - tiếng Anh. "vớ", "vớ"]. Với sự giúp đỡ của nó, bạn có thể giải quyết được nhiều vấn đề nhất nhiệm vụ khác nhau: tổ chức quyền truy cập an toàn vào các dịch vụ nằm phía sau tường lửa, ẩn địa chỉ IP thực của bạn khi làm việc với các tài nguyên mạng không thân thiện hoặc triển khai máy chủ proxy phổ quát hỗ trợ mọi giao thức cấp ứng dụng (HTTP, FTP, POP3/SMTP, ICQ, v.v.). Thật không may, bất chấp sự đơn giản và phong phú của SOCKS, nhiều quản trị viên hệ thống vẫn chưa quen với nó và không biết nó có thể hữu ích như thế nào. Tôi muốn hy vọng rằng sau khi đọc tài liệu này, giao thức bị lãng quên không đáng có sẽ chiếm được vị trí xứng đáng trong kho vũ khí của họ. Hãy đặt chỗ ngay: tất cả phần trình bày tiếp theo sẽ đề cập đến phiên bản thứ năm của SOCKS, SOCKS5. Phiên bản thứ tư trước đó (SOCKS4) vẫn đang được lưu hành trên Internet, tuy nhiên, khả năng của nó bị hạn chế hơn.

Nhân tiện, tên của giao thức không liên quan gì đến các mặt hàng hàng dệt kim được đề cập trong phần ngoại truyện và là tên viết tắt đơn giản của “SOCK-et-S” - “sockets”, hoặc, theo cách dịch quen thuộc hơn của chuyên gia máy tính tai, “ổ cắm”. Thuật ngữ này đã được những người sáng tạo đề xuất như một phương án hoạt động và nó đã bị mắc kẹt. Như bạn đã biết, socket là nền tảng của bất kỳ API nào triển khai mạng- Unix, Winsock, v.v. Để gửi dữ liệu qua mạng, ứng dụng chỉ cần ghi dữ liệu vào socket, tương tự như những gì được thực hiện khi lưu trữ thông tin trong một tệp cục bộ. Trong cả hai trường hợp, chương trình không phải lo lắng về những gì đang xảy ra “đằng sau” - việc bổ sung dữ liệu người dùng với thông tin dịch vụ, chia nó thành các phân đoạn với việc đóng gói sau đó thành các datagram và việc gửi vật lý được thực hiện bởi các phần khác của hệ điều hành - ngăn xếp TCP / IP và trình điều khiển thiết bị mà ứng dụng không biết gì về nó. Sự “phân công lao động” này cho phép bạn thay đổi quy trình gửi tin nhắn theo ý muốn, miễn là giao diện lập trình ứng dụng không đổi. Chính đặc điểm này làm nền tảng cho hệ tư tưởng SOCKS. Nhiệm vụ chính của giao thức này là đưa vào quá trình trao đổi dữ liệu “bình thường” một trung gian nhất định được gọi là máy chủ SOCKS hoặc proxy SOCKS. Khi một máy khách (một ứng dụng hỗ trợ SOCKS: trình duyệt web Mozilla, máy khách ICQ Miranda IM, v.v., xem bên dưới) muốn gửi bất kỳ thông tin nào qua mạng, nó sẽ thiết lập kết nối không phải với người nhận thực sự mà với máy chủ SOCKS, đến lượt nó sẽ chuyển tiếp dữ liệu đến đích nhưng thay mặt nó. Từ quan điểm của máy chủ "thực" (ví dụ: trang web mà người dùng muốn xem Mozilla Firefox) SOCKS proxy là ứng dụng khách phổ biến nhất. Do đó, danh tính (địa chỉ IP) của máy khách thực sự sẽ bị ẩn khỏi máy chủ phục vụ nó. Tình huống rất thuận tiện này tiềm ẩn nhiều nguy hiểm (bạn có thể ẩn Bạn, nhưng họ có thể từ bạn), do đó, các máy chủ SOCKS ngoài đời thực đã phát triển các sơ đồ kiểm soát truy cập (cấm các kết nối đến và đi đến một danh sách địa chỉ nhất định) và hỗ trợ ủy quyền người dùng bằng mật khẩu (xem bên dưới).

Lưu ý rằng vì SOCKS hoạt động ở mức thấp hơn mức ứng dụng (cụ thể là truyền tải) của mô hình OSI, nên sự hỗ trợ của nó sẽ không yêu cầu bất kỳ thay đổi nào về logic của máy khách, chứ đừng nói đến máy chủ. Thật vậy, tất cả những gì cần thiết là sửa đổi việc thực hiện các chức năng chịu trách nhiệm tạo ra Kết nối mạng và gửi dữ liệu: connect(), bind(), send(), v.v. Trong thực tế, điều này thường đạt được bằng cách chặn các cuộc gọi hệ thống và sau đó thay thế chúng bằng các đối tác do người dùng xác định hỗ trợ SOCKS. Không có thay đổi về mã nguồn ứng dụng khách, theo quy định, không cần phải truy cập vào các văn bản nguồn ít hơn nhiều. Quy trình mạnh mẽ này được gọi là “soxification” và sẽ được thảo luận chi tiết dưới đây.

Bây giờ chúng ta đã hiểu biết chung về SOCKS, chúng ta có thể chuyển sang cái nhìn chi tiết hơn. của giao thức này.

Thông số kỹ thuật SOCKS5

Giao thức SOCKS5 được mô tả chi tiết trong RFC1928. Không giống như các tiêu chuẩn khổng lồ như HTTP 1.1, đặc tả SOCKS bao gồm 9 trang và bất kỳ ai cũng có thể dễ dàng phân tích cú pháp. Thông tin được cung cấp ở đây là một bản tóm tắt ngắn gọn về nó và nhằm mục đích giúp bạn trong vấn đề đơn giản này.

Như đã lưu ý trước đó, SOCKS5 là giao thức lớp vận chuyển. “Láng giềng” của nó - TCP và UDP được sử dụng trực tiếp để truyền dữ liệu đến từ lớp ứng dụng (từ ứng dụng tùy chỉnh), có nghĩa là proxy SOCKS phải có khả năng hoạt động chính xác với từng proxy đó. Cũng lưu ý rằng giao thức ICMP được sử dụng bởi các tiện ích ping và traceroute nằm bên dưới lớp vận chuyển, và do đó, thật không may, không thể được đồng bộ hóa.[ Chú thích cuối trang: có các phần mở rộng không chuẩn cho giao thức SOCKS cho phép bạn làm việc với ICMP, tuy nhiên, chúng sẽ không được thảo luận trong bài viết này].

Trước khi gửi bất kỳ dữ liệu nào, khách hàng phải thực hiện quy trình ủy quyền trên máy chủ SOCKS. Để thực hiện việc này, nó sẽ mở kết nối TCP tới cổng 1080 (giá trị mặc định) của máy chủ SOCKS và gửi một tin nhắn qua đó chứa mã số của các phương thức xác thực mà nó hỗ trợ. Máy chủ SOCKS chọn một trong các phương thức theo ý mình và báo cáo số của nó cho khách hàng. Danh sách một số giá trị có thể có được đưa ra trong Bảng 1. Như bạn có thể dễ dàng thấy, xác thực có thể không có (trong thực tế, điều này rất có thể có nghĩa là máy chủ SOCKS phân biệt máy khách theo địa chỉ IP của chúng) hoặc dựa trên tên người dùng và mật khẩu. Trong trường hợp sau có thể một số lượng lớn nhiều tùy chọn khác nhau, từ “Xác thực tên người dùng/mật khẩu” tầm thường (RFC 1929) cung cấp việc truyền mật khẩu tới biểu mẫu mở sang CHAP (mật khẩu được mã hóa, dữ liệu đơn giản) và GSSAPI (RFC 1961) an toàn hơn nhiều, có thể được sử dụng để bảo vệ hoàn toàn lưu lượng truy cập bằng mật mã. Sau khi ủy quyền thành công, khách hàng có thể gửi yêu cầu (lệnh), thiết lập kết nối gửi đi và thậm chí nhận các kết nối đến.

Thiết lập kết nối TCP đi

Để thiết lập kết nối TCP gửi đi, máy khách sẽ gửi yêu cầu “CONNECT” đến máy chủ SOCKS, yêu cầu này chỉ định địa chỉ và cổng phân phối. Để xác định nút người nhận, cả địa chỉ IP (IPv4/IPv6 đều được hỗ trợ) và địa chỉ IP chính thức Tên miền. Trong trường hợp sau, máy chủ SOCKS sẽ đảm nhiệm việc giải quyết chúng, do đó, về nguyên tắc, mạng mà máy khách vận hành có thể hoạt động mà không cần máy chủ DNS. Trong thông báo phản hồi, máy chủ SOCKS báo cáo mã lỗi (như thường lệ, 0 cho biết thao tác đã thành công), cũng như địa chỉ IP (BND.ADDR) và cổng TCP (BND.PORT) sẽ được sử dụng để thực sự giao tiếp với nút thắt được yêu cầu. Vì máy chủ SOCKS thường có nhiều hơn một giao diện mạng, địa chỉ IP đã cho có thể khác với kết nối điều khiển được thiết lập. Sau đó, máy khách sẽ mở một phiên TCP mới với BND.ADDR:BND.PORT và gửi dữ liệu. Kết nối TCP gửi đi sẽ bị chấm dứt khi phiên điều khiển bị đóng. Lưu ý rằng yêu cầu CONNECT có thể bị proxy SOCKS từ chối nếu địa chỉ nguồn (máy khách) hoặc đích (máy chủ) bị cấm [ Chú thích cuối trang: hoặc không được cho phép rõ ràng, tùy thuộc vào cách triển khai cụ thể và chính sách được chọn] phục vụ quản trị hệ thống.

Thiết lập kết nối UDP đi

Không giống như giao thức truyền phát TCP, bao gồm việc thiết lập một phiên, giao thức UDP dựa trên datagram và do đó sử dụng phức tạp hơn một chút. Hỗ trợ của nó chỉ xuất hiện trong SOCKS5.

Trước khi gửi datagram UDP, máy khách yêu cầu máy chủ SOCKS Hiệp hội UDP bằng lệnh "UDP ASSOCIATE". Liên kết UDP là một loại phiên ảo giữa máy khách và máy chủ SOCKS. Trong yêu cầu gửi đi, khách hàng chỉ định bị cáo buộcđịa chỉ và cổng sẽ đóng vai trò là nguồn của các gói dữ liệu UDP trong tương lai. Nếu thông tin này vẫn chưa được biết khi liên kết UDP được thiết lập, khách hàng nên sử dụng kết hợp 0.0.0.0:0 (hoặc, giả sử, x.x.x.x:0 nếu chỉ không xác định được số cổng). Trong thông báo phản hồi, máy chủ SOCKS chỉ định địa chỉ IP (BND.ADDR) và cổng UDP (BND.PORT) mà các gói dữ liệu gửi đi sẽ được gửi đến. Trong trường hợp này, địa chỉ và cổng của người nhận thực sự của họ được chỉ định trực tiếp trong phần nội dung (chúng ta có thể nói rằng quá trình đóng gói UDP diễn ra). E Bạn các tham số, cùng với địa chỉ và cổng của người gửi, được sử dụng để quyết định liệu một datagram có thể được gửi hay không. Như bạn có thể dễ dàng thấy, điều này tạo ra tải bổ sung trên máy chủ SOCKS: các quy tắc lọc phải được áp dụng cho mỗi gói dữ liệu UDP, trong khi đó, trong trường hợp kết nối TCP, tính hợp pháp của nó được đánh giá một lần, tại thời điểm máy chủ SOCKS thực thi lệnh “ lệnh KẾT NỐI”. Theo tiêu chuẩn, máy chủ SOCKS phải đảm bảo rằng địa chỉ IP của người gửi datagram khớp với địa chỉ của máy chủ đã tạo liên kết UDP. Liên kết UDP bị hủy đồng thời với việc đóng phiên điều khiển TCP trong đó lệnh UDP ASSOCIATE được gửi.

Nhiều máy chủ SOCKS hiện tại gặp phải sự cố nghiêm trọng nếu tường lửa NAT (Dịch địa chỉ mạng) được đặt giữa chúng và máy khách yêu cầu liên kết UDP. Lý do cho điều này nằm ở sự thay đổi địa chỉ nguồn và cổng xảy ra vào thời điểm gói dữ liệu UDP vượt qua tường lửa. Kết quả là, máy chủ và ứng dụng khách không nghi ngờ bắt đầu nói các ngôn ngữ khác nhau: địa chỉ nguồn và cổng dự định được chỉ định trong lệnh “UDP ASSOCIATE” không còn tương ứng với các tham số thực của gói dữ liệu mà máy chủ SOCKS nhận được. Kết quả là chúng bị loại bỏ do không thuộc về liên kết UDP. Vấn đề có thể được giải quyết bằng cách chỉ định 0.0.0.0:0 làm nguồn dự định (xem ở trên), điều này sẽ được máy chủ SOCKS hiểu là “bất kỳ gói dữ liệu UDP nào đến từ cùng một địa chỉ với lệnh tạo liên kết”. Thật không may, hầu hết các máy chủ SOCKS thực tế diễn giải tiêu chuẩn này hẹp hơn và không cho phép bạn đặt đồng thời cả địa chỉ dự định và cổng người gửi về 0. Trong số các cách triển khai được tác giả thử nghiệm, “thủ thuật chuyển tiếp UDP qua NAT” được mô tả ở đây chỉ cho phép thực hiện một cách - Dante.

Nhận kết nối đến

Tính năng khá nguyên bản này có thể hữu ích trong trường hợp máy khách và máy chủ “thực” trong sơ đồ được mô tả ở trên bị hoán đổi, điều này có thể xảy ra, chẳng hạn như trong các giao thức như FTP. Với mục đích thảo luận sâu hơn, chúng ta sẽ giả định rằng giữa “khách hàng” (bên có ý định chấp nhận kết nối đến) và “máy chủ” (bên khởi tạo kết nối đến) đã thiết lập kênh liên lạc “trực tiếp” bằng lệnh “CONNECT”. Để mở kênh "đảo ngược", "máy khách" phải gửi lệnh "BIND" đến máy chủ SOCKS, chỉ định trong tham số của nó địa chỉ IP và cổng mà nó sẽ sử dụng để nhận kết nối đến. Đáp lại, máy chủ SOCKS báo cáo địa chỉ IP và cổng được phân bổ cho nó để duy trì kênh “đảo ngược”. "Máy khách" dự kiến ​​sẽ chuyển các tham số này đến "máy chủ" bằng cách sử dụng các phương tiện được cung cấp bởi các giao thức lớp ứng dụng (ví dụ: lệnh FTP "PORT"). Sau khi máy chủ SOCKS chấp nhận (hoặc từ chối) kết nối đến, nó sẽ thông báo lại cho “máy khách”, cho nó biết địa chỉ IP và cổng được “máy chủ” sử dụng. Lưu ý rằng các kết nối đến chỉ có thể được chấp nhận bởi ứng dụng mà nhà phát triển đã đảm nhận việc hỗ trợ SOCKS ở giai đoạn thiết kế. Mặt khác (nếu ứng dụng hoạt động với máy chủ SOCKS thông qua chương trình ổ cắm), nó sẽ không thể cung cấp thông tin chính xác về địa chỉ của ổ cắm đang chờ “phản hồi” (tức là nó sẽ tạo ra lệnh “PORT” không chính xác trong ví dụ FTP đã thảo luận ở trên).

TẤT "Dây Xích"

Nào, đi làm thôi. Sáu bộ định tuyến được thuê “tại một thời điểm” để tín hiệu chạy qua đó. Và tất cả đều có khả năng chống hack khá tốt.

Sergey Lukyanenko “Mê cung của sự phản ánh”

Kiến trúc của giao thức SOCKS5 giúp dễ dàng kết hợp các máy chủ SOCKS thành các tầng hoặc vì chúng còn được gọi là “chuỗi”. Đáng chú ý là tất cả các hành động cần thiết cho việc này có thể được thực hiện ở phía khách hàng. Yêu cầu duy nhất đối với các “liên kết” của chuỗi là chúng phải “tin tưởng” lẫn nhau (tức là cho phép thiết lập các kết nối đến và đi). Nếu các máy chủ SOCKS hình thành tầng không ẩn danh (nghĩa là chúng sử dụng Tên người dùng/Mật khẩu, CHAP hoặc các sơ đồ xác thực tương tự), thì người dùng cũng cần phải hoàn tất thành công quy trình ủy quyền trên từng máy chủ đó.

Giả sử chúng ta có một bộ máy chủ N SOCKS có tên là socks1, socks2, ..., socksN, đáp ứng tất cả các yêu cầu trên. Sau đó, để tạo một tầng, khách hàng có thể thực hiện các thao tác sau:

    Khi kết nối TCP đi: khách hàng kết nối với vớ1, thực hiện quy trình ủy quyền (nếu cần) và gửi lệnh “CONNECT”, chỉ định vớ2 làm địa chỉ giao hàng. Bằng cách thực hiện yêu cầu này, bít tất1 sẽ tạo một kết nối mới với bít tất2 và sẽ thường xuyên chuyển tất cả thông tin đi qua nó tới khách hàng, trong khi bít tất2 thậm chí sẽ không đoán được nó thực sự đang giao tiếp với ai. Sau đó, quy trình này được lặp lại cho đến khi thiết lập được kết nối giữa bít tất (N-1) và bít tấtN. Máy chủ cuối cùng trong tầng kết nối trực tiếp với nút mà khách hàng quan tâm. Quá trình truyền dữ liệu diễn ra như bình thường: máy khách gửi một gói đến máy chủ bít tất1, máy chủ này sẽ truyền gói tin đó đến bít tất2, ..., v.v. cho đến khi đến được nút cuối.

    Khi kết nối UDP đi: máy khách kết nối với vớ1, thực hiện quy trình ủy quyền và gửi tuần tự hai lệnh: “CONNECT” (địa chỉ giao hàng - vớ2) và “UDP ASSOCIATE”. Do đó, hai kết nối mới được tạo: kênh UDP ảo giữa máy khách và vớ1 và phiên TCP giữa vớ1 và vớ2. Sử dụng phiên TCP này, máy khách (thay mặt cho vớ1) gửi lệnh “UDP ASSOCIATE” đến máy chủ vớ2 (mở kênh UDP giữa vớ1 và vớ2) và “CONNECT” đến máy chủ vớ3. Quy trình tiếp tục cho đến khi các kênh UDP ảo được thiết lập giữa tất cả các máy chủ SOCKS trong tầng. Để gửi bất kỳ dữ liệu nào, trước tiên, máy khách thực hiện đóng gói N lần gói dữ liệu UDP, chỉ định tuần tự vớ1, bít tất2, bít tất3, bít tấtN và địa chỉ của người nhận thực sự làm địa chỉ gửi, sau đó gửi nó đến máy chủ bít tất1. Lưu ý rằng trong thực tế, tùy chọn xếp tầng này cực kỳ hiếm. Điều này là do các máy chủ SOCKS, như Tường lửa NAT, có thể thay đổi cổng nguồn của gói dữ liệu, điều này sẽ dẫn đến các sự cố được mô tả chi tiết trong phần “Thiết lập kết nối UDP đi”.

Sử dụng chuỗi máy chủ SOCKS không yêu cầu xác thực, máy khách có thể tăng đáng kể tính ẩn danh khi làm việc trên Internet (xem phần ngoại truyện). Bạn có thể tìm thấy nhiều chương trình trên Internet thực hiện các chương trình được mô tả ở đây. Ví dụ: đây là SocksChain (http://www.ufasoft.com/socks/ ) cho Windows hoặc ProxyChains ( ) cho Unix. Máy chủ SOCKS xếp tầng cũng là một phần không thể thiếu của một số bộ soxifier, đáng chú ý nhất là FreeCap (http://www.freecap.ru/ ).

máy chủ SOCKS

Bây giờ chúng ta đã quen với các nguyên tắc hoạt động của máy chủ SOCKS, đã đến lúc chuyển từ lý thuyết sang thực hành. Có một số lượng lớn các chương trình trên thế giới triển khai giao thức SOCKS5. Chúng bao gồm tất cả các hệ điều hành phổ biến (Unix, Windows, ...) và các phương thức phân phối (phần mềm miễn phí, phần mềm chia sẻ, nguồn mở, v.v.). Ở đây chúng ta sẽ xem xét ngắn gọn những cách triển khai nổi tiếng nhất (hoặc thú vị theo quan điểm của tác giả).

Hãy bắt đầu với Triển khai tham chiếu SOCKS5 (http://www.socks.permeo.com/), do NEC thực hiện và thuộc sở hữu của Hiện nay Công ty Permeo. Phiên bản hiện tại được đánh số 1.0r11 và được phát hành vào tháng 8 năm 2000. Như bạn có thể dễ dàng đoán từ cái tên, máy chủ này là một triển khai tham chiếu của giao thức và nói chung, nó không nhằm mục đích sử dụng trong công nghiệp. Tuy nhiên, vì những lý do mà tôi không rõ lắm, nó đã được đưa vào các cổng FreeBSD và do đó là một tiêu chuẩn thực tế trên nền tảng này. Sản phẩm có hỗ trợ GSSAPI và được phân phối dưới dạng mã nguồn nhưng theo giấy phép độc quyền. Việc sử dụng thương mại của máy chủ này bị cấm.

Dante, được phát triển bởi công ty Na Uy Inferno Nettverk, đặc biệt phổ biến với những người ủng hộ Linux. Sản phẩm đang phát triển, mặc dù không nhanh lắm (phiên bản mới nhất, 1.1.15, ra mắt ngày 31 tháng 1 năm 2005) và khá phù hợp để sử dụng thực tế. Như đã đề cập trước đó, Dante cho phép các liên kết UDP hoạt động chính xác ngay cả khi chúng đi qua Tường lửa NAT. Chương trình được phân phối dưới dạng mã nguồn theo giấy phép BSD. Dante bao gồm một thư viện để đồng hóa minh bạch các ứng dụng Unix (xem bên dưới)

Valentin Sinitsyn (val AT linuxcenter DOT ru) - Máy chủ proxy đa năng

Cách đây một thời gian, tôi muốn thử triển khai một máy chủ proxy cho nhu cầu của riêng mình và một máy chủ có thể được sử dụng trong tương lai, đồng thời kích thước của nó sẽ ở mức tối thiểu. Tùy chọn tự nhiên đối với tôi là triển khai bằng trình biên dịch chương trình. Chương trình này nhỏ gọn, tiện lợi và sau này tôi rất thường xuyên sử dụng nó. Nhưng bây giờ, sau nhiều năm, tôi muốn cho thấy thực hiện đơn giản nhất một giao thức, SOCKS4. Giao thức này được tạo để các máy khách nằm trên mạng cục bộ phía sau tường lửa có thể truy cập mạng bên ngoài. Đồng thời, trong trường hợp này, có thể kiểm soát các yêu cầu của khách hàng :) Điều đầu tiên bạn cần làm khi triển khai là đọc tài liệu mô tả giao thức này, vì chúng tôi muốn các chương trình tiêu chuẩn hiểu giao thức của mình mà không cần “phá hoại bằng một tập tin.” Vì vậy, tài liệu:

Bây giờ, đã có mô tả, hãy bắt đầu. Công việc của máy chủ proxy là chấp nhận yêu cầu từ máy khách ở một định dạng nhất định, tạo một ổ cắm và kết nối nó với địa chỉ mà máy khách yêu cầu, sau đó đảm bảo trao đổi dữ liệu giữa hai ổ cắm cho đến khi chúng được máy chủ đóng lại. hoặc khách hàng. Hãy bắt đầu thực hiện.

Macro và cấu trúc dữ liệu sử dụng trong chương trình

Hãy tạo một tệp bao gồm, bao gồm.inc. Trong tệp này, chúng tôi sẽ đặt các macro + cấu trúc tiêu chuẩn để làm việc với SOCKS4 khi viết chương trình Windows. Ở đây tôi sẽ không cung cấp tất cả các macro, tôi sẽ chỉ cung cấp mô tả và chức năng cần thiết để giải quyết vấn đề chính, mọi thứ khác bạn sẽ tìm thấy trong tệp đính kèm với mã nguồn.
; SOCKS4 – Cấu trúc được máy khách sử dụng khi yêu cầu kết nối; tới máy chủ (DSTIP)/cổng (DSTPORT) được chỉ định CONNECT_SOCK4 Struc VN Db ? CD Db? DSTPORT Dw? DSTIP Dd? Db vô giá trị? CONNECT_SOCK4 Kết thúc ; SOCKS4 - phản hồi của máy chủ proxy về kết nối. RESPONSE_SOCK4 Cấu trúc VN Db ? CD Db? DSTPORT Dw? DSTIP Dd? RESPONSE_SOCK4 Kết thúc

Qua nhìn chung, cấu trúc CONNECT_SOCK4 và RESPONSE_SOCK4 không khác nhau vì chúng tôi triển khai giao thức mà không được phép. Nhưng tôi quyết định để chúng riêng biệt để sau này có thể dễ dàng thay đổi để cải thiện. Trong bản thân các cấu trúc, trong biến VN, phiên bản giao thức được chỉ định; trong trường hợp của chúng tôi, phải luôn có 4; trong trường hợp SOCKS5, biến này chứa 5 (giao thức về cơ bản tương tự). Biến CD được sử dụng để trả về máy khách kết quả của yêu cầu máy chủ proxy đến địa chỉ mà máy khách yêu cầu (90 - kết nối thành công / 91 - kết nối không thành công).
Chúng tôi thực sự có ba giai đoạn trong chương trình.
* Đầu tiên, chúng ta khởi tạo socket, lắng nghe các yêu cầu của máy khách trong socket và tạo một luồng xử lý.
* Giai đoạn thứ hai là phân tích yêu cầu của khách hàng, nỗ lực tạo và kết nối ổ cắm với máy chủ do khách hàng yêu cầu.
* Và giai đoạn cuối cùng, thứ ba là gửi dữ liệu giữa socket máy khách và socket do chúng tôi tạo và kết nối đến địa chỉ được yêu cầu.

Triển khai giai đoạn 1, khởi tạo chương trình:

; Quy trình chính là quy trình bắt đầu cho chương trình WinMain Proc LOCAL ThreadId, hServSock:DWORD LOCAL tên máy chủ :BYTE LOCAL _wsa:WSADATA LOCAL _our:sockaddr_in ; Khi khởi chạy thư viện để làm việc với socket, chúng tôi sử dụng chức năng của phiên bản 1.1, ; hãy yêu cầu nó như một lệnh gọi tối thiểu WSAStartup, 0101h, ADDR _wsa .if eax == 0 ; Chúng tôi lấy địa chỉ của mình, chuẩn bị cấu trúc để khởi tạo ổ cắm máy chủ gọi gethostname, ADDR Hostname, 256 gọi gethostbyname, ADDR Hostname .if eax == 0 gọi inet_addr, ADDR Hostname .else mov eax, mov eax, mov eax, .endif mov _our. sin_addr, eax gọi inet_ntoa, eax mov _our.sin_family, AF_INET mov _our.sin_addr.S_un.S_addr, INADDR_ANY xor eax, eax ; Nhập cổng mà chúng tôi muốn nghe tin nhắn đến mov ax, SOCKS_PORT gọi htons, eax mov _our.sin_port, ax gọi socket, AF_INET, SOCK_STREAM, 0 .if eax != INVALID_SOCKET ; Lưu ổ cắm máy chủ đã tạo mov hServSock, eax ; Chúng tôi liên kết ổ cắm máy chủ với địa chỉ của chúng tôi và liên kết gọi cổng được yêu cầu, hServSock, ADDR _our, SIZEOF sockaddr_in .if eax != SOCKET_ERROR @@: ; Khởi tạo socket để chờ gọi listen, hServSock, SOMAXCONN .repeat ; Một máy khách đã đến, chúng tôi nhận được một ổ cắm với lệnh gọi máy khách đến chấp nhận, hServSock, NULL, NULL .until eax != INVALID_SOCKET ; Tạo một luồng trong đó máy khách hiện tại sẽ được xử lý xchg eax, ebx gọi CreateThread, NULL, NULL, ADDR socketThread, ebx, NULL, ADDR ThreadId ; Chúng tôi rời đi để đợi khách hàng jmp @B .endif .endif gọi closesocket, hServSock .endif gọi ExitProcess, 0 WinMain Endp
Đây là quy trình đầu tiên của chúng tôi, tôi đã cố gắng nhận xét về mã nhiều nhất có thể để bạn có thể tìm ra, nhưng nếu vẫn còn điều gì đó chưa rõ ràng, vui lòng liên hệ với tôi hoặc MSDN. Về cơ bản tất cả mã được viết bằng cú pháp MASM và WinAPI. Kết quả của hàm trên phải là một ổ cắm hoạt động trên một trong các địa chỉ mạng máy của bạn (địa chỉ cục bộ hoặc địa chỉ bên ngoài nếu bạn có IP thực) + dựa trên kết nối máy khách, hàm sẽ tạo một luồng riêng được sử dụng để làm việc với máy khách đến. Bây giờ chúng ta hãy tiếp tục...

Giai đoạn thứ hai, phân tích yêu cầu của khách hàng

Ở bước thứ hai, tất cả những gì cần làm là chấp nhận cấu trúc CONNECT_SOCK4, tạo ổ cắm, cố gắng kết nối nó và gửi phản hồi cho máy khách. Thực hiện:

SocketThread Proc sock:DWORD LOCAL lpMem, _csock, ThreadId, dAmount:DWORD LOCAL Remote:sockaddr_in LOCAL wrFds, rdFds:fd_set LOCAL hResp:RESPONSE_SOCK4 ; Sẵn sàng đọc dữ liệu từ socket gọi FdZero, ADDR rdFds gọi FdSet, sock, ADDR rdFds gọi select, NULL, ADDR rdFds, NULL, NULL, NULL ; Chúng tôi nhận được kích thước của dữ liệu đang chờ đọc gọi ioctlsocket, sock, FIONREAD, ADDR dAmount ; Chúng tôi dự trữ bộ nhớ cho dữ liệu mov lpMem, @Result(LocalAlloc, LMEM_FIXED or LMEM_ZEROINIT, dAmount) ; Đọc dữ liệu yêu cầu từ ổ cắm gọi recv, sock, lpMem, dAmount, 0; Yêu cầu được gửi đến lea edi, hResp mov esi, lpMem ; Esi chứa yêu cầu của người dùng. Chúng tôi chỉ xử lý (ở đây) phiên bản SOCKS4, ; Về nguyên tắc, SOCKS5 có thể được xử lý tại đây, nhưng việc đó sẽ được thực hiện sau... Giả sử Esi: Ptr CONNECT_SOCK4 Giả sử Edi: Ptr RESPONSE_SOCK4 .if .VN == 4 ; Triển khai giao thức SOX 4 .if .CD == 1 gọi ổ cắm, AF_INET, SOCK_STREAM, 0 .if eax != INVALID_SOCKET mov _csock, eax ; Chúng tôi lấy dữ liệu của máy chủ từ xa mà khách hàng muốn kết nối mov Remote.sin_family, AF_INET mov ax, .DSTPORT mov Remote.sin_port, ax mov eax, .DSTIP mov Remote.sin_addr, eax mov cx, .DSTPORT mov edx , .DSTIP ; Edi chứa câu trả lời cho người dùng mov .VN, 0 mov .DSTPORT, cx mov .DSTIP, edx ; Chúng tôi đang cố gắng kết nối với máy chủ từ xa gọi kết nối, _csock, ADDR Remote, SIZEOF Remote .if !eax ; Chúng tôi đang chuẩn bị phản hồi rằng chúng tôi đã kết nối mov .CD, 90 ; Chúng tôi gửi cho khách hàng một phản hồi chứa kết quả của lần thử kết nối gọi send, sock, ADDR hResp, SIZEOF RESPONSE_SOCK4, 0 ; Chúng tôi tạo thành một cấu trúc với thông tin về máy chủ và; ổ cắm máy khách được kết nối; - theo máy chủ ở đây ý tôi là ổ cắm được kết nối với máy khách; ai đã gửi yêu cầu; - theo máy khách, ý tôi là một ổ cắm được kết nối với máy chủ; có dữ liệu được khách hàng yêu cầu mov ebx, @Result(LocalAlloc, LMEM_FIXED hoặc LMEM_ZEROINIT, SIZEOF THREAD_DATA) Giả sử Ebx: Ptr THREAD_DATA mov eax, _csock mov .Server, eax mov eax, sock mov .Client, eax Giả sử Ebx: Nothing ; Chúng tôi bắt đầu luồng xử lý ổ cắm (đọc từ máy khách và truyền đến ổ cắm máy chủ) gọi CreateThread, NULL, NULL, ADDR ClientSock, ebx, NULL, ADDR ThreadId .else ; Nếu kết nối không thành công, hãy đóng ổ cắm máy khách, gọi closesocket, _csock ; Chúng tôi nói rằng đã xảy ra lỗi kết nối mov , 91 ; Chúng tôi gửi cho khách hàng một phản hồi chứa kết quả của lần thử kết nối gọi send, sock, ADDR hResp, SIZEOF RESPONSE_SOCK4, 0 .endif .endif .endif .endif Giả sử Edi: Không có gì Giả sử Esi: Không có gì ; Giải phóng bộ nhớ được phân bổ cho yêu cầu gọi LocalFree, lpMem ret socketThread Endp
Kết quả của quy trình này là một ổ cắm được kết nối cũng như một luồng được tạo để thực hiện trao đổi dữ liệu giữa hai ổ cắm. Nó đơn giản. Người ta chỉ cần làm rõ rằng một số điểm địa chỉ được sử dụng ở đây trong các cấu trúc đã được đưa vào MASM để giúp công việc của lập trình viên trở nên dễ dàng hơn. Điểm đầu tiên, macro “Giả sử”.
Dòng Giả sử Esi: Ptr CONNECT_SOCK4 cho trình biên dịch biết rằng thanh ghi này (Esi) chứa địa chỉ của cấu trúc CONNECT_SOCK4, giúp đơn giản hóa hơn nữa việc truy cập các biến trong cấu trúc này. Giả sử Esi:Không có gì hủy bỏ ràng buộc. Để hiểu rõ hơn, có thể dễ dàng hơn nếu tôi liệt kê một số tùy chọn địa chỉ:
Giả sử Esi:Ptr CONNECT_SOCK4 mov al, .VN ; Chúng ta đặt vào AL giá trị byte từ cấu trúc biến VN mov al, .CD ; Đặt biến CD mov ax vào AL. .DSTPORT ; Đặt biến DSTPORT trong AX Giả sử Esi:Không có gì
hoặc
di chuyển, ; Đặt giá trị byte từ biến VN vào AL mov al, ; Đặt biến CD mov ax, ; Đặt biến DSTPORT trong AX
hoặc
mov al, byte ptr ; Đặt biến VN vào AL mov al, byte ptr ; Đặt biến CD vào AL mov ax, word ptr ; Đặt biến DSTPORT trong AX

Tôi nghĩ điều hiển nhiên đối với bạn, cũng như đối với tôi, là sử dụng tùy chọn đầu tiên sẽ nhanh hơn, thuận tiện hơn và rõ ràng hơn. Mặc dù nếu cần phải đề cập đến một biến của cấu trúc, thì tùy chọn thứ hai vẫn có quyền tồn tại. Tôi nghĩ tốt hơn nên sử dụng tùy chọn thứ ba trong trường hợp dữ liệu tại địa chỉ không có cấu trúc. Nhưng như bạn đã biết, mỗi con sói Tambov đều có hương vị và màu sắc riêng. Sử dụng phương pháp thuận tiện nhất cho bạn.
Một điểm nữa cần được làm rõ. Macro kết quả. Macro này được viết để bạn có thể gọi hàm WinAPI trên một dòng và ghi kết quả thực thi vào thanh ghi hoặc bộ nhớ. Vì vậy, dòng:
mov lpMem, @Result(LocalAlloc, LMEM_FIXED hoặc LMEM_ZEROINIT, dAmount)
Đầu tiên thực hiện cuộc gọi như thế này:
gọi LocalAlloc, LMEM_FIXED hoặc LMEM_ZEROINIT, dAmount
và sau khi thực hiện lệnh gọi này, kết quả thực hiện (Eax) được lưu trong biến lpMem. Trong trường hợp cụ thể này, bộ nhớ sẽ được phân bổ và địa chỉ nơi đặt khu vực được phân bổ cho chúng ta sẽ được ghi vào biến.

Giai đoạn ba, truyền dữ liệu

Vậy là hai công đoạn khó khăn nhất đã hoàn thành. Khách hàng đến, chúng tôi kết nối anh ta với máy chủ từ xa và đã đến lúc thực hiện công việc “khỉ” đơn giản nhất. Truyền dữ liệu giữa hai socket. Hãy làm điều đó một cách nhanh chóng và dễ dàng:
; Một luồng đọc từ ổ cắm máy khách và gửi nó đến ổ cắm máy chủ.... ClientSock Proc Param:DWORD LOCAL sserver, sclient:DWORD LOCAL rdFds:fd_set LOCAL dAmount, lpBuf: DWORD ; Trong Param, chúng tôi có thông tin về ổ cắm máy chủ và máy khách; chuyển sang các biến cục bộ mov ebx, Param Giả sử Ebx: Ptr THREAD_DATA mov eax, .Server mov sserver, eax mov eax, .Client mov sclient, eax Giả sử Ebx: Nothing ; Đừng quên giải phóng bộ nhớ gọi LocalFree, Param @@: gọi FdZero, ADDR rdFds gọi FdSet, sserver, ADDR rdFds gọi FdSet, sclient, ADDR rdFds gọi select, NULL, ADDR rdFds, NULL, NULL, NULL ; Kiểm tra xem có dữ liệu cần đọc hay không.if eax == SOCKET_ERROR || eax == 0 ; Không có dữ liệu - thoát jmp @F .endif; Có dữ liệu từ máy chủ cần được chuyển đến máy khách không? gọi FdIsSet, sserver, ADDR rdFds .if eax; Chúng tôi nhận được kích thước của dữ liệu đang chờ đọc gọi ioctlsocket, sserver, FIONREAD, ADDR dAmount ; Dự trữ bộ nhớ cho dữ liệu mov lpBuf, @Result(LocalAlloc, LMEM_FIXED hoặc LMEM_ZEROINIT, dAmount) gọi recv, sserver, lpBuf, dAmount, 0 .if eax == SOCKET_ERROR || eax == 0 jmp @F .endif gọi gửi, sclient, lpBuf, eax, 0 gọi LocalFree, lpBuf .endif ; Có dữ liệu từ máy khách để gửi đến ổ cắm máy chủ không? gọi FdIsSet, sclient, ADDR rdFds .if eax; Chúng tôi nhận được kích thước của dữ liệu đang chờ đọc gọi ioctlsocket, sclient, FIONREAD, ADDR dAmount ; Dự trữ bộ nhớ cho dữ liệu mov lpBuf, @Result(LocalAlloc, LMEM_FIXED hoặc LMEM_ZEROINIT, dAmount) gọi recv, sclient, lpBuf, dAmount, 0 .if eax == SOCKET_ERROR || eax == 0 jmp @F .endif gọi gửi, sserver, lpBuf, eax, 0 gọi LocalFree, lpBuf .endif; Chúng ta hãy đi đến chu kỳ mới jmp @B @@: ; Đóng ổ cắm gọi closesocket, sserver gọi closesocket, sclient ; Thoát khỏi chuỗi lệnh gọi ExitThread, 0 ClientSock Endp
Ban đầu, quy trình này khởi tạo các biến nội bộ từ cấu trúc được truyền vào luồng để làm cho chúng thuận tiện hơn khi sử dụng. Sau đó, trong vòng lặp, một kiểm tra được thực hiện để xem có dữ liệu để đọc từ socket hay không, sau đó là hai đoạn mã (thực ra là sao chép-dán, ở đây tôi không bận tâm đến việc loại bỏ chức năng và tối ưu hóa nó vì nó rõ ràng hơn ) đọc từ một ổ cắm và gửi nó đến ổ cắm thứ hai.
Thế đấy, nhanh lên! Hãy biên dịch và thử. Về nguyên tắc nhất một lựa chọn tốt– FireFox. Trong cài đặt kết nối, chúng tôi chỉ định rằng bạn cần sử dụng máy chủ proxy SOCKS4. Chúng tôi cho biết địa chỉ của nó và cổng nơi nó được đặt. Sau đó, chúng tôi lưu cài đặt và tận hưởng Internet, được chuyển qua proxy của chúng tôi, kích thước 3,5 kbyte))) Có, tôi sẽ làm rõ. Để biên dịch cần phải cài đặt gói

Máy chủ proxy như vậy kiểm soát quyền truy cập tài nguyên bên ngoài của khách hàng và truyền yêu cầu đến máy chủ. SOCKS cũng có thể được sử dụng theo cách ngược lại, cho phép máy khách bên ngoài kết nối với máy chủ phía sau tường lửa.

Không giống như máy chủ proxy HTTP, SOCKS truyền tất cả dữ liệu từ máy khách mà không cần thêm bất kỳ dữ liệu nào từ chính nó, nghĩa là, theo quan điểm của máy chủ cuối, proxy SOCKS là một máy khách thông thường. SOCKS phổ biến hơn - nó không phụ thuộc vào các giao thức lớp ứng dụng cụ thể (lớp 7 của mô hình OSI) và dựa trên tiêu chuẩn TCP/IP - giao thức lớp 4. Tuy nhiên, proxy HTTP lưu trữ dữ liệu vào bộ nhớ đệm và có thể lọc nội dung của dữ liệu được truyền đi một cách cẩn thận hơn.

Giao thức này được phát triển bởi David Koblas, quản trị viên hệ thống của Hệ thống máy tính MIPS. Sau khi MIPS trở thành một phần của Silicon Graphics (SGI) vào năm đó, Koblas đã có bài nói chuyện về SOCKS tại Hội nghị chuyên đề bảo mật Usenix và SOCKS đã được công bố rộng rãi. Giao thức đã được mở rộng lên phiên bản 4 bởi Ying-Da Lee của Phòng thí nghiệm Hệ thống NEC.

Giao thức SOCKS 4

SOCKS 4 được thiết kế để hoạt động thông qua tường lửa mà không cần xác thực đối với các ứng dụng máy khách-máy chủ chạy trên TCP, chẳng hạn như TELNET, FTP và các giao thức truyền thông phổ biến như HTTP, WAIS và GOPHER. Về cơ bản, máy chủ SOCKS có thể được coi là tường lửa hỗ trợ giao thức SOCKS.

Một yêu cầu SOCKS 4 điển hình trông như thế này (mỗi trường là một byte):

Yêu cầu của khách hàng tới Máy chủ SOCKS:

  • trường 1: Số phiên bản SOCKS, 1 byte (phải là 0x04 cho phiên bản này)
  • trường 2: mã lệnh, 1 byte:
    • 0x02 = Gán cổng TCP/IP (ràng buộc)
  • trường 3: số cổng, 2 byte
  • trường 4: Địa chỉ IP, 4 byte
  • trường 5: ID người dùng, chuỗi có độ dài thay đổi, được kết thúc bằng byte rỗng (0x00). Trường này nhằm mục đích xác định người dùng (xem Nhận dạng)

Phản hồi của máy chủ đối với Máy khách SOCKS:

  • trường 1: byte rỗng
  • trường 2: mã phản hồi, 1 byte:
    • 0x5a = yêu cầu được chấp nhận
    • 0x5b = yêu cầu bị từ chối hoặc không hợp lệ
    • 0x5c = Yêu cầu không thành công do identd không chạy (hoặc không thể truy cập được từ máy chủ)
    • 0x5d = Yêu cầu không thành công do nhận dạng khách hàng không thể xác thực ID người dùng trong yêu cầu
  • trường 3: 2 byte tùy ý, nên bỏ qua
  • trường 4: 4 byte tùy ý, nên bỏ qua

Giao thức SOCKS 5

SOCKS 5 mở rộng mô hình SOCKS 4 bằng cách thêm hỗ trợ UDP, cung cấp kế hoạch phổ quát xác thực mạnh mẽ và mở rộng các phương pháp đánh địa chỉ bằng cách thêm hỗ trợ cho tên miền và địa chỉ IPv6. Cài đặt ban đầu Kết nối bây giờ bao gồm những điều sau đây:

  • Máy khách kết nối và gửi lời chào bao gồm danh sách các phương thức xác thực được hỗ trợ
  • Máy chủ chọn một trong số chúng (hoặc gửi phản hồi lỗi yêu cầu nếu không có phương pháp đề xuất nào được chấp nhận)
  • Tùy thuộc vào phương thức đã chọn, một số tin nhắn có thể được chuyển giữa máy khách và máy chủ
  • Client gửi yêu cầu kết nối, tương tự SOCKS 4
  • Máy chủ phản hồi, tương tự như SOCKS 4

Các phương thức xác thực được đánh số như sau:

  • 0x00 - không cần xác thực
  • 0x01 - GSSAPI
  • 0x02 - tên người dùng/mật khẩu
  • 0x03-0x7F - được IANA đặt trước
  • 0x80-0xFE - dành riêng cho các phương thức sử dụng riêng tư

Lời chào đầu tiên từ khách hàng:

  • trường 2: số phương thức xác thực được hỗ trợ, 1 byte
  • trường 3: số phương thức xác thực, độ dài thay đổi, 1 byte cho mỗi phương thức được hỗ trợ

Máy chủ báo cáo lựa chọn của mình:

  • trường 1: Phiên bản SOCKS, 1 byte (0x05 cho phiên bản này)
  • trường 2: phương thức xác thực đã chọn, 1 byte hoặc 0xFF nếu không đề xuất phương thức nào được chấp nhận

Việc nhận dạng tiếp theo phụ thuộc vào phương pháp đã chọn.

Yêu cầu khách hàng:

  • trường 1: Số phiên bản SOCKS (phải là 0x05 cho phiên bản này)
  • trường 2: mã lệnh, 1 byte:
    • 0x01 = thiết lập kết nối TCP/IP
    • 0x02 = Gán cổng TCP/IP (ràng buộc)
    • 0x03 = Liên kết cổng UDP
  • trường 3: byte dành riêng, phải là 0x00
  • trường 4: loại địa chỉ, 1 byte:
    • 0x01 = địa chỉ IPv4
    • 0x03 = tên miền
    • 0x04 = địa chỉ IPv6
  • trường 5: gán địa chỉ
    • 4 byte cho địa chỉ IPv4
    • 16 byte cho địa chỉ IPv6
  • trường 6: số cổng, 2 byte

Phản hồi của máy chủ:

  • trường 1: Số phiên bản SOCKS, 1 byte (0x05 cho phiên bản này)
  • trường 2: mã phản hồi, 1 byte:
    • 0x00 = yêu cầu được chấp nhận
    • 0x01 = Lỗi máy chủ SOCKS
    • 0x02 = kết nối bị cấm theo quy tắc
    • 0x03 = mạng không khả dụng
    • 0x04 = không thể truy cập máy chủ
    • 0x05 = kết nối bị từ chối
    • 0x06 = TTL đã hết hạn
    • 0x07 = Lệnh không được hỗ trợ / lỗi giao thức
    • 0x08 = loại địa chỉ không được hỗ trợ
  • trường 3: byte dành riêng, phải là 0x00
  • trường 4: loại địa chỉ tiếp theo, 1 byte:
    • 0x01 = địa chỉ IPv4
    • 0x03 = tên miền
    • 0x04 = địa chỉ IPv6
  • trường 5: gán địa chỉ
    • 4 byte cho địa chỉ IPv4
    • byte đầu tiên là độ dài của tên, theo sau là tên miền không có giá trị rỗng ở cuối
    • 16 byte cho địa chỉ IPv6
  • trường 6: số cổng, 2 byte

Triển khai

  • Sun Java System Web Proxy Server - máy chủ proxy lưu trữ bộ đệm cho Solaris, Linux, Windows. Hỗ trợ các bộ lọc I/O HTTPS, NSAPI, cấu hình lại động và proxy ngược.
  • DeleGate là một cổng cấp ứng dụng đa chức năng và máy chủ proxy chạy trên nhiều nền tảng khác nhau. Ngoài SOCKS, nó còn hỗ trợ HTTP(S), FTP, NNTP, SMTP, POP, IMAP, LDAP, Telnet, DNS và các giao thức khác.
  • 3proxy - máy chủ proxy nhẹ có hỗ trợ SOCKS-proxy
  • WinGate là máy chủ proxy đa giao thức có hỗ trợ SOCKS cho Windows.
  • OpenSSH cho phép bạn tự động tạo các đường hầm được xác định thông qua một tập hợp con của giao thức SOCKS.

Xem thêm

  • Tor là mạng định tuyến củ hành ẩn danh với giao diện SOCKS.

Liên kết

  • RFC 1928 - Giao thức SOCKS Phiên bản 5
  • RFC 1928 (tiếng Nga) - Giao thức SOCKS 5
  • RFC 1929 - Xác thực tên người dùng/mật khẩu cho SOCKS V5
  • RFC 1961 (tiếng Anh) - Phương pháp xác thực GSS-API cho SOCKS Phiên bản 5
  • SOCKS: Giao thức cho proxy TCP xuyên tường lửa - Giao thức SOCKS 4

Quỹ Wikimedia. 2010.

Xem "SOCKS" là gì trong các từ điển khác:

    TẤT- là một giao thức Internet cho phép các ứng dụng máy chủ khách sử dụng một cách minh bạch các dịch vụ của tường lửa mạng. SOCKS là viết tắt của SOCKetS [ ]… … Wikipedia

    TẤT- Bắt đầu điều hướng, hãy sử dụng SOCKS là một giao thức Internet cho phép một ứng dụng khách hàng sử dụng cách thức minh bạch các dịch vụ của tường lửa màu đỏ. SOCKS là một từ viết tắt của SOCKETS . Mất khách hàng que hay detrás… … Wikipedia Español

    Giao thức mạng cho phép máy khách ứng dụng máy chủ sử dụng minh bạch các dịch vụ đằng sau tường lửa. SOCKS là viết tắt của SOCKetS (ổ cắm). Khách hàng sử dụng tường lửa cần quyền truy cập vào... ... Wikipedia

    Tất- im Phòng giới thiệu des Weißen Hauses Betty Currie und Socks ... Wikipedia tiếng Đức

    Tất- sobre el pupitre de la Sala de Prensa de la Casa Blanca. Tất (tiếng Tây Ban Nha: Calcetines, Marzo de 1989 20 de febrero de 2009) fue el gato de la familia del Presidente de los Estados Unidos Bill Clinton trong thời gian làm tổng thống. Fue la única mascota... ... WikipediaTiếng Tây Ban Nha