it-swarm-vi.tech

Quay lại địa chỉ IP công cộng được chuyển tiếp từ mạng cục bộ - Kẹp tóc NAT

Đây là một Câu hỏi Canonical về Kẹp tóc NAT (Loopback NAT).

Hình thức chung của câu hỏi này là:

Chúng tôi có một mạng với các máy khách, một máy chủ và một NAT Bộ định tuyến. Có cổng chuyển tiếp trên bộ định tuyến đến máy chủ để một số dịch vụ của nó có sẵn ở bên ngoài. Chúng tôi có DNS trỏ đến bên ngoài IP. Máy khách mạng cục bộ không kết nối được, nhưng công việc bên ngoài.

  • Tại sao điều này thất bại?
  • Làm cách nào tôi có thể tạo sơ đồ đặt tên hợp nhất (tên DNS hoạt động cả cục bộ và bên ngoài)?

Câu hỏi này đã trả lời được hợp nhất từ ​​nhiều câu hỏi khác. Ban đầu, họ tham khảo FreeBSD, D-Link, Microtik và các thiết bị khác. Tuy nhiên, tất cả họ đều cố gắng giải quyết cùng một vấn đề.

46
adopilot

Thứ bạn đang tìm kiếm được gọi là "NAT kẹp tóc". Các yêu cầu từ giao diện bên trong cho một địa chỉ IP được gán cho giao diện bên ngoài phải được bỏ qua như thể chúng đến từ giao diện bên ngoài.

