các sự cố NAT lạ với pfSense đối với VM lang thang

Điều này đã làm tôi bối rối:

Tôi có một tường lửa pfSense (hãy gọi nó là pfs) và đằng sau nó là một số máy chủ. Tôi NAT một số dịch vụ từ IP công cộng của mình đến các máy chủ khác nhau trên mạng LAN mà không gặp sự cố nào.

Trên một trong các máy chủ (hãy gọi nó là s1) Tôi đang chạy một lang thang (với libvirt) VM (hãy gọi nó là v1) với một công cộng mạng được cấu hình, nhận IP 192.168.1.159 qua pfsmáy chủ DHCP.

Bây giờ tôi cấu hình một NAT đơn giản trên pfs để truy cập s1's SSH, nói <wan>:6622 -> s1:22 và truy cập nó trên mydomain.com:6622. Không vấn đề gì.

Tôi cũng có thể truy cập v1:22 (hoặc tương đương 192.168.1.159:22) với người dùng ssh hợp lệ từ trong mạng LAN không có vấn đề.

Bây giờ tôi thêm một NAT đơn giản vào pfs, Nói <wan>:6722 -> v1:22. Bây giờ cố gắng truy cập mydomain.com:6722 không làm công việc?!

Mục tiêu là thêm cả "lớp khác": chạy các container có cổng công khai, ví dụ: --xuất bản 9980:80 trên v1 và truy cập chúng dưới dạng ví dụ: v1:9980 và từ mydomain.com:9980 với NAT tương ứng trên pfs Thích <wan>:9980 -> v1:9980. Từ mạng LAN điều này cũng hoạt động như mong đợi (tức là tôi có thể truy cập v1:9980 từ mạng LAN), nhưng NAT thông qua pfs không phải.

Tôi có các thiết lập tương tự hoạt động trong cùng một mạng trên các máy khác nhau mà không gặp sự cố. Tôi thậm chí còn có một người khác (không lang thang, nhưng cũng libvirt) VM bật s1 mà tôi có thể ssh qua NAT thông qua IP công cộng của mình một cách hoàn toàn ổn. Nhưng bằng cách nào đó ở trên không hoạt động với lang thang máy và tôi thực sự không biết điều gì có thể gây ra sự cố này. (FWIW tôi có net.ipv4.forward bật trên v1).

CHỈNH SỬA:

Tôi đã tiến gần hơn một bước: nếu tôi tấn công NIC hiện có đầu tiên của lang thang máy ảo sử dụng quản lý đức hạnhvà đặt VM thứ hai thành rtl8139 thay vì tài năng (và sau đó khởi động lại), tôi thua ssh lang thang khả năng nhưng NAT sau đó hoạt động. Vì vậy, câu hỏi sau đó trở thành: làm thế nào để cấu hình thông qua lang thang cung cấp sao cho chúng tôi có cấu hình tương tự, tôi cho rằng điều đó có nghĩa là mạng công cộng phải ở trên giao diện mặc định?

Dung dịch:

Nguyên nhân là do lang thang yêu cầu (và do đó định cấu hình) giao diện cục bộ của nó (mạng riêng) làm giao diện chính, không có phương thức tiêu chuẩn nào để ghi đè giao diện đó. (Một số thông tin là đây, nhưng lang thang mọi người thừa nhận rằng chính họ cũng bối rối trước chủ đề này...)

Một biến thể (mạnh mẽ hơn) trên khái niệm để điều chỉnh các tuyến đường mặc định đã mang lại giải pháp. tôi đang sử dụng một ansible nhà cung cấp, nơi tôi thực hiện các thao tác sau (đối với khách, thông qua playbook cung cấp):

  - tên: xóa tuyến đường mặc định sai trên eth0 (một lần nữa)
    vỏ: |
      eval $(route -n | awk '$0~/[.0]{4}/ && $3~/[.0]{4}/ && $8~/eth0/ { printf "ip route mặc định qua %s dev % s; ",$3,$8 }')

(điều thú vị là nó cần được thực thi hai lần (hoặc sau một thời gian?), có thể do mạng chưa hoạt động đầy đủ khi tập lệnh cung cấp bắt đầu?)

Điều này loại bỏ tuyến đường mặc định trên eth0 (các mạng công cộng sẽ chỉ được cấu hình tự động trên eth1 qua lang thang) và làm cho các kết nối bên ngoài hoạt động như mong đợi. Điều này có lẽ (suy đoán ở đây) do thực tế là các phản hồi đối với các yêu cầu NATed đến được định tuyến đến tường lửa thông qua tuyến đường mặc định trên eth0 theo mặc định (mà theo lang thang mặc định có mức ưu tiên), điều này gây nhầm lẫn cho NAT FW vì nó xuất hiện trên VM eth1. Vì vậy, loại bỏ eth0 làm câu trả lời mặc định cho các yêu cầu bên ngoài trên cùng một giao diện khi chúng xuất hiện.