Tại sao nhiều tổ chức không sử dụng NAT từ trong ra ngoài hoặc các giải pháp tương tự để cho phép kẹp tóc NAT?

NAT từ trong ra ngoài hay còn gọi là NAT loopback giải quyết các vấn đề về NAT kẹp tóc khi truy cập máy chủ web trên giao diện bên ngoài của ASA hoặc thiết bị tương tự từ các máy tính trên giao diện bên trong. Điều này ngăn quản trị viên DNS không phải duy trì vùng DNS nội bộ trùng lặp có địa chỉ RFC1918 tương ứng cho các máy chủ của họ được NAT thành địa chỉ công cộng. Tôi không phải là kỹ sư mạng, vì vậy tôi có thể đang thiếu một cái gì đó, nhưng điều này có vẻ như không có trí tuệ để cấu hình và thực hiện. Định tuyến không đối xứng có thể là một vấn đề nhưng dễ dàng giảm nhẹ.

Theo kinh nghiệm của tôi, các quản trị viên / kỹ sư mạng thích rằng mọi người trong hệ thống chỉ chạy split-dns hơn là cấu hình tường lửa của họ để xử lý đúng các kẹp tóc NAT. Tại sao lại thế này?

Có một vài lý do tại sao tôi sẽ không làm điều đó:

• Tại sao phải đặt thêm căng thẳng vào các bộ định tuyến và tường lửa DMZ nếu bạn không cần? Hầu hết các dịch vụ nội bộ của chúng tôi không nằm trong DMZ mà là khu vực chung của công ty, với các dịch vụ ủy quyền trong DMZ để thỉnh thoảng truy cập từ xa. Việc thực hiện từ bên trong đến bên trong sẽ tăng thêm tải cho DMZ, trong trường hợp của chúng tôi sẽ rất quan trọng.
• Nếu bạn không thực hiện DNAT + SNAT, bạn sẽ nhận được định tuyến không đối xứng, điều này nổi tiếng là khó khăn để có được quyền. Vì vậy, bạn SNAT và mất thông tin IP nguồn. Tuy nhiên, rất hữu ích khi liên kết IP nguồn với mọi người cho mục đích khắc phục sự cố. Hoặc đôi khi mục đích nerfshoot trong trường hợp ngu ngốc. "Này IP này đang làm một cái gì đó mạnh mẽ trên dịch vụ không được xác thực X" "Ồ, chúng ta hãy xem trong máy chủ imap ghi nhật ký đó là ai".

Rõ ràng, không thể có câu trả lời chắc chắn cho điều này, nhưng tôi có thể nghĩ ra một số lý do:

1. Sự thanh lịch: NAT không phải là rất thanh lịch để bắt đầu, nhưng sự cần thiết với không gian địa chỉ bị hạn chế của IPv4. Nếu tôi có thể tránh NAT, tôi sẽ làm. Với IPv6, vấn đề sẽ không còn nữa.
2. Độ phức tạp: đặc biệt trong trường hợp bạn không chỉ có một bộ định tuyến "lõi" duy nhất tạo ra tất cả các ranh giới bảo mật của mình, cấu hình bộ lọc có thể trở nên khá khó khăn. Dù vậy hoặc bạn sẽ phải truyền bá và duy trì các quy tắc NAT trên hầu hết các thiết bị định tuyến của mình.
3. Tham khảo: bất cứ nơi nào quản trị viên tường lửa là những người khác nhau so với phần còn lại của nhóm quản trị viên máy chủ, họ có thể khó tiếp cận. Để đảm bảo các thay đổi không bị trì hoãn bởi tồn đọng (hoặc kỳ nghỉ) của quản trị viên tường lửa, tùy chọn giữ trách nhiệm trong cùng một nhóm được chọn
4. Tính di động và thực tiễn phổ biến: Sử dụng chế độ xem DNS là "chỉ là điều mọi người biết đã hoàn thành" để giải quyết vấn đề này. Không phải mọi bộ định tuyến ranh giới đều hỗ trợ NAT loopback theo cách đơn giản, ít người có khả năng biết cách thiết lập chính xác trong môi trường cụ thể của bạn. Khi khắc phục sự cố mạng, phi hành đoàn sẽ cần biết về cấu hình NAT của kẹp tóc và tất cả các tác động của nó - ngay cả khi họ đang theo đuổi một vấn đề rõ ràng không liên quan

Tuyên bố từ chối trách nhiệm - đây là một câu trả lời flamebait.

Một lý do phổ biến tôi nghĩ rằng các giải pháp như thế này được tránh là nỗi sợ / sự căm ghét phi lý của NAT đối với các kỹ sư mạng . Nếu bạn muốn xem một số ví dụ về thảo luận về điều này, hãy xem những điều sau:

• http://packetpushers.net/show-86-connect-to-the-ipv6-iNET-for-free-USE-tunnelbroker-net/
• http://networkingnerd.net/2012/04/02/ipv6-nat-and-the-sme-a-response/ (Blog của Tom dường như tiếp tục thu hút thảo luận NAT / IPv6 khá sôi nổi)
• http://libertysys.com.au/blog/nat-is-evil-but-not-bad (blog của tôi)

