Phát hiện cổng chết trên Windows 2008 Server

9

Gần đây chúng tôi đã triển khai HAProxy cho stackoverflow.com. Chúng tôi đã quyết định sử dụng TProxy để duy trì địa chỉ nguồn cho các máy khách kết nối để nhật ký của chúng tôi và các mô-đun IIS khác phụ thuộc vào địa chỉ IP của máy khách sẽ không yêu cầu sửa đổi. Vì vậy, các gói đến giả mạo như thể chúng đến từ một địa chỉ IP internet bên ngoài, trong khi thực tế chúng đến từ một IP HAProxy 192.168.xx trên mạng cục bộ của chúng tôi.

Cả hai máy chủ web của chúng tôi đều có hai NIC - một địa chỉ lớp B có thể định tuyến trên internet công cộng có IP tĩnh, DNS và cổng mặc định và một địa chỉ lớp C riêng không thể định tuyến được định cấu hình với một cổng mặc định được trỏ đến IP riêng cho HAProxy. HAProxy có hai giao diện - một công khai và một riêng tư và thực hiện công việc định tuyến các gói trong suốt giữa các giao diện và hướng lưu lượng truy cập đến máy chủ web thích hợp.

Bộ điều hợp Ethernet Internet:

   Sự miêu tả . . . . . . . . . . . : card mạng số 1
   Đã bật DHCP. . . . . . . . . . . : Không
   Tự động cấu hình kích hoạt. . . . : Đúng
   Địa chỉ IPv4. . . . . . . . . . . : 69.59.196.217 (Ưu tiên)
   Mặt nạ mạng con. . . . . . . . . . . : 255.255.255.240
   Gateway mặc định . . . . . . . . . : 69,59.196.209
   Máy chủ DNS. . . . . . . . . . . : 208,67.222.222
                                       208,67.220.220
   NetBIOS trên Tcpip. . . . . . . . : Đã bật

Bộ điều hợp Ethernet Riêng tư cục bộ:

   Sự miêu tả . . . . . . . . . . . : card mạng số 2
   Đã bật DHCP. . . . . . . . . . . : Không
   Tự động cấu hình kích hoạt. . . . : Đúng
   Địa chỉ IPv4. . . . . . . . . . . : 192.168.0.2 (Ưu tiên)
   Mặt nạ mạng con. . . . . . . . . . . : 255.255.255.0
   Gateway mặc định . . . . . . . . . : 192.168.0.50
   NetBIOS trên Tcpip. . . . . . . . : Đã bật

Chúng tôi đã vô hiệu hóa các số liệu tự động trên mỗi máy chủ web và chỉ định lớp B công khai có thể định tuyến là số liệu 10 và giao diện riêng của chúng tôi là số liệu 20.

Chúng tôi cũng đã thiết lập cả hai khóa đăng ký này:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"DeadGWDetectDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"EnableDeadGWDetect"=dword:00000000

Khoảng hai lần mỗi ngày, chúng tôi thấy các sự cố trong đó một trong các máy chủ web không thể liên hệ với DNS hoặc thực hiện kết nối với bất kỳ máy chủ nào khác trên internet công cộng.

Chúng tôi nghi ngờ phát hiện cổng chết là phát hiện sai sự cố trên cổng công cộng và đang chuyển tất cả lưu lượng truy cập sang cổng riêng không có quyền truy cập DNS tại thời điểm này nhưng không có cách nào để xác minh điều này.

Có cách nào để biết liệu phát hiện cổng chết đang chạy hay thậm chí là một tùy chọn trong máy chủ Windows 2008 không?
Nếu vậy, có cách nào để vô hiệu hóa phát hiện cổng chết trong máy chủ Windows 2008 không?
Nếu không, có thể có những lý do nào khác khiến chúng ta mất khả năng phân giải DNS hoặc kết nối trong một thời gian ngắn?

— Geoff Dalgas
nguồn

1

Mặc dù thiết lập này đôi khi được tán thành (xem blog.technet.com/timmcmic/archive/2009/04/26/ ,), nó hoạt động rất tốt đối với chúng tôi - tất cả lưu lượng truy cập từ HAProxy đến các trang IIS của chúng tôi dường như vẫn đến từ địa chỉ IP gốc. Điều này giúp tiết kiệm lượng thời gian chưa sử dụng, vì chúng ta phải (tìm hiểu cách) định cấu hình IIS và vô số trình cắm của nó để sử dụng tiêu đề HTTP_X_FORWARDED_FOR.

