thảo luận Cộng đồng người dùng MikroTik Router

Klq đến Mik nhưng cho hỏi có b nào đang dùng DDNS của Google trên Xpenology ko?
Hôm nay nó move qua bên Squarespace rồi giờ kết nối nó báo failed, mặc dù vẫn truy cập NAS được qua domain. Giờ nên chuyển qua thằng nào nhỉ?
 
Mục đó là sử dụng cho việc gì ạ ? Em đang xài Wireguard nó để chơi game có tác dụng ko nhỉ ? VỚi cho em hỏi có 1 dãy danh sách VPN NORD có cách nào nó chọn add hết vào MIKROTIK để nó tự chọn cái tốt nhất chạy ko nhỉ ? Mong ai biết chỉ giùm em cái !
Should be used on WireGuard devices that are used as "servers" for other devices as clients to connect to. Otherwise router will all repeatedly try to connect "endpoint-address" or "current-endpoint-address" causing unnecessary system logs to be written
Tạm dịch:
Nên sử dụng trên các thiết bị WireGuard làm "máy chủ" cho các thiết bị khác (máy khách) kết nối vào. Nếu không, bộ định tuyến sẽ liên tục cố kết nối đến "endpoint" hoặc "endpoint" hiện có, khiến bị ghi log hệ thống không cần thiết.
Nói như thế thì WG Server nên để responder=yes
 
Mục đó là sử dụng cho việc gì ạ ?

Như bác @wuhoatu đã giải thích ở post trên. Còn lý do cái setting này nó xuất hiện là vì:

* WG thực chất không có khái niệm client-server. Hai đầu của tunnel WG là hai peers ngang hàng nhau, về lý thuyết đều có thể là thằng gửi khởi tạo tunnel hay gửi packet handshake cho thằng bên kia. Tất nhiên là nếu khi cấu hình 1 peer mà không điền thông tin Endpoint (địa chỉ và cổng) thì sẽ không có thông tin đích đến để mà khởi tạo kết nối hay gửi đi.

* Khi đã từng thiết lập và chạy thành công tunnel giữa 2 peers, thì lúc này cả hai đều có thông tin endpoint, là địa chỉ và cổng của đầu bên kia. Thế nên trong RouterOS tuy bác không điền Endpoint nhưng nếu kết nối được ít nhất 1 lần thì thông tin endpoint của lần handshake thành công cuối sẽ có và là thông tin hiện ở mục Current Endpoint Address và Current Endpoint Port (cho đến khi reboot). Như vậy có điền Endpoint hay không cũng không quan trong nữa, coi như RouterOS có thông tin này rồi.

* Do tính chất ngang hàng nhau của 2 đầu peers WG, và đo WG dùng UDP không có kết nối dài lâu như TCP, nên thỉnh thoảng 2 bên lại gửi handshake cho nhau bằng cách gửi packet đến cái cổng UDP và địa chỉ từ thông tin endpoint của peer, một phần cũng là để giữ cái "kết nối" UDP nó sống (thực ra là để giữ cổng UDP nó vẫn mở trên stateful firewall). Việc thường xuyên thử gửi handshake này từ lúc RouterOS 7 mới có hỗ trợ WG luôn diễn ra, nếu RouterOS có thông tin endpoint của peer bên kia (từ current endpoint là đủ, không cần ghi trong thiết lập Endpoint). Nếu peer bên kia ngỏm thì sau khoảng 20 lần thử gửi handshake nó sẽ thôi. Không những thế, còn có 1 bug khiến RouterOS cũng gửi handshake này ngay cả khi không có thông tin endpoint, lúc này nó thử handshake với 0.0.0.0.

* Trước đây chẳng ai quan tâm đến điều này, do trước đây RouterOS hầu như chẳng ghi log gì cho wireguard cả, kết nối bị lỗi cũng không có log. Bắt đầu từ 7.14 thì có thay đổi này:

Code:
7.14
*) wireguard - optimised and improved WireGuard service logging;