Từ những gì tôi có thể nói, rất nhiều nỗi sợ hãi này bắt nguồn từ việc triển khai NAT kém của Cisco (vì vậy theo nghĩa đó có thể không phải là phi lý), nhưng theo tôi, kỹ sư mạng "cổ điển" này được đào tạo rất tốt trong "NAT là thế giới quan xấu, rằng anh ấy hoặc cô ấy không thể nhìn thấy những ví dụ rõ ràng như thế này, nơi nó có ý nghĩa hoàn hảo và thực sự đơn giản hóa giải pháp.

Có bạn đi - downvote cho nội dung trái tim của bạn! :-)

Tôi đoán là:

1. Split DNS dễ hiểu hơn.
2. NAT Hairpin sử dụng hết tài nguyên trên bộ định tuyến trong khi split-dns thì không.
3. Bộ định tuyến có thể có các giới hạn băng thông mà bạn không có được thông qua thiết lập split-dns.
4. Split-dns sẽ luôn hoạt động tốt hơn khi bạn tránh các bước định tuyến / NAT.

Về mặt tích cực cho kẹp tóc NAT,

• Khi thiết lập xong, nó chỉ hoạt động.
• Không có vấn đề với bộ đệm DNS cho máy tính xách tay di chuyển giữa mạng công việc và internet công cộng.
• DNS cho một máy chủ chỉ được quản lý ở một nơi.

Đối với một mạng nhỏ có yêu cầu lưu lượng truy cập thấp đến máy chủ nội bộ, tôi sẽ sử dụng NAT kẹp tóc. Đối với một mạng lớn hơn có nhiều kết nối đến máy chủ và trong đó băng thông và độ trễ là quan trọng, hãy đi với split-dns.

Từ quan điểm của tôi, điều này đã thay đổi một chút giữa quá trình chuyển đổi Cisco Pix sang ASA. Mất aliaslệnh. Và nói chung, việc truy cập địa chỉ bên ngoài từ giao diện bên trong trên tường lửa của Cisco đòi hỏi một số mánh khóe. Xem: Làm thế nào để tôi truy cập máy chủ nội bộ của mình trên IP bên ngoài?

Tuy nhiên, chúng tôi không cần phải duy trì một vùng DNS nội bộ trùng lặp. Cisco ASA có thể chuyển hướng truy vấn DNS cho địa chỉ bên ngoài sang địa chỉ nội bộ nếu được định cấu hình trên câu lệnh NAT. Nhưng tôi thích giữ một vùng bên trong cho vùng DNS công cộng để có độ chi tiết đó và có thể quản lý vùng này ở một nơi thay vì bước vào tường lửa.

Thông thường, chỉ có một vài máy chủ có thể yêu cầu điều này trong một môi trường (thư, web, một vài dịch vụ công cộng), vì vậy nó không phải là một vấn đề to lớn.

Tôi có thể nghĩ ra một vài lý do:

1. Nhiều tổ chức đã phân tách DNS do không muốn công bố tất cả thông tin DNS nội bộ của họ ra thế giới, do đó, không có nhiều nỗ lực để xử lý một số máy chủ cũng bị lộ thông qua IP công cộng.
2. Khi một tổ chức và mạng của nó phát triển lớn hơn, họ thường tách các hệ thống phục vụ người bên trong khỏi các máy chủ phục vụ bên ngoài, do đó việc định tuyến đến các bên ngoài để sử dụng nội bộ có thể là một đường dẫn mạng dài hơn nhiều.
3. Càng ít sửa đổi mà các thiết bị trung gian thực hiện đối với các gói, thì càng tốt khi nói đến độ trễ, thời gian đáp ứng, tải thiết bị và xử lý sự cố.
4. (rất nhỏ, phải thừa nhận) Có các giao thức mà NAT vẫn sẽ phá vỡ nếu thiết bị NAT không vượt quá tiêu đề của gói và sửa đổi dữ liệu trong đó bằng địa chỉ IP mới. Ngay cả khi đó chỉ là một trường hợp của bộ nhớ tổ chức, đó vẫn là một lý do hợp lệ để mọi người tránh nó, đặc biệt nếu họ đang xử lý một giao thức mà họ không chắc chắn 100%.

Nếu tôi định sử dụng NAT loopback, tôi sẽ hơi lo lắng về cách thiết bị NAT sẽ xử lý các địa chỉ nguồn giả mạo. Nếu nó không kiểm tra giao diện nào gói đến, thì tôi có thể giả mạo địa chỉ nội bộ từ mạng WAN và gửi gói đến máy chủ có địa chỉ nội bộ. Tôi không thể nhận được trả lời, nhưng tôi có thể thỏa hiệp máy chủ bằng địa chỉ nội bộ.

Tôi sẽ thiết lập NAT loopback, cắm vào bộ chuyển đổi DMZ và gửi các gói với các địa chỉ nguồn nội bộ giả mạo. Kiểm tra nhật ký máy chủ để xem nếu chúng đã được nhận. Sau đó, tôi sẽ đến quán cà phê và xem ISP của tôi có chặn các địa chỉ giả mạo hay không. Nếu tôi thấy bộ định tuyến NAT của mình không kiểm tra giao diện nguồn, có lẽ tôi sẽ không sử dụng NAT loopback ngay cả khi ISP của tôi đang kiểm tra.