— Jarrod Dixon

1

Tại sao bạn có một cổng được cấu hình trên giao diện 192.168.0.2? Bạn có thể định cấu hình một cổng mặc định trống (và thực tế đây là những gì Windows nhắc bạn làm khi bạn có hai giao diện).

— Portman

@Portman - vì các hộp web của chúng tôi đang thấy lưu lượng truy cập với IP khách hàng ban đầu còn nguyên vẹn, các phản hồi sẽ không được gửi đến mạng của chúng tôi - đó là lý do tại sao chúng tôi phải có một cổng mặc định vào hộp HAProxy của chúng tôi.

— Jarrod Dixon

@Jarrod - cấu hình đó có vẻ đáng ngờ. Còn nếu bạn muốn chạy một trang web không cân bằng trên máy chủ web đó thì sao? Phản ứng sẽ được chuyển qua HAProxy? Làm thế nào bạn sẽ xử lý một cái gì đó như máy tính để bàn từ xa? Tôi nhận ra điều này không giải quyết được câu hỏi, nhưng có vẻ như đây là trường hợp của You're It It Wrong, đó là những gì daivdsmalley đang nói (một cách lịch sự).

— Portman

4

@ Jeff / Geoff / Jarrod - Tôi ghét phải nói rõ ràng, nhưng các bạn là nhà phát triển phần mềm, tại sao không thuê một người chuyên gia trong một ngày để sửa chữa? Tất cả đều rất tốt để làm bẩn tay bạn nhưng có một lỗ hổng kiến thức rõ ràng ở đây, nó ảnh hưởng không ngừng đến doanh nghiệp và rõ ràng bạn đã dành một chút thời gian quý báu để không sử dụng các kỹ năng cốt lõi của mình là phát triển. Tin tôi đi, nhờ ai đó sửa chữa và sau đó chọn bộ não của anh ấy / cô ấy sau khi bạn làm việc. Chết tiệt, ngay cả khi các nhà cung cấp web, chúng ta cần phải có người để thu hẹp những khoảng trống này khi nó ảnh hưởng đến nhiệm vụ / dịch vụ quan trọng.

— Kev

5

Các DWORD phát hiện cổng chết đó là vô dụng trên Windows Server 2008. Lý do duy nhất chúng tồn tại là vì lý do tương thích. Trình điều khiển TCP / IP và các thành phần bộ định tuyến Windows không tìm kiếm các giá trị này nữa.

Tôi nghi ngờ tính năng này đã được đưa vào Auto-Tune, được ra mắt trong Windows Vista. Hãy thử thực hiện các thao tác sau trong dấu nhắc lệnh nâng cao (và khởi động lại):

Netsh int tcp thiết lập autotuninglevel toàn cầu = bị vô hiệu hóa

Cập nhật ( đã thêm ngày 13 tháng 9 năm 2009 @ 7: 58pm EST )

Nếu điều đó không làm việc, chúng tôi sẽ cần thêm đầu ra chẩn đoán. Bắt đầu theo dõi (vòng tròn) với các kịch bản NetConnection hoặc LAN và để nó tiếp tục chạy cho đến khi sự cố xảy ra.

kịch bản bắt đầu theo dõi Netsh = NetConnection maxSize = 512

_{(Ví dụ: Bắt đầu kịch bản theo dõi NetConnection, với kích thước nhật ký theo dõi tối đa là 512MB)}

Bạn có thể mở theo dõi kết quả trong Network Monitor 3.3 , chỉ cần đảm bảo bạn cài đặt các trình phân tích cú pháp mới nhất .

— Rafael Rivera
nguồn

ý tưởng tốt, nhưng dường như cũng không hoạt động .. vừa trải qua một lần mất lưu lượng truy cập 5 phút - điều này đã tự khắc phục một cách bí ẩn.

— Jeff Atwood

@Jeff: Hmm, chúng tôi cần thêm dữ liệu Thuyền trưởng! Xem chỉnh sửa ở trên.

— Rafael Rivera

5

Chúng tôi không thể đi đến một kết quả cuối cùng về lý do tại sao chúng tôi không thể kiểm soát hành vi của Phát hiện Cổng chết.

