Chúng tôi đang làm việc với một PLC (phoenix plc tiếp theo) kết nối với mạng profinet (và profibus). Do thiếu công cụ và không thể kết nối lại mọi thứ theo nhu cầu của chúng tôi (PLC được tích hợp trong máy của chúng tôi), chúng tôi đang tìm kiếm các cách khác nhau để truy cập một số máy chủ web https trên master profibus.
Vì vậy, từ một khoảng cách nào đó, chúng tôi có một PC Windows. PC này được kết nối thông qua một công tắc với PLC. PLC này đang chạy trên bản phân phối linux. PLC được kết nối với profinet master và profibus master.
- WinPC (192.168.192.200)
- Mạch ngoài PLC (192.168.192.202)
- Nic bên trong PLC (192.168.2.2)
- Chủ Profinet (192.168.2.3)
- Bậc thầy Profibus (192.168.2.4)
Điều gì sẽ hoàn toàn tuyệt vời, nếu chúng ta có thể mở một trình duyệt web trên PC Windows và kết nối với profibus master (trong đó PLC sẽ chỉ NAT các gói tới profibus master).
Tôi có quyền truy cập root trên PLC, vì vậy tôi nghĩ rằng tôi có thể quản lý việc này bằng cách sử dụng iptables
. Vì chúng tôi không quan tâm đến bảo mật, tôi đặt tất cả các chính sách để chấp nhận (INPUT, OUTPUT, FORWARD). Bước duy nhất sau đó tôi phải thực hiện (tôi ngây thơ ...) là NAT gói đến đích. Thật không may, nó không hoạt động.
đầu ra hiện tại của tôi về iptables -S
root@axcf3152:/opt/plcnext/# iptables -S
-P CHẤP NHẬN ĐẦU VÀO
-P CHẤP NHẬN VỀ PHÍA TRƯỚC
-P CHẤP NHẬN ĐẦU RA
và bảng tự nhiên của tôi
root@axcf3152:/opt/plcnext/# iptables -t nat -L
PREROUTING chuỗi (CHẤP NHẬN chính sách)
đích prot opt nguồn đích
DNAT icmp -- bất cứ đâu tới:192.168.2.4
DNAT tcp -- bất cứ đâu bất cứ đâu tcp dpt:6666 tới:192.168.2.4:443
DNAT tcp -- bất cứ đâu bất cứ đâu tcp dpt:5555 tới:192.168.2.3:443
DNAT tcp -- bất cứ đâu bất cứ đâu tcp dpt:4444 tới:192.168.2.3:80
DNAT tcp -- bất cứ đâu bất cứ đâu tcp dpt:3333 tới:192.168.2.4:80
DNAT tcp -- bất cứ đâu bất cứ đâu tcp dpt:6666 tới:192.168.2.4:443
Vì vậy, về cơ bản, tất cả những gì tôi đã làm ngoài việc đặt tất cả các chính sách thành CHẤP NHẬN là thêm một vài quy tắc cho nat:
iptables -t nat -A PREROUTING -p tcp --dport 6666 -j DNAT --to-destination 192.168.2.4:443
Và sau đó cho cả hai hương vị (http (80), https (443)) và cho cả profinet master (192.168.2.3) và profibus master (192.168.2.4)
Nếu tôi hiểu tất cả những gì tôi đọc về iptables tối nay thì tôi không cần bận tâm đến việc thêm các quy tắc cho bảng bộ lọc 'TIẾP TỤC' vì tôi chấp nhận mọi thứ (rất không an toàn, nhưng chúng tôi không quan tâm đến thiết lập thử nghiệm này).
Điều duy nhất tôi không chắc chắn là liệu (hoặc khi nào) tôi cũng cần thực hiện POSTROUTING.
Dù sao, khi tôi mở trang web https://192.168.192.202:6666 hoặc bất kỳ hương vị nào của nó, trang không thể tải (kết nối bị từ chối).
Mọi sự trợ giúp sẽ rất được trân trọng!!
CẬP NHẬT:
ban hành các lệnh sau để tôi ping profibus master (TÔI NGHĨ)
iptables -A INPUT -p icmp --icmp-type echo-request -j REJECT
iptables -t nat -A PREROUTING -p icmp -j DNAT --to-destination 192.168.2.4
iptables -t filter -A FORWARD -p icmp -d 192.168.2.4 -j CHẤP NHẬN
iptables -t nat -A POSTROUTING -j MASQUERADE
Bây giờ khi tôi ping trên PC Windows tới 192.168.192.202, tôi nhận được phản hồi. tôi cũng thấy iptables -t nat -L -v
tăng số liệu thống kê về quy tắc này (#packets + byte tăng khi tôi gửi lệnh ping mới).
Tôi nghĩ rằng điều này chứng tỏ rằng chủ profinet đang trả lời ping (vì hiện tại tôi từ chối icmp trên chính PLC)
câu hỏi:
- Tôi có cần quy tắc FORWARD không? Hay giả định của tôi là đúng rằng tôi đang cho phép mọi thứ và quy tắc này có dư thừa không?
- Tôi có cần thêm MASQUARADE không? Tôi vẫn gặp khó khăn để hiểu điều này thực sự làm gì (cũng như nhiều người khác có vẻ như do số lượng câu hỏi có trên web)
- Có điều gì còn thiếu trong thử nghiệm iptables của tôi có thể giải thích tại sao https không được chuyển tiếp không? Hoặc mọi thứ có ổn không và vấn đề có nằm ở tổng thể profibus thực tế không (không lưu trữ máy chủ web ở đó như tuyên bố của nhà cung cấp, ví dụ:)
CẬP NHẬT2:
Quy tắc icmp thỉnh thoảng hoạt động. Khi tôi xóa tất cả các quy tắc khỏi iptables và cố gắng thực hiện lại các bước, không phải lúc nào tôi cũng làm việc. iptables khó hơn tôi nghĩ ...