Kết quả là trong log tràn ngập các dòng "info" thông báo không nhận được trả lời từ bên kia lúc thử handshake. Các bác có thể search "wireguard" ở cái topic release 7.14 và thấy các chú phàn nàn loạn lên v7.14.3 [stable] is released! - MikroTik (https://forum.mikrotik.com/viewtopic.php?t=205097#p1059453).

* Sau khi bị phàn nàn nhiều quá thì bản 7.14.1 sửa cái lỗi handshake với 0.0.0.0 lúc hoàn toàn không có thông tin endpoint:

Code:
7.14.1
*) wireguard - do not attempt to connect to peer without specified endpoint-address;

* Thế nhưng ra xong forum vẫn đầy phàn nàn, lý do là như ở trên em viết, chỉ cần từng có kết nối thành công 1 lần trước đó (và chưa reboot) là sẽ có thông tin endpoint. Như vậy nếu ở ngoài dùng điện thoại nối qua WG về router thì sau đó, ngay cả khi điện thoại tắt WG rồi, RouterOS vẫn sẽ tiếp tục thử (khoảng 20 lần) gửi handshake, và kết quả lại đầy dòng log trong bảng log.

* Nên giải pháp mới nhất là từ bản 7.15 có thêm cái checkbox "Responder" kia. Bật nó lên thì RouterOS sẽ không thử tự gửi handshake đi nữa, mà chỉ đợi đầu bên kia tạo handshake, ngay cả khi nó đủ thông tin về địa chỉ và cổng endpoint hiện thời của peer. Như vậy nếu bật lên với peer ứng với điện thoại chẳng hạn, và điện thoại ngắt WG đột ngột thì sẽ không bị có một lũ dòng log phàn nàn handshake với peer không thành công nữa.
 
cho e hỏi mấy bác để MTU của port ethernet quay pppoe là bao nhiêu vậy ạ?

Nếu ISP của bác hỗ trợ MTU 1500 cho PPPoE (hiện đã có feedback của các trên này dùng cả 3 nhà mạng lớn đã đặt được MTU 1500, ít ra là khi dùng converter (cái G-97CM của FPT có hỗ trợ) hay module GPON SFP, còn có vẻ nếu chỉ bridge qua modem nhà mạng thì ít thành công hơn) thì bác đặt MTU của interface ethernet hoặc VLAN ngay dưới cái PPPoE là 1508 nhé (cần 1508 nếu không MSS bị chỉnh sai). Còn interface pppoe-outX thì để Max MRU = Max MTU = 1500. Với 7.15 trở lên chỉ cần sửa MTU=1508 cho cái interface ngay dưới cái PPPoE thôi. Tức là nếu dùng interface VLAN thì chỉ cần cái VLAN sửa 1508, cái etherX/sfpX/sfp-plusX/bridgeX dưới cái VLAN có thể để nguyên 1500 không quan trọng. Tuy nhiên nếu dùng 7.13.x-7.14.x thì lại có 1 cái bug, lúc này cái interface etherX/sfpX/sfp-plusX/bridgeX dưới cái VLAN bác cũng phải đặt MTU 1508.

Nếu ISP không hỗ trợ MTU 1500 cho PPPoE, hoặc bác bridge router nhà mạng và không được, thì không quan trọng thiết lập MTU của interface ethernet/vlan, cứ để 1500 mặc định là đủ.
 
Nếu ISP của bác hỗ trợ MTU 1500 cho PPPoE (hiện đã có feedback của các trên này dùng cả 3 nhà mạng lớn đã đặt được MTU 1500, ít ra là khi dùng converter (cái G-97CM của FPT có hỗ trợ) hay module GPON SFP, còn có vẻ nếu chỉ bridge qua modem nhà mạng thì ít thành công hơn) thì bác đặt MTU của interface ethernet hoặc VLAN ngay dưới cái PPPoE là 1508 nhé (cần 1508 nếu không MSS bị chỉnh sai). Còn interface pppoe-outX thì để Max MRU = Max MTU = 1500. Với 7.15 trở lên chỉ cần sửa MTU=1508 cho cái interface ngay dưới cái PPPoE thôi. Tức là nếu dùng interface VLAN thì chỉ cần cái VLAN sửa 1508, cái etherX/sfpX/sfp-plusX/bridgeX dưới cái VLAN có thể để nguyên 1500 không quan trọng. Tuy nhiên nếu dùng 7.13.x-7.14.x thì lại có 1 cái bug, lúc này cái interface etherX/sfpX/sfp-plusX/bridgeX dưới cái VLAN bác cũng phải đặt MTU 1508.