Tôi hoàn toàn không có bất kỳ sự quen thuộc nào của FreeBSD, nhưng đọc hướng dẫn "pf" cho OpenBSD ( http://www.openbsd.org/faq/pf/rdr.html ) các giải pháp được đề xuất của DNS chia đôi, sử dụng mạng DMZ hoặc TCP ủy quyền khiến tôi tin rằng "pf" không hỗ trợ NAT kẹp tóc.

Tôi sẽ xem xét việc đi theo con đường DNS phân chia và không sử dụng địa chỉ IP trong các URL bên trong mà thay vào đó, sử dụng tên.

16
Evan Anderson

Vì câu hỏi này đã được nâng lên thành câu hỏi chính tắc trên kẹp tóc NAT, tôi nghĩ rằng nó có lẽ nên có một câu trả lời có giá trị hơn so với câu hỏi hiện được chấp nhận, (mặc dù xuất sắc) liên quan cụ thể là FreeBSD.

Câu hỏi này áp dụng cho các dịch vụ được cung cấp bởi các máy chủ trên mạng IPv4 có địa chỉ RFC1918, được cung cấp cho người dùng bên ngoài bằng cách giới thiệu Destination NAT (DNAT) tại cổng. Người dùng nội bộ sau đó thử truy cập các dịch vụ đó thông qua địa chỉ bên ngoài. Gói tin của họ đi từ máy khách đến thiết bị cổng, ghi lại địa chỉ đích và ngay lập tức đưa nó trở lại mạng bên trong. Đây là lần quay đầu tiên của gói tạo ra tại cổng dẫn đến tên kẹp tóc NAT , bằng cách tương tự với lần lượt kẹp tóc .

Vấn đề phát sinh khi thiết bị cổng ghi lại địa chỉ đích, nhưng không phải địa chỉ nguồn. Sau đó, máy chủ sẽ nhận được một gói có địa chỉ đích bên trong (của chính nó) và địa chỉ nguồn bên trong (của máy khách); Nó biết nó có thể trả lời trực tiếp đến một địa chỉ như vậy, vì vậy nó làm như vậy. Vì câu trả lời là trực tiếp, nên nó không đi qua cổng, do đó không bao giờ có cơ hội cân bằng hiệu ứng của đích đến NAT trên gói ban đầu bằng cách viết lại địa chỉ nguồn của trả về gói.

Do đó, khách hàng gửi một gói đến một bên ngoài Địa chỉ IP, nhưng nhận được phản hồi từ một nội bộ Địa chỉ IP. Không có ý tưởng rằng hai gói là một phần của cùng một cuộc trò chuyện, vì vậy không có cuộc hội thoại nào xảy ra.

Giải pháp là đối với các gói yêu cầu NAT đích như vậy và đến cổng từ mạng nội bộ, để thực hiện nguồn NAT (SNAT) trên Gói gửi đến, thường bằng cách viết lại địa chỉ nguồn thành cổng. Máy chủ sau đó nghĩ rằng máy khách là cổng chính và trả lời trực tiếp cho nó. Điều đó tạo cho cổng một cơ hội để cân bằng các hiệu ứng của cả DNAT và SNAT trên gói gửi đến bằng cách viết lại cả địa chỉ nguồn và địa chỉ đích trên gói trả về.

Khách hàng nghĩ rằng nó đang nói chuyện với một máy chủ bên ngoài. Máy chủ nghĩ rằng nó đang nói chuyện với thiết bị cổng. Tất cả các bên đều hạnh phúc. Một sơ đồ có thể hữu ích tại thời điểm này:

enter image description here

Một số thiết bị cổng tiêu dùng đủ sáng để nhận ra các gói mà bước thứ hai NAT là cần thiết và những gói đó có thể sẽ hoạt động ngoài hộp trong kẹp tóc NAT. Những người khác không, và vì vậy sẽ không, và không chắc là họ có thể được thực hiện để làm việc. Một cuộc thảo luận về các thiết bị cấp tiêu dùng nào không phù hợp với Lỗi Máy chủ.

Các thiết bị mạng phù hợp thường có thể được yêu cầu hoạt động, nhưng - bởi vì chúng không phải là công việc đoán người quản trị thứ hai - chúng phải được bảo làm như vậy. Linux sử dụng iptables để thực hiện DNAT:

iptables -t nat -A PREROUTING  -p tcp --dport 80 -j DNAT --to-destination 192.168.3.11

sẽ cho phép DNAT đơn giản cho cổng HTTP, đến một máy chủ nội bộ trên 192.168.3.11. Nhưng để kích hoạt NAT kẹp tóc, người ta cũng cần một quy tắc như:

iptables -t nat -A POSTROUTING -d 192.168.3.11 -p tcp --dport 80 -j MASQUERADE

Lưu ý rằng các quy tắc như vậy cần được đặt đúng chỗ trong các chuỗi có liên quan để hoạt động chính xác và tùy thuộc vào cài đặt trong chuỗi filter, có thể cần các quy tắc bổ sung để cho phép lưu lượng truy cập NATted lưu chuyển. Tất cả các cuộc thảo luận như vậy nằm ngoài phạm vi của câu trả lời này.

Nhưng như những người khác đã nói, kẹp tóc kích hoạt đúng cách NAT không phải là cách tốt nhất để xử lý vấn đề. Cách tốt nhất là DNS chia đôi , trong đó tổ chức của bạn phục vụ các câu trả lời khác nhau cho tra cứu ban đầu tùy thuộc vào nơi khách hàng yêu cầu, bằng cách có các máy chủ vật lý khác nhau cho người dùng nội bộ so với người dùng bên ngoài hoặc bằng cách định cấu hình máy chủ DNS để phản hồi khác nhau theo địa chỉ của khách hàng yêu cầu.

49
MadHatter

Vấn đề ở đây là, bộ định tuyến của bạn không NAT địa chỉ máy khách nội bộ của bạn. Do đó, bắt tay TCP không thành công.

Giả sử IP sau

  • Khách hàng: 192.168.1.3
  • Máy chủ: 192.168.1.2
  • Bộ định tuyến bên trong: 192.168.1
  • Bộ định tuyến ngoài: 123.123.123.1

Đây là điều đang xảy ra:

  1. Máy khách (192.168.1.3) gửi TCP-SYN đến IP bên ngoài của bạn, Cổng 80 (123.123.123.1:80)
  2. Bộ định tuyến thấy quy tắc chuyển tiếp cổng và chuyển tiếp gói đến máy chủ (192.168.1.2:80) mà không thay đổi IP nguồn (192.168.1.3)
  3. Khách hàng chờ đợi một SYN-ACK từ IP bên ngoài
  4. Máy chủ gửi câu trả lời của anh ấy lại cho khách hàng trực tiếp, bởi vì nó nằm trên cùng một mạng con. Nó không gửi gói đến bộ định tuyến, điều này sẽ đảo ngược NAT.
  5. Khách hàng nhận được một SYN-ACK từ 192.168.1.2 thay vì 123.123.123.1. Và loại bỏ nó.
  6. Khách hàng vẫn chờ đợi một SYN-ACK từ 123.123.123.1 và hết thời gian.
9
PEra

Tại sao không sử dụng dns chia chân trời thay vì mã hóa địa chỉ IP ở mọi nơi? Bạn sẽ có ext.yourdomain trỏ đến 217.x.x.x ở bên ngoài và sau đó 192.x.x.x ở bên trong.

4
Ryaner

Nếu đó là bộ định tuyến D-Link gốc (nghĩa là, không phải Rev. D/Firmware Phiên bản 1.00VG từ Virgin Media), bạn sẽ có thể điều chỉnh các cài đặt để khắc phục điều này. (Tuy nhiên, tôi đồng ý với đề xuất của DD-WRT trước đây vì nhiều lý do khác!)

  1. Đăng nhập vào giao diện web của bộ định tuyến
  2. Nhấp vào tab Nâng cao ở trên cùng
  3. Nhấp vào tab Cài đặt tường lửa ở bên trái
  4. Nhấp vào nút radio Điểm cuối độc lập bên dưới Lọc điểm cuối TCP , như được hiển thị trong ảnh chụp màn hình bên dưới (hoặc xem trình giả lập bộ định tuyến tại trang web của D-Link)
  5. Lưu thay đổi; bạn đã hoàn tất

D-Link router web UI screenshot

Ảnh chụp màn hình này là từ mô hình Rev. C; của bạn có thể hơi khác nhau.

2
David

Gần đây đã trả lời một câu hỏi tương tự: Cisco static NAT không hoạt động ở phía LAN và chỉ nhận ra rằng đây là Câu hỏi Canonical. Vì vậy, hãy cho phép tôi tóm tắt giải pháp ở đây.

Trước hết: hãy quên NAT (nếu bạn có thể) - câu hỏi hoàn toàn không phải là về cách định cấu hình NAT. Đó là về việc truy cập máy chủ được đặt phía sau NAT từ cả Internet và LAN. Sử dụng hai vùng DNS là một giải pháp thay thế khả thi, nhưng không phải lúc nào cũng là giải pháp. Nhưng giải pháp này tồn tại và cực kỳ đơn giản (mặc dù không hoàn hảo, có lẽ):

(1) trên máy chủ: thêm địa chỉ IP công cộng làm địa chỉ IP phụ trên giao diện mạng của máy chủ với mặt nạ 255.255.255.255 (dịch vụ web hoặc bất cứ điều gì bạn muốn trên máy chủ cũng nên nghe trên địa chỉ IP này); tất cả các hệ điều hành hiện đại sẽ cho phép bạn thực hiện điều này (hoặc giao diện loopback với địa chỉ IP công cộng được gán cho nó có thể được sử dụng thay vì thêm IP phụ vào giao diện chính).

(2) trên máy chủ LAN: ví dụ: thêm tuyến Máy chủ cho địa chỉ IP công cộng, ví dụ, đối với máy chủ Windows sử dụng lệnh sau: tuyến -p thêm 203.0.113.130 mặt nạ 255.255.255.255 192.168 .1.11 (bạn cũng có thể sử dụng tùy chọn "tuyến đường tĩnh" DHCP để phân phối tuyến đường). Hoặc, nếu có (a) bộ chuyển đổi L3 (es)/bộ định tuyến ở giữa máy khách và bộ định tuyến hướng Internet, hãy định cấu hình tuyến Máy chủ đó trên (các) bộ chuyển đổi trung gian (bộ)/bộ định tuyến này, không trên các khách hàng.

Đối với những người liên quan đến TCP bắt tay ba bước: nó sẽ hoạt động tốt trong cấu hình được đề xuất.

Vui lòng cung cấp thông tin phản hồi (ít nhất, bỏ phiếu).

2
Sergio

Từ quan điểm kỹ thuật, giải pháp tốt nhất cho vấn đề này là bật IPv6 trên mạng của bạn. Khi IPv6 được bật, bạn cần tạo bản ghi AAAA cho tên miền của mình. Giữ bản ghi A hiện có trỏ đến IPv4 bên ngoài của bộ định tuyến . Tạo bản ghi AAAA trỏ đến địa chỉ IPv6 của máy chủ .

IPv6 có đủ địa chỉ để tránh NAT, vì vậy bạn sẽ không cần kẹp tóc NAT cho IPv6. Và khi bạn đã bật IPv6 và tạo bản ghi AAAA, mọi khách hàng đều hỗ trợ RFC 8305 sẽ thử IPv6 trước IPv4. Điều này có nghĩa là bạn không cần kẹp tóc NAT cho IPv4, vì khách hàng sẽ không sử dụng nó.

Bạn vẫn sẽ cần IPv4 hiện tại NAT cho các kết nối đi và chuyển tiếp cổng cho các kết nối đến cho đến khi hầu hết thế giới cũng đã bật IPv6.

Nó cũng nhanh hơn.

Sử dụng IPv6 sẽ cung cấp cho bạn một hiệu suất tốt hơn so với NAT kẹp tóc.

Với kẹp tóc NAT khách hàng của bạn sẽ gửi gói thông qua bộ chuyển mạch đến bộ định tuyến, bộ định tuyến sau đó sẽ thực hiện hai vòng dịch và cuối cùng gửi gói thông qua bộ chuyển mạch đến máy chủ. để khách hàng sẽ đi qua toàn bộ con đường ngược lại.

Với IPv6, bạn tránh NAT, thay vào đó các gói được gửi trực tiếp thông qua chuyển đổi giữa máy khách và máy chủ. Điều này có nghĩa là trên một vòng, bạn giảm số lần chuyển qua công tắc từ 4 xuống còn 2 và bạn tránh được 2 chuyến đi qua bộ định tuyến và 4 bản dịch mà bộ định tuyến sẽ thực hiện. Điều này chuyển thành hiệu suất tốt hơn.

Điều này đúng ngay cả khi bạn sử dụng một công tắc được tích hợp trong cùng hộp với bộ định tuyến.

Nếu ISP không có IPv6 thì sao?

Nếu bạn đang sử dụng một ISP không hỗ trợ IPv6, tôi sẽ hỏi liệu bạn có nên lưu trữ các máy chủ trên mạng đó không. Đây là những gợi ý của tôi về những việc cần làm nếu ISP hiện không hỗ trợ IPv6.

Trước tiên, hãy nói với ISP rằng bạn cần IPv6. Và có thể nhắc nhở họ rằng giao thức IPv6 đã tồn tại được 20 năm nên họ đã quá hạn trong việc hỗ trợ nó. Nếu điều đó không đủ để ISP đưa bạn nghiêm túc bắt đầu tìm kiếm các ISP khác.

Nếu bạn tìm thấy một ISP có hỗ trợ IPv6, bạn có thể chạy với cả hai ISP trong thời gian chuyển tiếp. Trên bộ định tuyến được kết nối với ISP mới, bạn có thể vô hiệu hóa IPv4 ở phía LAN và sau đó kết nối các bên LAN của cả hai bộ định tuyến với cùng một công tắc. IPv4 và IPv6 là hai giao thức độc lập và do đó không có vấn đề gì nếu các kết nối đó đi qua các bộ định tuyến khác nhau. Là một lợi ích phụ, nó cung cấp cho bạn một số tiền dự phòng nếu một trong các kết nối bị mất điện.

Nếu bạn không thể tìm thấy một ISP có hỗ trợ IPv6, bạn nên xem xét việc chuyển máy chủ của mình sang một cơ sở lưu trữ. Với một máy chủ trong một cơ sở lưu trữ, bạn ít phụ thuộc vào vị trí địa lý và vì lý do đó, có nhiều sự cạnh tranh giữa các nhà cung cấp sẽ giúp đảm bảo có một dịch vụ đáp ứng nhu cầu của bạn.

Di chuyển máy chủ đến một cơ sở lưu trữ sẽ không cung cấp cho khách hàng IPv6 của bạn, nhưng di chuyển máy chủ có nghĩa là bạn không còn cần kẹp tóc NAT để tiếp cận nó.

Những việc bạn không nên làm

Không bật IPv6 và tạo bản ghi AAAA nếu bạn không có cách định tuyến lưu lượng IPv6. Nếu ISP của bạn không hỗ trợ IPv6 nhưng bạn vẫn chọn bật IPv6 trên mạng LAN của mình (có thể sử dụng địa chỉ RFC 4193) và tạo bản ghi AAAA, nó sẽ hoạt động cho các máy khách trên mạng LAN đến máy chủ của bạn trên mạng LAN. Nhưng giao tiếp giữa mạng LAN của bạn và thế giới bên ngoài trước tiên sẽ thử IPv6 (sẽ không hoạt động) và bạn sẽ dựa vào việc quay trở lại với IPv4, điều tốt nhất là chậm hơn một chút hoặc tệ nhất là không xảy ra.

1
kasperd

Ill trả lời cho câu hỏi của tôi chỉ để mở rộng tầm nhìn cho những người có vấn đề tương tự.

Tôi đã liên lạc với ISP của tôi và yêu cầu họ thử giải quyết vấn đề của tôi. Những gì họ đã cung cấp cho tôi là một địa chỉ IP công cộng khác chỉ dành cho máy chủ, Bây giờ tôi có lưu lượng truy cập cục bộ trên WAN bên FreeBSD và chúng tôi đã tạo các đường dẫn cụ thể để lưu lượng truy cập cục bộ nhanh hơn đến IP công cộng của Máy chủ

1
adopilot

Tôi sẽ thêm một câu trả lời ở đây vì các ý kiến ​​ở đây không giải quyết được vấn đề cụ thể của tôi. Tôi nghi ngờ đó là vì tôi gặp phải một lỗi kernel linux khó chịu. Các thiết lập là:

internet <--> modem 1.1.1.1/30 <--> switch <---> LAN 10.1.1.0/24
                                      ^
        +----------------------+      |
        |              /--eth0 o <----/
        |              |       |           
        | 10.1.1.1/24 br0      |           v (antenna)
        |  1.1.1.2/30  |       |           |
        |              \-wlan0 o ----------/
        +----------------------+ 

Mặc dù bức tranh có vẻ phức tạp, sự thay đổi duy nhất có liên quan đến các tình huống được nêu trong các bình luận khác là việc bổ sung cầu phần mềm, br0. Nó ở đó vì hộp cổng cũng là một điểm truy cập không dây cho mạng LAN.

Hộp cổng của chúng tôi vẫn đang hoạt động NAT nhiệm vụ cho các máy trên mạng LAN. Vì chỉ có 1 cổng ethernet nên buộc phải làm kẹp tóc NAT. Tôi nghi ngờ nó chỉ nên hoạt động với các quy tắc iptables đã cho trong các bình luận khác ở đây, nhưng trên nhân Linux ít nhất là 4,9 thì không. Dưới 4,9, trong khi hộp cổng của chúng tôi có thể truy cập internet, các máy trên mạng LAN cố gắng truy cập thông qua NAT có thể 't.

tcpdump hiển thị phản hồi cho các gói đến nhấn eth0, nhưng chúng không làm cho nó ra khỏi br0. Chạy lệnh này sửa lỗi đó:

ebtables -t brouter -A BROUTING -d 01:00:00:00:00:00/01:00:00:00:00:00 -j ACCEPT
ebtables -t brouter -A BROUTING -p IPv4 --ip-dst 10.1.1.0/24 -j ACCEPT
ebtables -t brouter -A BROUTING -p IPv4 --ip-src 10.1.1.0/24 -j ACCEPT
ebtables -t brouter -A BROUTING -p IPv4 -j DROP

Trước khi lệnh đó được chạy, các gói đến được xử lý theo hành vi mặc định của hạt nhân, nghĩa là đưa chúng đến cầu sau đó truyền cho chúng các mô đun định tuyến của kernel. Lệnh buộc các gói không từ mạng LAN đi qua cầu và đi thẳng đến định tuyến, điều đó có nghĩa là cây cầu không có cơ hội thả chúng. Địa chỉ quảng bá và phát đa hướng phải được bắc cầu, nếu không những thứ như DHCP và mDNS sẽ không hoạt động. nếu bạn đang sử dụng IPv6, bạn cũng phải thêm các quy tắc cho nó.

Bạn có thể muốn khắc phục sự cố bằng cách này:

brctl hairpin br0 eth0 on
brctl hairpin br0 wlan0 on

Tôi chắc chắn đã rất cám dỗ - đó là nỗ lực đầu tiên của tôi. Ngay sau khi tôi thực hiện, các máy trên mạng LAN đã truy cập được internet, vì vậy nó hoạt động được một lúc. Sau đó, điều sau đây xảy ra (và tôi không quan tâm để lặp lại thí nghiệm):

  1. Thời gian Ping trên mạng LAN đến cổng tăng gấp đôi sau khoảng 10 giây, tăng từ 0,1ms, lên 0,2ms, 0,4ms, 0,8ms, 2ms và cho đến khi hộp cổng không thể truy cập được từ mạng LAN. Nó cười như một cơn bão gói, nhưng STP đã được bật ở mọi nơi.
  2. Không lâu sau khi tất cả các điểm truy cập không dây đã chết.
  3. Trong khi cố gắng chẩn đoán những gì đang xảy ra với không dây, tất cả các điện thoại IP đã khởi động lại.
  4. Không lâu sau đó, các máy có dây đã mất mọi liên lạc với mạng LAN.

Cách duy nhất là khởi động lại mọi máy trong tòa nhà. Một ngoại lệ là các công tắc phần cứng, không thể khởi động lại. Họ phải được đạp điện.

0
Russell Stuart

Vì tôi cũng đã hỏi câu hỏi này (xem Làm cách nào để tôi truy cập dịch vụ mạng được đặt sau tường lửa từ bên trong bằng IP bên ngoài? ) và được chuyển hướng ở đây nhưng câu trả lời ở đây không cung cấp giải pháp (trái ngược với giải thích chung ) hãy để tôi cung cấp Linux của tôi (iptables cụ thể) giải pháp ở đây để tiết kiệm cho mọi người một vài giờ thử nghiệm. Tập tin này nằm trong iptables-restore định dạng và có thể được đọc trực tiếp vào iptables (sau khi chỉnh sửa địa chỉ IP). Cái này dành cho máy chủ web (cổng 80) và chỉ dành cho IPv4 - các quy tắc cho IPv6 và cho SSL (cổng 443) là tương tự nhau.


# Port forwarding for VM / Container access with „hairpin NAT“.
*nat
:PREROUTING ACCEPT [3:205]
:INPUT ACCEPT [59:670]
:OUTPUT ACCEPT [16:172]
:POSTROUTING ACCEPT [20:257]

# This was simple port forwarding - access works from outside but not from inside
#-A PREROUTING  -4 -p tcp -i eth0 --dport 80 -j DNAT --to web.local:80

# This is real hairpin NAT which allows „web.local“ to access itself via the VM hosts external IP.
# First we need to masquerade any traffic going out the external interface:
-A POSTROUTING -o eth0 -j MASQUERADE

# Then we need to reroute incoming traffic on the public IP to the local IP:
-A PREROUTING  -4 -p tcp -d web.public.com --dport  80 -j DNAT --to web.local:80

# And finally we need to tell the router that the source IP of any traffic
# coming from the LAN must be source-rewritten when going to the web server:
-A POSTROUTING -4 -p tcp -s lan.local/24 -d web.local --dport  80 -j SNAT --to-source web.public.com:80

COMMIT

Thay thế lan.local, web.localweb.public.com với mạng cục bộ của bạn (ví dụ: 10.0.x.0/24), IP cục bộ của máy chủ web của bạn (ví dụ: 10.0.1.2) và IP công cộng của bộ định tuyến của bạn (ví dụ: 4.5.6.7). Các -4 chỉ để cho phép các quy tắc IPv6 và IPv4 trong cùng một tệp (các dòng như vậy bị bỏ qua bởi ip6tables). Ngoài ra, hãy nhớ đặt địa chỉ IPv6 trong [ngoặc] khi chúng bao gồm khai báo cổng, ví dụ: [fe0a:bd52::2]:80.

Đó là tất cả những điều khiến tôi phải nhổ tóc khi cố gắng thực sự thực hiện những lời giải thích trong câu hỏi này. Tôi hy vọng tôi không bỏ sót điều gì.

0
Jens

Như đó là một câu hỏi kinh điển. Tôi sẽ trả lời nếu bạn có bộ định tuyến Sonicwall.

Biểu thức cần biết là Chính sách lặp lại NAT

Tài liệu này mô tả cách Máy chủ trên SonicWall LAN có thể truy cập máy chủ trên SonicWall LAN bằng địa chỉ IP công cộng của máy chủ đến FQDN. Hãy tưởng tượng một mạng NSA 4500 (Tăng cường SonicOS) trong đó Mạng con LAN chính là 10.100.0.0/24 và Mạng chính WAN IP là 3.3.2.1. Hãy nói rằng bạn có một trang web cho khách hàng của mình và tên máy chủ của nó là. Bạn đã viết các chính sách và quy tắc cần thiết để người ngoài có thể truy cập trang web, nhưng nó thực sự đang chạy trên máy chủ riêng tư 10.100.0.2. Bây giờ hãy tưởng tượng rằng bạn là một người sử dụng máy tính xách tay ở phía riêng tư, với IP là 10.100.0.200. Bạn muốn tiếp cận máy chủ bằng tên công khai của nó, bởi vì bạn làm điều tương tự khi máy tính xách tay của bạn đi cùng bạn. Nếu bạn ngồi trên phía riêng tư và yêu cầu http://www.example.com >, loopback là điều giúp cho điều đó có thể hoạt động, mặc dù máy chủ thực sự ở ngay bên cạnh bạn trên một địa chỉ IP cục bộ .

Để cho phép chức năng này, bạn sẽ cần tạo một chính sách vòng lặp NAT, còn được gọi là NAT phản chiếu hoặc kẹp tóc.

Chính sách lặp lại bằng cách sử dụng WAN Địa chỉ IP của giao diện

Login to the SonicWall Management GUI.
Navigate to Manage | Rules | NAT Policies submenu.
Click on the Add button.
Create the following NAT Policy.
Original Source: LAN Subnets (or Firewalled Subnets if you want hosts in other zones to be included)
Translated Source: WAN Interface IP
Original Destination: WAN Interface IP
Translated Destination: (LAN server object)
Original Service: Any
Translated Service: Original
Inbound Interface: Any
Outbound Interface: Any

Sonicwall sẽ nhận ra dịch vụ bên ngoài mà bạn cố gắng liên hệ và sẽ viết lại địa chỉ đích để phù hợp với địa chỉ bên trong của máy chủ, do đó nó sẽ được chuyển sang máy tính.

0
yagmoth555