Ảo hóa pfSense 2.0.1 ảnh hưởng đến kết nối máy chủ Hyper-V? arp?


8

Cài đặt

Tôi đã thiết lập pfSense 2.0.1 (hình ảnh 64 bit-amd) làm máy chủ lưu trữ trong Hyper-V. Như được mô tả trong các blog khác, tôi đã phải thực hiện các if ifconfig xuống deX,, if ifconfig lên deXiến để có được mạng và chạy.

Máy chủ (HP chạy Windows 2008 R2) được trang bị hai NIC vật lý.

  • NIC vật lý đầu tiên (cổng 1) không được cấu hình trong máy chủ (chỉ khi chuyển đổi Hyper-V, xem thêm xuống).

  • NIC vật lý thứ hai (cổng 2) được cấu hình với một mạng để quản lý từ xa (mạng lớp C tiêu chuẩn). Tôi nghĩ rằng cả hai NIC được kết nối với cùng một công tắc và Vlan = mặc định (hệ thống dây vật lý được thực hiện bởi nhà cung cấp cùng vị trí của tôi).

Trong Hyper-V có các mạng ảo được định nghĩa sau:

  • Internal : mạng nội bộ của máy ảo được sử dụng để liên lạc giữa các máy ảo (LAN LAN Kết nối các máy chủ Windows).

  • Internet : mạng ảo được sử dụng làm kết nối WAN cho pfSense. Mạng này được gán cho NIC vật lý đầu tiên (cổng 1) của máy chủ. Mạng ảo được dành riêng cho Hyper-V và không được chia sẻ với máy chủ.

Trong thiết lập của mình, tôi sử dụng pfSense làm tường lửa đối mặt với Internet cho một vài máy ảo (máy chủ Windows) cũng chạy trên cùng máy chủ Hyper-V.

Các hộp Windows sử dụng pfSense làm cổng mặc định và tôi đã tải xuống thành công các bản cập nhật Windows cho tất cả các máy ảo thông qua tường lửa pfSense - hoạt động trơn tru.

Để định hướng lại các dịch vụ đến, pfSense được thiết lập với 1-1 NAT để ánh xạ các địa chỉ IP của ISP sang địa chỉ nội bộ 172.16.0.0/16 trên các hộp Windows.

Vấn đề

Vấn đề tôi gặp phải là sau khi làm việc thành công với kết nối RDP qua mạng quản lý (cổng 2), kết nối chỉ bị chết và tất cả kết nối mạng bị mất cho máy chủ và VM. Trước khi sự cố xảy ra tôi đã thực hiện hai thay đổi cấu hình.

  1. Đã chuyển địa chỉ IP quản lý từ cổng 1 sang cổng 2. Thay đổi này đã được xác minh thành công bằng cách kết nối lại RDP một giờ sau trên giao diện mới (cổng 2 như mô tả ở trên).

  2. Đã thực hiện một số cấu hình trên các IP ảo trong pfSense (cần thiết cho NAT 1-1).

Vài phút sau, kết nối với máy bị mất.

Điều khiến tôi băn khoăn là kết nối mạng quản lý (cổng 2) được cho là không được Hyper-V xử lý vì nó không được tích hợp với Hyper-V. Tuy nhiên, dường như có sự lan truyền lỗi từ pfSense (sử dụng NIC trên cổng 1).

Đầu ngày hôm nay, chúng tôi đã gặp một vấn đề tương tự khi chỉ sử dụng một NIC (cổng 1 được chia sẻ giữa Hyper-V / pfSense và máy chủ). Vấn đề chúng tôi gặp phải là khi pfSense bị dừng, chúng tôi có thể ping máy chủ và khi nó được khởi động lại, ping ngừng hoạt động (không có xung đột IP như chúng tôi biết).

PfSense được cài đặt từ ISO và giả mạo Địa chỉ MAC MAC là default = off.

Vì đường may vấn đề lan truyền giữa hai cổng vật lý, tôi đoán rằng điều này có thể có liên quan đến ARP không hoạt động chính xác.

Bất kỳ ý kiến ​​hiểu biết về điều này rất nhiều đánh giá cao.

/ J


Bạn đã làm một công việc thần giải thích vấn đề. Nhưng bạn không nói những gì bạn đã thay đổi. Bạn có thể liệt kê các địa chỉ IP thực tế (hoặc bị xáo trộn) được sử dụng làm IP ảo và quản lý và các thay đổi thực tế được thực hiện ở phần 1 và # 2 không?
Andy Shinn

