Thay đổi gói tin ở proxy

#1

mình có 1 thắc mắc về network thế này

giả sử mình tạo 1 con server proxy , nằm giữa 2 server, server A, server B
tại server A, gửi 1 gói tin 2mb , đến server B thông qua proxy, nhưng tại proxy mình cố ý cắt gói tin 2mb kia ra thành
20 gói tin nhỏ hơn , rồi mới chuyển tiếp đến server B, thì theo bạn dữ liệu khi đến server B có còn nguyên vẹn , và đúng không , so với việc chuyển tiếp trực tiếp từ A sang B mà ko cắt nhỏ gói tin ra

mình băn khoăng vì, mình có đọc 1 bài về bypass sni , đợt gần đây , vn chặn web ■■■ bằng sni , nên mấy cao thủ chơi trò cắt gói tin sni ra để khi chạy qua bộ lọc của nhà mạng thì nó ko đọc ra domain bị chặn

#2

mục đích của việc cắt là gì?
cơ chế cắt và nối như thế nào?
những câu hỏi mang tính giả định như này thì sao mà có câu trả lời chuẩn được

1 Like
#3
  1. vì sao cắt : vì dùng udp , nên không thể gửi 1 gói tin lớn như tcp
  2. cơ chế cắt nối : ở client sử dụng buffer thế nào thì bên server cũng sử dụng buffer có độ lớn như vậy , ko có gì đặt biệt hết
  3. ko giả định , mình đang làm nhưng vì lâu lâu lại bị lost , hoặc gửi nhận gói tin sai nên không biết có phải lỗi do việc cắt ghép ko
  4. mình sài tcp để giao tiếp thì lại ko xảy ra việc trên
#4

tcp bản thân nó cũng cắt/nối, gửi từng package, chứ làm gì có chuyện gửi hẳn 1 cái gì đó 2mb 1 lần
bản thân udp là đã là 1 protocol không đảm bảo tính toàn vẹn rồi của thông tin rồi

#5

nó cắt ở tầng dưới thôi và tự động cắt , chuyện đó thì mình ko can thiệp vào , mình chỉ cắt ở tầng application

đúng rồi cái khó là ở chỗ thằng udp này nó ko toàn vẹn, nên quá trình check lại mình phải viết ở tầng application, chứ tcp nó làm dưới tầng mạng rồi

thực ra mình đang muốn thử làm 1 con server dạng như hamichi , tailscale , cho phép nhiều máy kết nối với nhau thành 1 mạng nội bộ, và ko chỉ dùng protocol tcp mà dùng đc cả udp

#6

Hamachi và Tailscale là VPN mà. Những VPN này cần VPN client ở Server A và Server B mới chạy được, khi có software client thì bạn có thể thoải mái cắt gói tin, xào nấu gì ở trung gian cũng được rồi thằng software này sẽ ghép lại thành gói tin ban đầu.
Việc này khác hoàn toàn với việc bạn chỉ có 1 proxy trung gian, nếu bạn tự tiện cắt gói tin tại proxy thì sao bên Server B nó nhận được nhỉ?
Proxy chỉ có chức năng filter hoặc ẩn danh thôi chứ nhỉ?

Về việc sử dụng UDP không toàn vẹn là đúng rồi. Có 2 trường hợp xảy ra:

  • Gói tin bị mất luôn -> Application bên nhận cần yêu cầu gửi lại
  • Các gói tin đến đích với thứ tự đảo lộn -> Phải đánh số thứ tự và sắp xếp lại.

Các việc này tất nhiên phải làm ở tầng application rồi.

2 Likes
#7

giờ để loại bỏ trường hợp mất gói tin thì mình sài mạng local , cho 2 máy local nối mạng lan với nhau test có đảm bảo loại bỏ việc mất gói tin udp trên đg truyền ko?

thứ tự đảo lộn, thì mình sẽ thêm các seq number, và ack vào mỗi gói, bắt chước tcp,

