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

Đây là một câu hỏi Canonical về Hairpin 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 khách hàng, máy chủ và Bộ định tuyến NAT. 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 IP bên ngoài. 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 đề.

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ột Mạng DMZ hoặc ủy quyền TCP 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.

Vì đây đã được coi là câu hỏi kinh điển 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à (mặc dù xuất sắc) liên quan cụ thể đến 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 NAT đích (DNAT) tại cổng. Người dùng nội bộ sau đó cố gắng truy cập các dịch vụ đó thông qua địa chỉ bên ngoài. Gói 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 nội bộ. Chính sự xoay chuyển sắc bén của gói này ở cổng tạo ra cái 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ì 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 NAT đích đến trên gói ban đầu bằng cách viết lại địa chỉ nguồn của gói trả về.

Do đó, khách hàng gửi một gói đến một địa chỉ IP bên ngoài , nhưng nhận được phản hồi từ một địa chỉ IP nội bộ . 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à tiếp cận cổng từ mạng bên trong , cũng thực hiện NAT nguồn (SNAT) trên gói gửi đến, thường bằng cách viết lại địa chỉ nguồn là địa chỉ nguồn của cổng. Sau đó, máy chủ nghĩ rằng máy khách là cổng chính và trả lời trực tiếp cho nó. Điều đó lần lượt mang lại cho cổng 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:

Một số thiết bị cổng tiêu dùng đủ sáng để nhận ra các gói mà bước NAT thứ hai là cần thiết và chúng có thể sẽ hoạt động vượt trội trong kịch bản NAT kẹp tóc. Những người khác thì không, và vì vậy sẽ không, và không chắc là họ có thể được tạo ra để 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 thuộc chủ đề cho 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để làm DNAT, do đó:

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 filterchuỗi, các quy tắc bổ sung có thể cần thiết để 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, NAT kẹp tóc kích hoạt đúng cách không phải là cách tốt nhất để xử lý vấn đề. Điều tốt nhất là DNS đường chân trời , nơi tổ chức của bạn cung cấp các câu trả lời khác nhau cho tra cứu ban đầu tùy thuộc vào vị trí của máy khách 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 bên trong 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.

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 thất bại.

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.

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.xxx ở bên ngoài và sau đó 192.xxx ở bên trong.

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 Độc lập điểm cuối trong Bộ 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

Ả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.

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, cho phép tôi tóm tắt các 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ấu hình NAT. Đó là về việc truy cập một 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 không 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: route -p add 203.0.113.130 mặt nạ 255.255.255.255 192.168.1.11 (bạn cũng có thể sử dụng DHCP " tùy chọn tuyến đường tĩnh "để 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 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 bắt tay ba chiều TCP: nó sẽ hoạt động tốt trong cấu hình đề xuất.

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

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ộ ở phía mạng 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ủ

Từ quan điểm kỹ thuật, giải pháp tốt nhất cho vấn đề này là kích hoạ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 một 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à một khi bạn đã bật IPv6 và tạo bản ghi AAAA, bất kỳ ứng dụng khách nào hỗ trợ RFC 8305 sẽ thử IPv6 trước IPv4. Điều này có nghĩa là bạn cũng 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 NAT IPv4 hiện tại của mình cho các kết nối gử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 một 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ủ. Các gói từ máy chủ đến máy khách sẽ đi qua toàn bộ đường dẫn 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 chuyến đi khứ hồi, 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ữ 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.

Đầu 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ố lượng 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 NAT kẹp tóc để tiếp cận nó.

Những gì 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.

Vì tôi cũng đã hỏi câu hỏi này (xem Làm thế 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ác câu trả lời ở đây không cung cấp giải pháp (ngược lại với giải thích chung ) cung cấp iptablesgiải pháp Linux ( cụ thể) của tôi ở đây để tiết kiệm cho mọi người một vài giờ thử nghiệm. Tập tin này có 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.localvà web.public.comvới mạng nội 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à chỉ IP công cộng của router của bạn (ví dụ. 4.5.6.7). Đây -4chỉ là để 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 ip6tables). Ngoài ra, hãy nhớ đặt địa chỉ IPv6 trong [dấu ngoặc] khi chúng bao gồm tờ khai 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 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ì.

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 thực hiện nhiệm vụ NAT cho các máy trên mạng LAN. Vì nó chỉ có 1 cổng ethernet nê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 được đưa ra trong các nhận xét khác ở đây, nhưng trên nhân Linux thì ít nhất là 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 qua NAT không thể.

tcpdumphiể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 qua 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à cứ thế 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 ở khắp 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.

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 loopback NAT

Tài liệu này mô tả cách máy chủ lưu trữ 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 (SonicOS được tăng cường) trong đó Mạng con LAN chính là 10.100.0.0 / 24 và IP WAN chính là 3.3.2.1. Giả sử 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 truy cập 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 ở phía riêng tư và yêu cầu http://www.example.com>, loopback là những gì làm cho nó 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 chính sách loopback NAT, còn được gọi là phản chiếu NAT hoặc kẹp tóc.

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

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.

Trong FreeBSD bằng cách sử dụng PF, thật dễ dàng như (trong tệp pf.conf của bạn):

extif = "tun0"
intif = "em0"
{other rules}...
nat on $intif from any to 192.168.20.8 port 80 -> ($extif)

192.168.20.8 sẽ là máy chủ web nội bộ.