Nếu ISP không hỗ trợ MTU 1500 cho PPPoE, hoặc bác bridge router nhà mạng và không được, thì không quan trọng thiết lập MTU của interface ethernet/vlan, cứ để 1500 mặc định là đủ.
Của Em Mặc Định ko chỉnh gì được lun ! Với Cho Em hỏi DNS "MÌNH THÍCH"Nó có thể tự cập nhât tự động ko hay phải chỉnh thủ công bằng tay ạ !
 
Của Em Mặc Định ko chỉnh gì được lun ! Với Cho Em hỏi DNS "MÌNH THÍCH"Nó có thể tự cập nhât tự động ko hay phải chỉnh thủ công bằng tay ạ !

Chỗ này mục Actual MTU không chỉnh được vì là thông tin hiện, nhưng 2 mục chỉnh được thì như post trên em ghi là cái Max MTU và Max MRU bác nhé, để cả hai là 1500. Interface vlan10 bác để MTU 1508.
 
Nếu ISP của bác hỗ trợ MTU 1500 cho PPPoE (hiện đã có feedback của các trên này dùng cả 3 nhà mạng lớn đã đặt được MTU 1500, ít ra là khi dùng converter (cái G-97CM của FPT có hỗ trợ) hay module GPON SFP, còn có vẻ nếu chỉ bridge qua modem nhà mạng thì ít thành công hơn) thì bác đặt MTU của interface ethernet hoặc VLAN ngay dưới cái PPPoE là 1508 nhé (cần 1508 nếu không MSS bị chỉnh sai). Còn interface pppoe-outX thì để Max MRU = Max MTU = 1500. Với 7.15 trở lên chỉ cần sửa MTU=1508 cho cái interface ngay dưới cái PPPoE thôi. Tức là nếu dùng interface VLAN thì chỉ cần cái VLAN sửa 1508, cái etherX/sfpX/sfp-plusX/bridgeX dưới cái VLAN có thể để nguyên 1500 không quan trọng. Tuy nhiên nếu dùng 7.13.x-7.14.x thì lại có 1 cái bug, lúc này cái interface etherX/sfpX/sfp-plusX/bridgeX dưới cái VLAN bác cũng phải đặt MTU 1508.

Nếu ISP không hỗ trợ MTU 1500 cho PPPoE, hoặc bác bridge router nhà mạng và không được, thì không quan trọng thiết lập MTU của interface ethernet/vlan, cứ để 1500 mặc định là đủ.
Viettel brigde và SFP đều chạy 1508 đó b!
 
Viettel brigde và SFP đều chạy 1508 đó b!

Vâng bác. Ý em là lúc không bật được thành công MTU 1500 trên pppoe-outX (do có các bảo dùng bridge modem nhà mang xong chỉnh Max MTU = Max MRU = 1500 thì Actual MTU nó vẫn chỉ ghi 1480 hay 1492 ý ạ) thì không cẩn sửa MTU của interface bên dưới làm gì nữa. Còn nếu pppoe-outX nó ra được thành công Actual MTU 1500 thì lúc đó cần chỉnh MTU bên dưới lên 1508 (1 tầng bên dưới thôi).

Nếu ISP hỗ trợ và cái Layer 2 (bridge, converter, GPON module) cũng hỗ trợ thì Actual MTU của pppoe-outX vẫn sẽ được là 1500 ngay cả khi không nâng MTU bên dưới lên 1508. Và vẫn gửi được packet IP với đủ kích thước 1500 bytes qua PPPoE bình thường. Lý do cần nâng MTU bên dưới lên 1508 chỉ là do cái bug của cái phần chỉnh tự động TCP MSS của MikroTik mà thôi. Nếu không nâng lên thì các packet của kết nối TCP vẫn bị RouterOS giới hạn ở 1492 bytes (do không cho MSS quá 1452).
 