à cho mình hỏi có công cụ nào giúp mình theo dỏi và kiểm tra việc truyền nhận gói tin , từ client đến server, và moniter cho mình biết gói tin nào đúng sai, thừa thiếu gì không?

#8
  • UDP: Sender and receiver are responsible for the order/sequence of data packets. If server A and B are running with TCP, communication between them will not work if a proxy is running UDP between them.
  • Buffer: It is best if the client sends the buffer size to the server first, so that there is an equal buffer size
  • Loss: Normally, when a client starts to communicate with a server, this server starts a thread that associates with this client and communicates with the client until it quits. The server’s thread for every client should have an “endless loop” that only waits for an incoming client message and passes it to the part to process and then continues to wait for client messages. By the way, OS/TCP always queues the sending messages for reading. When the queue is full, the sender (client or server) blocks any further sending. In this case, you need to use the “timeout” option to prevent the possible loss.
#9

Bạn có thể cho biết proxy server hoạt động ở layer mấy? Và bạn cắt gói tin ở layer mấy không?

Nếu cái này mà bạn còn chưa biết hoặc dùng qua thì mình hơi quan ngại khả năng thực tế của “dự án” này…

#10

Không đảm bảo. Việc mất gói có thể đến từ dây cáp. Dây dỏm thì mất gói nhiều hơn.
Kể cả dây xịn thì xác suất mất vẫn có, do sai số clock, do quá nhiệt, do nhiễu điện trường, ví dụ như ai đó bật quạt hoặc máy bơm trong nhà hoặc nhà hàng xóm.

Bạn có nghĩ là vì sao phải làm cơ chế giống TCP ở application layer thay vì trực tiếp dùng TCP? Chi phí/hiệu suất giải quyết vấn đề này ở lớp Application so với lớp Transport thế nào?
Việc thêm UDP vào để giải quyết vấn đề gì, giúp ích gì?

:upside_down_face: :shark:

#11

proxy chỉ hoạt động ở tầng application thôi, ko đi sâu hơn

bình thường thì mình dùng wireshark , nhưng đó chỉ là xem gói tin, mình muốn kiểu thống kê , còn đây là dự án pet project của mình để học hỏi thôi bạn

#12

vì 1 số game hoặc chương trình mà mình muốn chạy trên proxy của mình nó chạy trên protocol udp nên phải làm cả udp

#13

:flushed: thế phải hỏi là các gói tin UDP có bị block hay không đã. nếu không thì làm gì cho phức tạp.

còn nếu bạn muốn split UDP ở application layer. thì bạn cũng nên hỏi là server đang nhận các packet UDP có hỗ trợ việc packet fragmentation không? vì UDP có khả năng mất gói tin. nếu bạn split ra thì làm sao 1 UDP server biết được rằng packet bị mất hay đang bị thiếu?

còn nếu bạn thọt lét ở layer sâu hơn (như layer 3, vì các packet sẽ bị split ở layer 4) thì sẽ ok. vì khi này UDP sẽ tự tiến hành gom các packet lại và gửi về cho application layer một cách tự động :ok_hand:

#14

bên game người ta làm, chủ động dùng udp có nghĩa là người ta chấp nhận gói tin khi đến với người ta là đã không trọn vẹn rồi
bạn là client game, dù bạn có đi thẳng tới cái server game đó, thì vẫn có xác xuất bị mất gói

mình chưa rõ là bạn đang viết code như nào, bạn có demo không
mà không biết bạn có nhầm lẫn khái niệm “gói” không, cái bạn cắt ra được, bạn gọi là “gói”, gói này đâu có phải là “gói” của tcp, đâu liên quan nhau

#15

Nếu proxy hoạt động ở tầng app thì việc cắt nhỏ gói tin ở tầng TCP/UDP liên quan gì đến proxy vậy bạn?

Bạn có biết SNI thì nó nằm ở đâu, và trong những gói tin nào không? Proxy bạn kết nối bằng giao thức gì? HTTP? HTTPS? Hay SOCKS? Bạn có thấy SNI trong các gói gửi cho proxy chưa mà cần phải tách?

