CGGX_ANNX
Senior Member
@CGGX_ANNX Em đang làm cách này để truy cập vào các trang bị nhà mạng chặn
Em muốn hỏi thêm là ngoài cách này thì có cách nào tối ưu hơn để vào các trang bị nhà mạng chặn ko?
Cũng tùy các nhà mạng chặn kiểu gì bác ạ. Nếu nhà mạng chặn bằng cách block định tuyến cả dải địa chỉ IP của trang web thì chỉ có giải pháp dùng VPN. Nhưng ngày nay do các trang web dùng dịch vụ CDN ngày càng nhiều, nên nhà mạng khó có khả năng block định thuyến dải IP vì sẽ ảnh hưởng đến các trang và dịch vụ khác không cần block.
Nếu nhà mạng block kiểu hời hợt là DNS server của nhà mạng không trả lời query cho domain bị block, hay trả lời lái về địa chỉ IP khác do nhà mạng quản lý (và bị chặn) thì giải quyết được bằng cách dùng DNS bên thứ 3. Tuy nhiên phải dùng DNS over HTTPS (DoH) mới ăn thua, vì ngày nay có vẻ các nhà mạng cũng intercept kết nối UDP và TCP tới cổng 53 rồi sửa response/chặn query DNS (vì DNS53 không có mã hóa bảo mật gì cả). Dùng DNS over TLS (DoT) tuy bảo mật nhưng dễ bị nhà mạng block vì sử dụng cổng 853, hầu như không có gì khác dùng nên block 1 phát là xong. DoH thì dùng cổng 443 nhà mạng khó block hàng loạt.
Như vậy là nên dùng DoH cái đã. RouterOS hỗ trợ DoH rồi, tuy nhiên như em viết ở trên dùng DoH trực tiếp trên DoH thì một số tính năng như FWD kia không chạy, khi đó muốn vừa có DoH vừa có tính năng như kia thì bác chạy resolver khác trong mạng LAN, resolver đó dùng DoH nối ra ngoài, còn RouterOS dùng con trong LAN đó làm Upstream.
Ngoài việc block DNS mà người thường có thể vượt qua khác dễ dàng thì nhà mạng có chặn bằng DPI (Deep packet inspection) với một số site quen thuộc (kiểu medium, bbc, pỏn) bằng cách đọc một vài packet đầu của kết nối TCP. quét các chuỗi kia. Nhiều năm trước đa phần kết nối không mã hóa thì đọc trộm dễ dang biết site client đang nối đến mà không phải nhớ từng địa chỉ IP. Ngày nay hầu hết các kết nối web đều mã hóa hết (HTTPS), nhưng với các chuẩn TLS và HTTP những năm trước thì nhà mạng vẫn biết bác nối vào site nào chỉ từ mấy packet đầu của kết nối, do ban đầu kết nối client thường gửi tên domain lên khi thiết lập đường TLS (cần vì SNI). Kiểu quét này tương tự như cách RouterOS hỗ trợ cái "TLS Host" trong filter tường lửa vậy. Và khi phát hiện ra người dùng đang nối và site cấm thì nhà mạng thường ngắt kết nối rất nhanh bằng cách gửi 1 packet TCP RST về client. Để client ngắt ngay kết nối mà không đợi timeout với thử lại nhiều lần như trong trường hợp nhà mạng chỉ drop packet.
Tuy nhiên kiểu này ngày ngay cũng không hiệu quả nữa. Thứ nhất là các browser hiện đại và các server hỗ trợ chuẩn mới khiến trò DPI này không chạy. Thí dụ nếu dùng HTTP/3 dựa trên QUIC (dùng UDP) thì không còn khái niệm kết nối TCP nữa, nên gửi packet TCP RST không tác dụng. Ngoài ra ngày càng nhiều site hỗ trợ ECH (Encrypted Client Hello), nên tên domain không được gửi ở dạng plain text lên nữa nên nhà mạng không scan được ra domain.
Có một vấn đề là mặc định các browser thường vẫn dùng HTTP/2 với TCP để thiết lập kết nối đầu tiên tới trang web trong lần viếng thăm đầu, do không biết server có hỗ trợ HTTP/3 không. Tức là nhà mạng vẫn có khả năng chặn ở kết nối HTTP/2 này. Thí dụ medium với bbc là như vậy. Tuy nhiên ngày nay có chuẩn mới cho phép dùng resource record (RR) mới HTTPS trong thông tin DNS để bảo client thiết lập kết nối HTTP/3 ngay từ đầu, bỏ qua toàn bộ chuẩn cũ hơn. Khi đó nhà mạng bó tay vì ngay packet đầu đã là QUIC dùng UDP. Nếu các site đã hỗ trợ HTTP/3 nhưng chưa hỗ trợ HTTPS DNS RR thì bác có thể cài resolver ở nhà cho nó tự trả lời DNS query HTTPS RR với các site này để bảo client dùng HTTP/3.
Ngay cả nếu không có HTTPS RR hay tự hack để có HTTPS RR thì với nhiều site như medium, bác dùng các browser hiện đại như các bản mới nhất của Chrome và Edge, thì bác refresh trang bị TCP RST vài lần là xong. Nhiều lúc còn không cần refresh. Lý do là các browser hiện đại để tận dụng lợi ích mà HTTP/3 và QUIC mang lại (tạo kết nối nhanh hơn nhiều, ít round trip hơn so với sử dùng TCP và TLS) thì các browser đều thử khởi tạo cùng 1 lúc 2 kết nối HTTP/2 hay 1.1 kiểu cũ và HTTP/3 kiểu mới. Nếu nhận được trả lời từ kết nối QUIC trước thì browser sẽ tự chuyển sang dùng HTTP/3. Thế nên nhiều lúc bác refresh một hồi là cái packet UDP trả lời cho kết nối QUIC nó đến nhanh hơn cái packet TCP RST nhà mạng gửi thì browser của bác cũng tự chuyển sang HTTP/3 và ignore kết TCP HTTP/2 hay 1.1 kia.
Ngay cả nếu trang web không hỗ trợ ECH với HTTP/3 thì nếu bác dùng RouterOS với mấy rule tường lửa mặc định defconf thì nhiều lúc cả các site chỉ dùng HTTP/2 với TLS 1.2/1.3 thuần túy (thí dụ rất nhiều site pỏn) vẫn vào được (miễn là bác dùng DNS server không bị nhà mạng kiểm soát). Mặc dù ban đầu có thể báo lỗi bị RST hay refused, nhưng bác refresh vài lần là ngon, lý do là nhà mạng ngắt kết nối bằng packet RST nhưng nếu timing không đúng thì sẽ dính phải cái rule drop invalid packet trong cấu hình tường lửa defconf của RouterOS, vì thứ tự các packet đến sai nên RouterOS sẽ drop chính cái packet RST đó và bác vào site pỏn dùng công nghệ cũ này vẫn ngon lành. Vì cái DPI nó chỉ scan và block vài packet đầu của kết nối và không scan tiếp (không đủ tài nguyên để làm việc này), nêu router drop được cái packet RST mà nó thấy là invalid do thứ tự/timing kia thì sau đó bác vào được vù vù.
Tóm lại em không biết bên mạng bác như nào. Bên FPT của em các site bị block thì chỉ cần dùng secure DNS (DoH) với browser mới, tường lửa có rule drop invalid, thì hầu như qua được hết các site bị block, cùng lắm là refresh vài lần. Hoặc với site hỗ trợ HTTP/3 mà bác setup hijack được cái DNS HTTPS RR thì không cần refresh.
Nhà mạng muốn block hiệu quả sẽ phải quay về block theo dải địa chỉ IP mà thôi. Nhưng cái này tầm ảnh hưởng rộng quá (chia sẻ dải IP do dùng CDN với dịch vụ Cloud), với địa chỉ có thể thay đổi thường xuyên nên hiện hiếm thấy nhà mạng còn sử dụng biện pháp này.