Vâng bác. Ý em là lúc không bật được thành công MTU 1500 trên pppoe-outX (do có các bảo dùng bridge modem nhà mang xong chỉnh Max MTU = Max MRU = 1500 thì Actual MTU nó vẫn chỉ ghi 1480 hay 1492 ý ạ) thì không cẩn sửa MTU của interface bên dưới làm gì nữa. Còn nếu pppoe-outX nó ra được thành công Actual MTU 1500 thì lúc đó cần chỉnh MTU bên dưới lên 1508 (1 tầng bên dưới thôi).

Nếu ISP hỗ trợ và cái Layer 2 (bridge, converter, GPON module) cũng hỗ trợ thì Actual MTU của pppoe-outX vẫn sẽ được là 1500 ngay cả khi không nâng MTU bên dưới lên 1508. Và vẫn gửi được packet IP với đủ kích thước 1500 bytes qua PPPoE bình thường. Lý do cần nâng MTU bên dưới lên 1508 chỉ là do cái bug của cái phần chỉnh tự động TCP MSS của MikroTik mà thôi. Nếu không nâng lên thì các packet của kết nối TCP vẫn bị RouterOS giới hạn ở 1492 bytes (do không cho MSS quá 1452).
MTU 1500 và 1492 nó khác biệt nhiều không bác, em thử thì không thấy khác biệt lắm 😅
 
MTU 1500 và 1492 nó khác biệt nhiều không bác, em thử thì không thấy khác biệt lắm 😅
Có khác nha thím

Cái 1492 hay 1480 mà ko có mangle để clamp to mptu. Thì ipv6 nó giựt sảng luôn. Mangle vên ipv6 ấy ,
Bỏ rule clamp vô êm liền.

Còn overhead nâng dư 8 bytes. Cho nó lên 1508 trừ 8 còn 1500 thì khỏi cần rule trong mangle.

Mà em thì kẹp luôn rule cho chắc cú 1 tí.
 
Có khác nha thím

Cái 1492 hay 1480 mà ko có mangle để clamp to mptu. Thì ipv6 nó giựt sảng luôn. Mangle vên ipv6 ấy ,
Bỏ rule clamp vô êm liền.

Còn overhead nâng dư 8 bytes. Cho nó lên 1508 trừ 8 còn 1500 thì khỏi cần rule trong mangle.

Mà em thì kẹp luôn rule cho chắc cú 1 tí.
ipv6 hiện tại em không dùng thím 😅, dùng nó 1 số web có ipv6 mới dùng đc còn k có ipv6 thì tạch nên em chưa dùng.
Client thím cho dùng ipv4 và ipv6 đồng thời hay chỉ 1 trong 2?.
 
ipv6 hiện tại em không dùng thím 😅, dùng nó 1 số web có ipv6 mới dùng đc còn k có ipv6 thì tạch nên em chưa dùng.
Client thím cho dùng ipv4 và ipv6 đồng thời hay chỉ 1 trong 2?.

Bình thường dual stack IPv6 và IPv4 chạy đồng thời thoải mái. Nếu dịch vụ với host chỉ có IPv4 thì máy bác dùng IPv4 khi nối vào chúng. Nếu cái nào hỗ trợ cả hai (DNS resolve ra được cả A lẫn AAAA record) thì các thiết bị sẽ ưu tiên sử dụng IPv6 TRỪ KHI thiết bị của bác hoặc host phía kia chỉ có địa chỉ ULA (bắt đầu bằng fdxx: ý), không có địa chỉ global, GUA. ULA mức ưu tiên thấp hơn IPv4 nên khi này IPv4 sẽ được sử dụng. Còn nếu đầu kia tên miền chỉ có AAAA (hoặc điền trực tiếp địa chỉ IPv6) thì IPv6 được dùng ngay cả khi chỉ có địa chỉ ULA.

Có IPv6 GUA thì không cần lo bị CGNAT, có thể nối trực tiếp về nhà. Cũng không cần port forwarding, mỗi thiết bị có địa chỉ riêng trên Internet nối trực tiếp vào được (nếu tường lửa cho phép). Nhược điểm là payload mỗi packet bị giảm 20 bytes so với IPv4 (overhead nhiều hơn).
 
Back
Top