Cái dòng đó dùng interface list WAN, nên bác phải add cái interface pppoe-outX vào trong cái list WAN đó nữa (bảng Interface Lists trong cửa sổ Interfaces ý bác ạ)
Cứ để ether1 trong đó bác. Một là để nó áp dụng cái rule drop ngăn forward từ phía ngoài cổng ether1 vào trong LAN của bác. Hai là giả sử bác muốn vào trang web/ssh quản lý của cái converter/SFP GPON/modem nhà mạng đã bridge bằng địa chỉ IP của các thiết bị đó thì router sẽ tự động áp dụng NAT luôn (cái này là cần thiết vì các thiết bị đó giống như nằm ở WAN, ngoài LAN của bác, khác với Internet là không đi qua pppoe-out1 mà thôi).
Cứ để ether1 trong đó bác. Một là để nó áp dụng cái rule drop ngăn forward từ phía ngoài cổng ether1 vào trong LAN của bác. Hai là giả sử bác muốn vào trang web/ssh quản lý của cái converter/SFP GPON/modem nhà mạng đã bridge bằng địa chỉ IP của các thiết bị đó thì router sẽ tự động áp dụng NAT luôn (cái này là cần thiết vì các thiết bị đó giống như nằm ở WAN, ngoài LAN của bác, khác với Internet là không đi qua pppoe-out1 mà thôi).
CGGX_ANNX em đang gặp thêm 1 vấn đề là khi bất rule này lên thì port forward rất mất ổn định,
Code:
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
in-interface-list="List All Vlan"
Em đang sử dụng reverse proxy của con nas xpen và mở cổng 80 với 443, nhưng khi bật rule này thì khi truy cập từ mạng ngoài vào qua tên miền phải chờ rất lâu mới kết nối được và rất hay bị mất kết nối. Khi tắt đi rule đi thì đăng nhập lại ổn định như bình thường. Thêm cái nữa là khi bật rule này thì xài app mikrotik trên iphone không kết nối với router qua tên miền được, tắt đi thì lại kết nối bình thường trong khi kết nối trên web cũng bằng tên miền đó thì lại báo kết nối được.
CGGX_ANNX em đang gặp thêm 1 vấn đề là khi bất rule này lên thì port forward rất mất ổn định,
Code:
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
in-interface-list="List All Vlan"
Em đang sử dụng reverse proxy của con nas xpen và mở cổng 80 với 443, nhưng khi bật rule này thì khi truy cập từ mạng ngoài vào qua tên miền phải chờ rất lâu mới kết nối được và rất hay bị mất kết nối. Khi tắt đi rule đi thì đăng nhập lại ổn định như bình thường. Thêm cái nữa là khi bật rule này thì xài app mikrotik trên iphone không kết nối với router qua tên miền được, tắt đi thì lại kết nối bình thường trong khi kết nối trên web cũng bằng tên miền đó thì lại báo kết nối được.
Đặt lên trên 2 cái rules drop của chain forward đó bác (nếu có vài cái địa chỉ đích thì cho vào address list rồi sửa cái kia thành dst-address-list). Có điều không rõ vì sao bên bác nó không chạy. Nên em mới hỏi xem liệu bảng routing rules với bridge filter có gì không. Tiện thể bác check cả bảng RAW của cái Firewall nữa.
Với tiện thể sẵn rồi thì bác export luôn cấu hình VLAN xem thế nào:
em mới thử tắt hết các rule trong firewall thì thấy mặc định vlan 1 ping được tới mấy vlan kia luôn rồi, còn mấy vlan kia thì ping ngược không được. Em cũng không biết tại sao luôn @@
CGGX_ANNX em đang gặp thêm 1 vấn đề là khi bất rule này lên thì port forward rất mất ổn định,
Code:
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
in-interface-list="List All Vlan"
Em đang sử dụng reverse proxy của con nas xpen và mở cổng 80 với 443, nhưng khi bật rule này thì khi truy cập từ mạng ngoài vào qua tên miền phải chờ rất lâu mới kết nối được và rất hay bị mất kết nối. Khi tắt đi rule đi thì đăng nhập lại ổn định như bình thường. Thêm cái nữa là khi bật rule này thì xài app mikrotik trên iphone không kết nối với router qua tên miền được, tắt đi thì lại kết nối bình thường trong khi kết nối trên web cũng bằng tên miền đó thì lại báo kết nối được.
Khi ở ngoài mạng bác dùng domain name truy cập vào cổng 80, 443, hay 6690 với IP public của router thì đầu tiên packet nó chui vào mục (I) của sơ đồ routing, mục Prerouting. Ứng với nó là chain PREROUTING ở cái hình bên dưới. Nếu có rule trong bảng RAW của tường lửa thì cái box RAW PREROUTING kia xử lý packet qua các rule đó, sau đó packet đi qua connection tracking, rồi tiếp theo đến bảng Mangle. Cái box MANGLE PREROUTING sẽ là lúc các rules ở bảng Mangle có chain=prerouting được xử lý. Theo nội dung bảng Mangle bác post trước đó thì sẽ không dính phải rule nào cả, vì không match cổng 53 với 2 rules đầu và source address với các rules còn lại.
Sau box MANGLE PREROUTING là box DST-NAT. Lúc này các rules ở bảng NAT, chain dstnat sẽ được xem xét và cho chạy qua. Ở đây vì lý thuyết là các packets này sẽ match với trong 3 cái rules action=dst-nat vì chúng có cổng đích thuộc 80/443/6690 TCP và địa chỉ đích của packet là địa chỉ public của router, trùng với list "Wan IP" (TUY NHIÊN, hiện nay ở chỗ này có một vấn đề mà em sẽ đề cập ở post sau!). Như vậy là action=dst-nat được áp dụng với packet và địa chỉ đích của packet bị thay, không còn phải là địa chỉ public của router nữa, mà là một trong hai địa chỉ 192.168.10.8 hoặc 192.168.10.5 tùy cổng.
Như bác có thể thấy là chain INPUT của tường lửa không được sử dụng ở đây, tức là cái rule action=drop chain=input của bảng filter bác post ở trên không áp dụng cho các packet này. Chain FORWARD của tường lửa sẽ được áp dụng và đi theo mũi tên ở mục số (3) kia. Chỗ MANGLE FORWARD thì hiện chỉ có 1 cái rule có comment "-----Thay doi MSS-----" trong bảng mangle của bác là có chain=forward cần được xem xét. Tuy nhiên out-interface không phải wghp225 mà là VlanHome nên rule này được bỏ qua.
Sau MANGLE FORWARD là đến FILTER FORWARD, đây là chỗ các rules ở bảng filter, chain forward được xét đến. Khi đây là packet đầu tiên của kết nối, tức là khi connection-state=new thì nó sẽ lần lượt chạy từ trên xuống dưới và không match với rule chain=forward nào ở bảng filter được cả. Có cái rule drop cuối
Code:
add action=drop chain=forward \
comment="defconf: drop all from WAN not DSTNATed" \
connection-nat-state=!dstnat connection-state=new in-interface-list=Wan
Dù có connection-state=new và in-interface-list đúng là từ ngoài nên match list Wan, tuy nhiên vì trước đó đã đi qua hộp DST-NAT và được rule action=dstnat match, nên kết nối này đã có connection-nat-state=dstnat, thế nên rule drop này không áp dụng được vì nó yêu cầu connection-nat-state=!dstnat
Vì không match được rules nào nên packet này được accept cho qua. Các packet tiếp theo của kết nối có connection-state=established nên sẽ được rules tít bên trên của chain forward chấp thuận ngay. Tóm lại các packets không bị block.
Ở hình Routing, sau FORWARD là đến hộp POSTROUTING, mục số (4) ở bảng tường lửa. Ở đây bảng mangle của bác không có rule nào có action=postrouting nên packet đi qua mà không bị xử lý. Packet sau đó đi qua hộp SRC-NAT. Ở bảng NAT của bác có 3 rules masquerade thuộc chain srcnat, tuy nhiên cả 3 rules đều không áp dụng với packet port forwarding này vì hoặc là out-interface không khớp, hoặc là source address không khớp (rule thứ 2 Hairpin NAT).
Sau đó hết phần của tường lửa, sau khi đi qua phần xử lý queues, vì không phải IPSec (VPN), packet sẽ được route qua interface VlanHome đến thiết bị nhận port forwarding.
Tóm lại khi port forwarding nếu mọi rules ok thì packet sẽ không bao giờ chạm tới các rules của chain Input.
Khi nào cái rule kia ở chain INPUT bảng Filter nó áp dụng? Chính là khi bác dùng App MikroTik trên điện thoại dùng mạng bên ngoài nối vào router bằng domain name.
Khi đó app MikroTik từ ngoài internet sẽ thử mở kết nối đến địa chỉ IP public của router với cổng TCP 8291 (App này dùng đúng cổng và giao thức của WinBox).
Cũng đi qua Mangle Prerouting và không match được với rules nào nên không bị thay đổi, sau đó cũng đi qua DSTNAT. Tuy nhiên lần này không có rules nào ở chain dstnat bảng NAT áp dụng được cả, vì cổng TCP 8291 không có rules port forwarding nào hết. Sau khi đi hết chain PREROUTING thì dst-address của packet vẫn là địa chỉ IP public của Router. Tức là đích đến của packet chính là router. Do đó mục ROUTING DECISION số (2) ở hình kia sẽ quyết định chuyển packet sang bên phải sang chain INPUT chứ không phải FORWARD như trước.
Chain Input của firewall xử lý packet. Ở bảng Mangle không có rule nào với chain input nên packet chuyển tiếp sang bảng Filter, mục (3B), ở đây ta có một số rules liền.
Vì đây là packet đầu tiên của kết nối nên connection-state=new, rule đầu (established,related,untracked) và rule 2 (invalid) sẽ bị skipped. Tiếp theo, vì không phải protocol = ICMP mà là TCP nên rule thứ 3 cũng không áp dụng. Đến rule thứ tư
Code:
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!Lan
lúc này in-interface là pppoe-out1 vì từ ngoài internet vào, thế nên match được với điều kiện in-interface-list=!Lan như vậy action=drop được áp dụng, packet được vứt bỏ.
Đây chính là lý do vì sao bác thử dùng app MikroTik trên điện thoại nối từ ngoài vào mà không được. NHƯNG ĐÂY LÀ KẾT QUẢ MÀ BÁC MUỐN VÀ CẦN! Một trong những mục đích của cấu hình tường lửa này là bảo vệ router, bác sẽ không muốn từ bên ngoài internet thử kết nối vào cổng WinBox của router để rồi mà thử bruteforce password này nọ (như nhiều bác trong này đã phàn nàn vì thấy trong log toàn các attempts thử brute force login vào cổng WinBox). Cái cổng 8291 này chắc chắn bác không nên để bên ngoài kết nối vào được. Và ở đây tường lửa đã làm tốt nhiệu vụ của mình. Đó là chỉ chấp nhận cho các kết nối port forwarding được đi vào.
Vậy bác cần làm gì nếu muốn từ ngoài nối vào quản lý router bằng App? Điều bác nên làm là thiết lập VPN, thí dụ WireGuard, khi này bác sẽ cần mở đúng 1 cổng UDP cho cái WireGuard ở chain Input. Vì WireGuard bảo mật tốt hơn và dùng keys chứ không phải password nên không thể brute force được như username và password. Bên ngoài bác sẽ kết nối qua WireGuard vào router và sau đó mới dùng App qua kết nối VPN đó.
@bukkahero Ở post vừa rồi thì em và bác đã thấy là hiện cấu hình tường lửa trên, với các kết nối mới từ ngoài internet vào địa chỉ IP public của router, mà không phải packet ICMP, thì hiện có 2 khả năng là cổng khớp với cổng của rules dstnat và packet được dst-nat sang đích là LAN, rồi cho qua chain forward; hoặc không khớp với rules dstnat và giữ đích đến là router, chuyển qua chain input, và hiện bị drop sạch vì không mở cổng nào tiếp nhận ở chain input.
Vấn đề là ở chỗ mấy cái rules dstnat này. Bình thường, khi router có địa chỉ IP public động, không thể hard-coded vào trong dst-address= của rules dstnat của port forwarding được, thì có cách đơn giản là bỏ điều kiện dst-address="địa chỉ public" đi và dùng in-interface/hoặc in-interface-list và match nó với interface hoặc interface list chứa các interface phía WAN, thí dụ in-interface=pppoe-out1 hoặc in-interface-list=Wan.
Tuy nhiên khi muốn ở trong LAN cũng dùng địa chỉ public của router để vào các dịch vụ đã được port forwarded này (cái trường hợp cần Hairpin NAT ý) thì áp dụng điều kiện in-interface/in-interface-list không được, vì từ LAN thì in-interface là interface trong LAN, không thuộc list Wan. Vì thế phải quay sang dùng điều kiện dst-address. Nhưng địa chỉ động và ta không muốn phải edit rules mỗi khi địa chỉ thay đổi nên mới phải dùng trick với dst-address-list.
Và ở đây có thể có một vấn đề với cái address list "Wan IP" trong 3 cái rules kia nếu như bác lỡ làm theo em mấy ngày vừa rồi.
Mấy hôm trước em bảo bác để có được list chứa địa chỉ IP public của router đơn giản nhất thì bác chỉ việc tạo 1 entry trong bảng address list với giá trị address là cái domain DDNS của bác, khi đó nó sẽ tự đông resolve domain và tạo 1 entry dynamic có cùng tên chứa địa chỉ đã được resolved ra và có thể sử dụng dược trong rules dstnat này ngay. Điều này đúng cho đến ngày hôm qua.
Hôm qua thì em có khuyên bác là để workaround vấn đề chưa tìm hiểu được là các thiết bị ở Lan-Ex-Home không dùng được DNS server là con pihole bên VlanHome, thì bác nên chuyển sang cho con Router làm DNS relay, bằng cách để địa chỉ của con pihole vào mục "Servers" trong cấu hình DNS của RouterOS, và lái các thiết bị ở các mạng sử dụng địa chỉ của router làm địa chỉ DNS. Tuy nhiên điều này cũng có nghĩa là khi router thử resolve cái domain DDNS kia để tìm ra địa chỉ IP cho cái address list "Wan IP", thì router sẽ quay sang hỏi con pihole (vì pihole nằm trong danh sách upstream DNS servers của router).
Vấn đề là con pihole của bác đang cấu hình để trả về địa chỉ local trong LAN cho cái domain kia! Tức là nếu bác follow cả 2 hướng dẫn này thì hiện nay cái address list "Wan IP" kia không có địa chỉ public của router, mà là địa chỉ LAN của cái NAS 192.168.10.10 thì phải. Điều đó có nghĩa là các rules DSTNAT kia không match với các kết nối từ ngoài internet vào các cổng port forwarding. Và khi không match với rules DSTNAT thì packet không bị sửa địa chỉ destination và vẫn giữ địa chỉ là public IP của router, và như ở trên bác đã đọc, điều đó có nghĩa là bị mang ra chain input xử lý và sẽ bị drop bởi rule ở bảng filter!
Thế nên giờ phải làm cách khác để gán giá trị cho list "Wan IP" ạ, không dùng cách để router resolve domain name nữa mà dùng script. Bác vào System - Scripts thêm script này, đặt tên là "update_pppoe_address" chẳng hạn, với nội dung:
Bác lưu nó rồi ấn Run Script cho nó chạy 1 lần. Kiểm trang trong bảng Address List của Firewall xem nó đã update đúng chưa.
Bây giờ phải cấu hình để script chạy mỗi khi kết nối PPPoE được quay lại thành công, vì lúc đó thường sẽ có địa chỉ public mới. Bác vào chỗ kết nối PPPoE, kiểm tra xem nó đang dùng profile gì
Bác vào bảng PPP - Profiles, chọn profile với tên tương ứng
và thêm script chạy lúc On Up, để gọi cái script kia:
Code:
/system script run "update_pppoe_address"
Hi vọng đấy là nguyên nhân vấn đề bác gặp phải khi truy cập từ ngoài internet vào mấy cái bác đã port forward kia, mà phải tắt filter chain input mới chạy. Còn việc dùng app MikroTik từ ngoài không vào được là đúng bác nhé, cái này khắc phục bằng cách thiết lập VPN kiểu WireGuard rồi vào qua đó mà thôi.
Cấu hình VLAN của bác hiện em không thấy có vấn đề gì cả. Với việc bác dùng Proxmox với 1 cổng Trunk cho các VLAN cũng không làm sao hết và được hỗ trợ bình thường. Ngoài ra theo config này thì không có gì làm vlanhome khác biệt vlaniot cả nên không thể giải thích việc vlanhome được đặc cách ngay cả khi bác tắt sạch filter cả (bật filter thì có cái rule drop từ Vlan-Ex-Home sang Lan).
Còn bên bảng RAW của Firewall có rule nào không hả bác?
Cấu hình VLAN của bác hiện em không thấy có vấn đề gì cả. Với việc bác dùng Proxmox với 1 cổng Trunk cho các VLAN cũng không làm sao hết và được hỗ trợ bình thường. Ngoài ra theo config này thì không có gì làm vlanhome khác biệt vlaniot cả nên không thể giải thích việc vlanhome được đặc cách ngay cả khi bác tắt sạch filter cả (bật filter thì có cái rule drop từ Vlan-Ex-Home sang Lan).
Còn bên bảng RAW của Firewall có rule nào không hả bác?
Cấu hình VLAN của bác hiện em không thấy có vấn đề gì cả. Với việc bác dùng Proxmox với 1 cổng Trunk cho các VLAN cũng không làm sao hết và được hỗ trợ bình thường. Ngoài ra theo config này thì không có gì làm vlanhome khác biệt vlaniot cả nên không thể giải thích việc vlanhome được đặc cách ngay cả khi bác tắt sạch filter cả (bật filter thì có cái rule drop từ Vlan-Ex-Home sang Lan).
Còn bên bảng RAW của Firewall có rule nào không hả bác?
Sau khi ngâm cứu cái config của bác em vẫn chưa tìm ra lý do gì mà bên các vlan khác không ping được 192.168.10.10 (con pihole ping được từ vlanhome đúng không bác?).
Bây giờ nếu bác tạm thời disable tất cả các rules ở bảng filter, tất cả các rules ở bảng mangle, các rule ở bảng NAT ngoại trừ rule
IPv6 bình thường không dùng NAT, với cấu hình bình thường trong RouterOS, có IPv6 forwarding, cấp địa chỉ bằng SLAAC, mỗi một thiết bị có địa chỉ global unicast riêng của mình, thì khi bác vào trang test kia, trang đó sẽ thử kết nối với địa chỉ của máy PC hay điện thoại mà bác đang ngồi chạy cái test chứ không phải kết nối vào địa chỉ IPv6 của router. Vì thế để block "ping" cho cái ô "ECHO REPLY" nó không vàng như trong hình nữa, bác phải hoặc là block trên tường lửa của từng thiết bị, hoặc là block trên RouterOS nhưng mà là add thêm rule vào chain FORWARD, chứ chain INPUT không thì không đủ.
Bác thêm rule này vào bảng filter rồi kéo lên trước rule hiện đang accept ICMPv6 ở chain forward.
và thêm rule ở chain input nếu bác muốn block cả ping đến địa chỉ router.
Thực tế ra mà nói thì block ping IPv6 vào thiết bị đằng sau router cũng không mang lại lợi ích cho lắm . Vì khi dùng SLAAC cái phần đuôi 64bit interface-id của cái địa chỉ của thiết bị nó khó mà mò ra bằng cách thử dần dần được (quá nhiều khả năng, ngay cả với phần interface-id dùng EUI64 dựa trên MAC address). Nên ai muốn ping được thiết bị bác thì phải biết địa chỉ full của nó trước bằng cách nào đó khác, mà thực tế chỉ là bằng cách vì bác nối vào dịch vụ/server của họ thì họ mới thấy địa chỉ của bác từ source address của packet thôi. Mà khi đó tức là họ không cần ping cũng biết thiết bị bác đang online . Bình thường các thiết bị cá nhân (PC/điện thoại/tablet) ngày nay toàn dùng địa chỉ IPv6 temporary để nối vào các dịch vụ, sau vài tiếng-một ngày là thay địa chỉ với interface id khác. Nên phía bên kia lưu lại địa chỉ để hôm sau ping thử lại cũng không có tác dụng.
Sau khi ngâm cứu cái config của bác em vẫn chưa tìm ra lý do gì mà bên các vlan khác không ping được 192.168.10.10 (con pihole ping được từ vlanhome đúng không bác?).
Bây giờ nếu bác tạm thời disable tất cả các rules ở bảng filter, tất cả các rules ở bảng mangle, các rule ở bảng NAT ngoại trừ rule
hi bác em đã tìm ra lý do không ping được và fix xong, hiện tại còn 1 vấn đề vẫn chưa fix được là khi bật 2 rule ở phần nat này để force dns là mất mạng
Phần DNS trong ip em để trống mà bật rule này lên là bị mất mạng, phải vào dns điền ip của con pihole vào và tắt 2 cái rule ở nat đi thì mới vào lại được.