Bạn đang gỡ lỗi này cục bộ (cùng một chuyển đổi cho máy chủ và máy khách của bạn)? Tôi đang hỏi bởi vì bạn có thể giả sử pfSense / Hyper-V là nguồn gốc của vấn đề khi thực tế nó có thể là tường lửa / proxy ở đâu đó hết hạn kết nối trạng thái của bạn. Cố gắng càng gần càng tốt với máy chủ này và để tcpdump và Wireshark chạy trên pfSense và Windows, sau đó kiểm tra xem điều gì đang xảy ra. Ngoài ra, vì bạn đã tráo đổi các giao diện, hãy kiểm tra kỹ mọi thứ trong công tắc ảo của Hyper-V.
Giovanni Tirloni

Bạn đã kích hoạt chế độ lăng nhăng trên giao diện ảo? bạn sẽ cần kích hoạt điều đó cho tường lửa: Theo mặc định, bộ điều hợp mạng ảo của hệ điều hành khách chỉ nhận các khung dành cho nó. Việc đặt bộ điều hợp mạng của khách ở chế độ lăng nhăng sẽ khiến nó nhận được tất cả các khung được truyền trên công tắc ảo được cho phép theo chính sách Vlan cho nhóm cổng liên kết. Điều này có thể hữu ích cho giám sát phát hiện xâm nhập hoặc nếu một sniffer cần phân tích tất cả lưu lượng truy cập trên phân khúc mạng.
MrLightBulp

Câu trả lời:


1

Bạn đã kiểm tra Trình xem sự kiện trên W2008R2 chưa?

Có thể là do các kết nối TCP tối đa được Windows cho phép: https://technet.microsoft.com/en-us/l Library / cc759700% 28WS.10% 29.aspx

pfSense như một bộ định tuyến phần mềm sử dụng rất nhiều kết nối có thể được mở nhưng không được đóng, trạng thái chờ đợi, v.v. Loại sử dụng mạng này có thể đạt được các giới hạn mặc định của ngăn xếp TCP và các cửa sổ có thể đóng hoặc không cho phép nhiều kết nối loại này. Điều đầu tiên cần làm trong trường hợp này là kiểm tra Trình xem sự kiện để xem có gì đó được báo cáo ở đó không.


Bạn có thể mở rộng về câu trả lời này?
BE77Y

pfSense như một bộ định tuyến phần mềm sử dụng rất nhiều kết nối có thể được mở nhưng không được đóng, trạng thái chờ đợi, v.v. Loại sử dụng mạng này có thể đạt được các giới hạn mặc định của ngăn xếp TCP và các cửa sổ có thể đóng hoặc không cho phép nhiều kết nối loại này. Điều đầu tiên cần làm trong trường hợp này là kiểm tra Trình xem sự kiện để xem có gì đó được báo cáo ở đó không.
NetVicy 17/2/2015

Đánh giá cao - nhưng nó sẽ hữu ích nhất khi thêm vào câu trả lời của bạn ở trên. :)
BE77Y

0

Điều này nghe có vẻ giống như sự cố định tuyến giữa pfSense và các thiết bị khác ...

Nếu bạn đang sử dụng Máy ảo phía sau pFSense làm tường lửa, tuy nhiên bạn cần chúng trên SubNet khác với PC trên mạng. Bạn có thể phải bật giao diện bổ sung trên pfSense (LAN2 nói) Sau đó ánh xạ nó trong Máy chủ VM tới một VSwitch riêng mà các máy ảo khác đang sử dụng .. Hoặc thậm chí TAG lưu lượng trong vSwitch và tách riêng vlan cho nó.

Tôi đã phải làm điều này nhiều lần trên VMWare. Ngoài ra, đối với tỷ lệ 1: 1 của bạn, bạn có thể phải thêm ánh xạ tuyến mạng tĩnh cho những ví dụ này. Tôi đã thấy pfSe nse bị rối loạn định tuyến.

Bằng cách đó bạn có ..

IINTERNET -> Wan0 -> pFSense -> PC LAN1 ..

                  pfSense -->LAN2 Virtual Machines.

Sau đó, bạn có thể kiểm soát các quy tắc định tuyến và tường lửa tốt hơn.

Hy vọng điều này sẽ giúp, Chúc mừng ...

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.