Rồi hơn nữa, việc tách và gộp cũng coi như là đã custom protocol của proxy rồi, a.k.a chẳng còn là proxy nữa, thì tại sao lại không dùng luôn ssh tunnel hay là vpn protocol cho nó khỏe?

1 Like
#16

sni sẽ nằm trong gói tin ở quá trình bắt tay nha bạn, client dùng socks để kết nối đến proxy, hoặc 1 số game thì nó connect trực tiếp bằng udp luôn, ko dùng giao thức gì

mình nghĩ đơn giản proxy là 1 thằng trung gian nằm giữa client và server thôi, ko biết định nghĩa chính xác thế nào mới đc gọi là proxy, nên đúng là sẽ có 1 số liên kết ko dùng giao thức chuẩn, mà dùng giao thức khác

mình ko dùng trực tiếp ssh tunel, vì mình muốn tự tìm hiểu , cứ cho là sáng tạo lại bánh xe đi cũng đc, vd mình muốn clone lại 1 số chức năng của tailscale chẳng hạng

#17

à gói ở đây , đơn giản là các byte đọc lên từ buffer khi gửi hoặc nhận dữ liệu thôi, vd: client gửi 10 byte đến proxy , ở proxy mình read 5 byte , rồi gửi cho server, rồi mới đọc tiếp 5 byte nữa gửi cho server, thay vì gửi thẳng 10byte cho server

#18

Nếu bạn tìm hiểu “kỹ” hơn xíu nữa, bạn sẽ thấy nó là bắt tay giữa máy “client” và máy “server”. Đằng này, máy “server” là “proxy” thì làm gì còn cái SNI nào của server gốc ở đây nữa mà phải cắt, phải giấu? Nên nói chung là bài toán ban đầu của bạn nó không có hợp lý rồi á.

Tiếp theo, nếu dùng SOCKS, bạn sẽ thấy là gói tin gốc (vốn dĩ gửi lên server đích), sẽ được mã hóa rồi gửi đi đến server, nên là thông tin ban đầu chả còn gì liên quan cả đâu.

Cuối cùng, nếu gọi là “sáng tạo lại bánh xe”, thì nên coi thử bánh xe là gì, nó như thế nào trước khi ngồi tưởng tượng coi cái bánh xe hình tam giác phải làm ra sao :innocent:

1 Like
#19

đoạn này thì bạn hiểu sai ý mình, proxy của mình nằm ở chính giữa , client và server, chứ ko phải thằng client nó connect tới proxy như 1 server, nên trong gói bắt tay có sni của server gốc

cái này cũng ko liên quan luôn, vì mục đích mình ko phải đọc gói tin , nên nó mã hóa hay sao mình cũng ko quan tâm , mình chỉ là thằng đứng giữa forward lại dữ liệu thôi, có điều mình cắt nhỏ ra xong mới gửi

cái này thì đúng thật chưa biết bên trong họ viết kiểu gì bởi vậy mới khó đó, nếu có prj hoặc open source để đọc thì đỡ đoán già đoán non rồi

#20

Sorry, mình hiểu nhầm thật, vậy là ở đây là cần by pass cho connection từ proxy đến server. Nếu vậy thì đúng là chỗ proxy cần phải xử lý nhiều.

Tuy nhiên, vì phía server bạn khả năng cao là không thể custom được (bởi vì, nếu được thì bạn custom protocol luôn từ client lên server cho rồi), nên chỗ proxy bạn vẫn phải “xử lý” theo đúng các chuẩn đã biết => blocker vẫn có thể “xử lý ngược lại” để có packet gốc => vẫn có thể block như thường, mặc dù sẽ tốn công hơn một xíu. Tốt hơn là follow lại cái bánh xe đã có thôi bạn: https://github.com/Xetera/sni-proxy/blob/main/README.md

Còn về tailscale, không phải nó có opensource ở https://github.com/tailscale hay sao? Ít nhất là cũng có source của client, là cũng được một nửa kiến thức cần có rồi, còn hơn là chẳng có gì

2 Likes
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?