Thay vì mất rất nhiều thời gian để khắc phục sự cố này, chúng tôi đã chọn đặt lưu lượng truy cập tuyến HAProxy của mình sang cổng ra bên ngoài và đặt cổng mặc định của cả hai máy chủ thành IP của haproxy và xóa địa chỉ cổng bên trong.

  [ soweb1 ] 69.59.196.220, GW=69.59.196.211 [haproxy]
       |
       +---- [haproxy] 69.59.196.211, GW 69.59.196.209
       |
    [ gw ] 69.59.196.209

Bây giờ chỉ có một cổng mặc định loại bỏ sự cố của chúng tôi vì phát hiện cổng mặc định đã chết không còn được sử dụng.

— Geoff Dalgas
nguồn

4

Tôi sẽ hỏi tại sao bạn thậm chí cần phải thay đổi cổng mặc định thành HAproxy. Nói chung, bạn hoàn toàn không nên thay đổi cổng mặc định của mình trừ khi bạn trỏ nó vào thiết lập N + 1 có tính khả dụng cao trong đó IP cổng có thể chuyển sang bộ định tuyến / máy khác trong trường hợp có điều gì đó xấu xảy ra. Nếu có điều gì đó xảy ra với máy HAproxy của bạn và bạn không có quyền truy cập ngoài băng, thì các máy chủ web sẽ ngừng truy cập internet.

Vì tôi tin rằng lý do bạn có thể làm điều này là do bạn đang sử dụng Tproxy trong thiết lập của mình để làm cho địa chỉ IP của máy khách xuất hiện trong nhật ký của bạn chứ không phải IP của máy chủ proxy, tôi có thể đề nghị bạn làm điều này thay thế

Thêm "tùy chọn chuyển tiếp ..." vào cấu hình HAproxy của bạn
Cài đặt bộ lọc x-chuyển tiếp-cho ISAPI
Xóa tproxy khỏi thiết lập của bạn
Thay đổi cổng mặc định trở lại cùng một cổng bạn đang sử dụng trước đây bằng kết nối trực tiếp internet

Tôi không có máy Windows để kiểm tra điều này nhưng tôi tin rằng nó sẽ mang lại hiệu quả mong muốn mà không bị mất kết nối không mong muốn.

— davidsmalley
nguồn

Tôi chỉ phát hiện ra nhận xét của bạn về câu hỏi ban đầu liên quan đến thiết lập này. Tuy nhiên, tôi sẽ nghi ngờ "nó hoạt động khủng khiếp đối với chúng tôi" nếu máy chủ của bạn mất kết nối internet :)

— davidsmalley

3

Ngoài ra, bạn có thể xem xét một giải pháp mạnh mẽ hơn nhiều như ldirectord + heartbeat chỉ chuyển hướng lưu lượng ở cấp hạt nhân, vì vậy không có sự ủy quyền nào cả. Tôi sử dụng thiết lập này rộng rãi và nó hoạt động tuyệt vời. linuxvirtualserver.org/docs/ha/lovebeat_ldirectord.html

— davidsmalley

Chúng tôi đã xem xét việc sử dụng x-forwarded-forbộ lọc tiêu đề và IIS đó để thay đổi nhật ký, nhưng chúng tôi không biết làm thế nào (hoặc nếu) các mô-đun IIS tùy chọn khác của chúng tôi cũng sử dụng tiêu đề trong hoạt động của chúng.

— Jarrod Dixon

Cảm ơn vì liên kết linuxvirtualserver.org/HighAvcellence.html - thông tin ở đó thật tuyệt vời! Tôi không biết gì về những môn học này (đó là lý do tại sao tôi không phải là người sắp đặt tất cả những điều này!), Nhưng tôi đang cố gắng học càng nhanh càng tốt. Có lẽ chúng ta có thể sử dụng heartbeat + ldirectord tương tự như cách linuxvirtualserver.org/docs/ha/ultramonkey.html thực hiện điều đó với HAProxy yêu thích của chúng ta.

— Jarrod Dixon

-1

Khi truy cập internet có liên quan (thường) thì các cổng mặc định chỉ nên được sử dụng để biểu thị đường dẫn đến INTERNET. Nếu bạn có nhiều cổng mặc định được xác định, bộ định tuyến HĐH không thể quyết định sử dụng cổng nào và nếu một cổng mặc định chỉ xuống một cổng thông tin (ví dụ: mạng LAN nhiều phân đoạn của bạn) thì các gói được chuyển tiếp tới đó cho internet sẽ không làm cho nó.

— Adrien
nguồn