วนกลับไปยังที่อยู่ IP สาธารณะที่ส่งต่อจากเครือข่ายท้องถิ่น - Hairpin NAT

45

นี่เป็นคำถามที่ยอมรับได้เกี่ยวกับกิ๊บ NAT (Loopback NAT)

รูปแบบทั่วไปของคำถามนี้คือ:

เรามีเครือข่ายกับลูกค้าเซิร์ฟเวอร์และเราเตอร์ NAT มีการส่งต่อพอร์ตบนเราเตอร์ไปยังเซิร์ฟเวอร์ดังนั้นบริการบางอย่างของมันจึงพร้อมใช้งานจากภายนอก เรามี DNS ที่ชี้ไปที่ IP ภายนอก ไคลเอนต์เครือข่ายท้องถิ่นล้มเหลวในการเชื่อมต่อ แต่ทำงานภายนอก

  • ทำไมสิ่งนี้ถึงล้มเหลว
  • ฉันจะสร้างรูปแบบการตั้งชื่อแบบรวมเป็นหนึ่งเดียว (ชื่อ DNS ที่ทำงานได้ทั้งภายในและภายนอก)

คำถามนี้มีคำตอบที่ถูกผสานจากคำถามอื่น ๆ พวกเขาเดิมอ้างถึง FreeBSD, D-Link, Microtik และอุปกรณ์อื่น ๆ พวกเขากำลังพยายามแก้ไขปัญหาเดียวกันทั้งหมด

networking  nat  port-forwarding  internet 
— adopilot
แหล่งที่มา
1
หากจุดประสงค์ของคุณคือการทดสอบการเข้าถึงจากอินเทอร์เน็ตไม่มีจุดใดที่จะยุ่งกับเส้นทางของเราเตอร์และ / หรือการตั้งค่า DNS อย่างไรก็ตามอย่างดีที่สุดจากภายในคุณจะต้องตรวจสอบว่าส่วนภายในของเราเตอร์นั้นทำงานได้หรือไม่ ฉันแนะนำให้คุณใช้พร็อกซีเซิร์ฟเวอร์ที่ด้านนอก

คำตอบ:

16

สิ่งที่คุณกำลังมองหาเรียกว่า "กิ๊บ NAT" การร้องขอจากอินเทอร์เฟซภายในสำหรับที่อยู่ IP ที่กำหนดให้กับอินเทอร์เฟซภายนอกควรเป็น NAT'ted ราวกับว่าพวกเขามาจากอินเทอร์เฟซภายนอกฝั่ง

ฉันไม่มีความคุ้นเคยกับ FreeBSD เลย แต่อ่านคู่มือ "pf" สำหรับ OpenBSD ( http://www.openbsd.org/faq/pf/rdr.html ) วิธีแก้ปัญหาที่เสนอของ DNS แบบแยกส่วนโดยใช้ เครือข่าย DMZ หรือ TCP proxying ทำให้ฉันเชื่อว่า "pf" ไม่รองรับกิ๊บ NAT

ฉันจะดูเส้นทางของ DNS แบบแบ่งส่วนและไม่ใช้ที่อยู่ IP ใน URL ภายใน แต่ใช้ชื่อแทน

— Evan Anderson
แหล่งที่มา
ฉันวิ่งข้ามกระทู้นี้ในขณะที่พยายามแก้ไขปัญหาเดียวกันและในขณะที่เป็นจริงที่ FreeBSD ไม่สนับสนุนกิ๊บ nat ออกจากกล่องมีวิธีเปลี่ยนเส้นทางและ NAT ภายใน -> ภายนอก -> ปริมาณการใช้ภายใน
— สีแดงเข้มนกกระยาง
ตัวอย่างเช่น no nat on $int_if proto tcp from $int_if to $int_net , nat on $int_if proto tcp from $int_net to $hairpin_int port $hairpin_ports -> $int_if, rdr on $int_if proto tcp from $int_net to $ext_if port $hairpin_ports -> $hairpin_int
— สีแดงเข้มนกกระยาง
48

เนื่องจากสิ่งนี้ได้รับการยกระดับให้เป็นคำถามมาตรฐานเกี่ยวกับกิ๊บติดผม NATฉันคิดว่ามันน่าจะมีคำตอบที่ถูกต้องมากกว่าคำตอบที่ยอมรับในปัจจุบันซึ่ง (แม้ว่าจะยอดเยี่ยม) เกี่ยวข้องกับ FreeBSD โดยเฉพาะ

คำถามนี้ใช้กับบริการที่ให้บริการโดยเซิร์ฟเวอร์บนเครือข่าย IPv4 ที่จัดการด้วย RFC1918 ซึ่งให้บริการแก่ผู้ใช้ภายนอกโดยแนะนำ NAT (DNAT) ปลายทางที่เกตเวย์ ผู้ใช้ภายในจากนั้นลองเข้าถึงบริการเหล่านั้นผ่านที่อยู่ภายนอก แพ็คเก็ตของพวกเขาออกจากไคลเอนต์ไปยังอุปกรณ์เกตเวย์ซึ่งจะเขียนที่อยู่ปลายทางอีกครั้งและอัดกลับเข้าไปในเครือข่ายภายในทันที มันเป็นอย่างนี้คมชัดเกี่ยวกับจะทำให้แพ็คเก็ตที่ประตูที่ทำให้ชื่อNAT กิ๊บ , โดยการเปรียบเทียบกับปิ่นหัน

ปัญหาเกิดขึ้นเมื่ออุปกรณ์เกตเวย์เขียนที่อยู่ปลายทางใหม่ แต่ไม่ใช่ที่อยู่ต้นทาง เซิร์ฟเวอร์จะได้รับแพ็คเก็ตที่มีที่อยู่ปลายทางภายใน (ของตัวเอง) และที่อยู่ภายใน (ลูกค้า) มันรู้ว่ามันสามารถตอบกลับโดยตรงไปยังที่อยู่ดังกล่าวจึงทำได้ เนื่องจากคำตอบนั้นโดยตรงมันไม่ได้ผ่านเกตเวย์ดังนั้นจึงไม่เคยมีโอกาสสร้างสมดุลของเอฟเฟ็กต์ NAT ปลายทางขาเข้าบนแพ็กเก็ตเริ่มต้นโดยเขียนที่อยู่ต้นทางของแพ็กเก็ตคืน

ไคลเอ็นต์จึงส่งแพ็กเก็ตไปยังที่อยู่ IP ภายนอกแต่ได้รับการตอบกลับจากที่อยู่ IP ภายใน มันไม่มีความคิดว่าสองแพ็กเก็ตเป็นส่วนหนึ่งของการสนทนาเดียวกันดังนั้นจึงไม่มีการสนทนาเกิดขึ้น

วิธีแก้คือสำหรับแพ็คเก็ตที่ต้องการ NAT ปลายทางดังกล่าวและไปถึงเกตเวย์จากเครือข่ายภายในเพื่อทำการ NAT ต้นทาง (SNAT) บนแพ็คเก็ตขาเข้าโดยปกติแล้วจะเขียนที่อยู่ต้นทางใหม่ให้เป็นเกตเวย์ เซิร์ฟเวอร์คิดว่าไคลเอนต์เป็นเกตเวย์และตอบกลับโดยตรง ในทางกลับกันเปิดโอกาสให้เกตเวย์สร้างสมดุลผลกระทบของทั้ง DNAT และ SNAT บนแพ็กเก็ตขาเข้าโดยเขียนทั้งที่อยู่ต้นทางและปลายทางบนแพ็กเก็ตที่ส่งคืน

ลูกค้าคิดว่ากำลังคุยกับเซิร์ฟเวอร์ภายนอก เซิร์ฟเวอร์คิดว่ากำลังคุยกับอุปกรณ์เกตเวย์ ทุกฝ่ายมีความสุข ไดอะแกรมอาจมีประโยชน์ ณ จุดนี้:

ป้อนคำอธิบายรูปภาพที่นี่

อุปกรณ์ Consumer gateway บางชนิดมีความสว่างเพียงพอที่จะรับรู้แพ็คเก็ตเหล่านั้นซึ่งจำเป็นต้องใช้ NAT ขั้นตอนที่สองและอุปกรณ์เหล่านั้นอาจทำงานนอกกรอบได้ในสถานการณ์สมมติกิ๊บ NAT คนอื่นไม่เช่นนั้นจะไม่และไม่น่าเป็นไปได้ที่พวกเขาจะสามารถทำงานได้ การอภิปรายเกี่ยวกับอุปกรณ์ระดับผู้บริโภคที่อยู่นอกหัวข้อสำหรับข้อบกพร่องของเซิร์ฟเวอร์

โดยทั่วไปอุปกรณ์เครือข่ายที่เหมาะสมสามารถบอกให้ทำงานได้ แต่ - เพราะพวกเขาไม่ได้อยู่ในธุรกิจที่คาดเดาผู้ดูแลระบบของพวกเขา - พวกเขาจะต้องบอกให้ทำเช่นนั้น Linux ใช้iptablesในการทำ DNAT:

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

ซึ่งจะช่วยให้ง่ายสำหรับ DNAT พอร์ต HTTP 192.168.3.11ที่ไปยังเซิร์ฟเวอร์ภายใน แต่การเปิดใช้งานกิ๊บ NAT จะต้องมีกฎเช่น:

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

โปรดทราบว่ากฎดังกล่าวจะต้องอยู่ในสถานที่ที่เหมาะสมในเครือข่ายที่เกี่ยวข้องเพื่อให้ทำงานได้อย่างถูกต้องและขึ้นอยู่กับการตั้งค่าในกลุ่มfilterโซ่อาจจำเป็นต้องมีกฎเพิ่มเติมเพื่ออนุญาตการไหลของ NATted การสนทนาดังกล่าวทั้งหมดอยู่นอกขอบเขตของคำตอบนี้

แต่อย่างที่คนอื่นพูดไว้การเปิดใช้งานกิ๊บ NAT อย่างถูกต้องไม่ใช่วิธีที่ดีที่สุดในการจัดการกับปัญหา วิธีที่ดีที่สุดคือsplit-horizon DNSซึ่งองค์กรของคุณให้บริการคำตอบที่แตกต่างกันสำหรับการค้นหาดั้งเดิมโดยขึ้นอยู่กับว่าลูกค้าร้องขอคืออะไรโดยมีเซิร์ฟเวอร์ที่แตกต่างกันสำหรับผู้ใช้ภายในและภายนอกหรือโดยการกำหนดค่าเซิร์ฟเวอร์ DNS ที่อยู่ของลูกค้าที่ร้องขอ

— MadHatter
แหล่งที่มา
ฉันสงสัยเล็กน้อยเกี่ยวกับที่อยู่บนแพ็กเก็ตที่แลกเปลี่ยนระหว่างเกตเวย์และเซิร์ฟเวอร์ มันจะไม่สอดคล้องกันมากขึ้นถ้าเซิร์ฟเวอร์เห็นที่อยู่ IP สาธารณะของเราเตอร์เป็น IP ของลูกค้าหรือไม่ ในทางเทคนิคทั้งสองสามารถทำงานได้ แต่เพื่อให้สอดคล้องกับวิธีที่เซิร์ฟเวอร์อื่นมองลูกค้ามันจะต้องใช้ IP สาธารณะ
— kasperd
1
ฉันคิดว่าคุณหมายถึงกรณีสุดท้าย "กิ๊บกิต NAT ที่เหมาะสม" สิ่งสำคัญคือการเขียนที่อยู่แหล่งที่มาใหม่บนแพ็คเก็ตขาเข้าในลักษณะที่มันจะกลับไปที่เราเตอร์ซึ่งสามารถย้อนกลับทั้ง DNAT และ SNAT และหลีกเลี่ยงปัญหา ที่อยู่ใดที่เราเตอร์ใช้ในการทำสิ่งนี้เป็นประเด็นที่มีรสนิยมมากกว่าและถ้าคุณทำเช่นนี้iptablesเป็นสิ่งที่คุณสามารถกำหนดค่าได้หากคุณเลือก
— MadHatter
1
ผู้ดูแลระบบหลายคนรวมตัวเองพิจารณา DNS แบบแบ่งขอบเขตซึ่งเป็นการรักษาที่เลวร้ายยิ่งกว่าโรค ถ้าหนึ่ง SNAT เพิ่มเติมสามารถเรียกได้ว่าเป็นโรคเลย DNS แบบแยกมุมมองทำให้มนุษย์สับสนในขณะที่ทำให้ชีวิตเราเตอร์ง่ายขึ้น หัวข้อนี้ควรได้รับการจัดการที่ดีขึ้นโดยคำถาม / คำตอบ ServerFault แยกต่างหาก
— kubanczyk
คำตอบของฉันเกี่ยวกับกิ๊บ NAT เป็นอย่างมาก ฉันเห็นข้อดีและข้อเสียของการเปิดใช้ "split-horizon DNS" ซึ่งเป็นที่ยอมรับ: ผู้เชี่ยวชาญรวมถึงการมีคำถามเฉพาะสำหรับการใช้งานและปัญหาของ SHDNS แต่ข้อเสียคือคำถามนี้มีคำถามอื่น ๆ อีกมากมายที่เกี่ยวข้องกับ มันรวมอยู่ในนั้นดังนั้นที่อาจเกิดขึ้นกับคำถามของคุณเช่นกัน ถ้าเป็นฉันฉันจะหยิบยกเรื่องเมตาและหาฉันทามติ หากคำถามดังกล่าวเขียนขึ้นฉันหวังว่าจะได้อ่านคำตอบของคุณ!
— MadHatter
@MadHatter ฉันควรเขียนคำสั่ง iptables ที่ไหน บนไคลเอนต์หรือเกตเวย์หรือเซิร์ฟเวอร์?
— Rocky Balboa
9

ปัญหาที่นี่คือว่าเราเตอร์ของคุณไม่ NAT ที่อยู่ลูกค้าภายในของคุณ ดังนั้น TCP handshake จึงล้มเหลว

ลองสมมุติ IP ต่อไปนี้

  • ลูกค้า: 192.168.1.3
  • เซิร์ฟเวอร์: 192.168.1.2
  • เราเตอร์ภายใน: 192.168.1
  • เราเตอร์ภายนอก: 123.123.123.1

นี่คือสิ่งที่เกิดขึ้น:

  1. ไคลเอนต์ (192.168.1.3) ส่ง TCP-SYN ไปยัง IP ภายนอกของคุณพอร์ต 80 (123.123.123.1:80)
  2. เราเตอร์เห็นกฎการส่งต่อพอร์ตและส่งต่อแพ็กเก็ตไปยังเซิร์ฟเวอร์ (192.168.1.2:80) โดยไม่เปลี่ยน IP ต้นทาง (192.168.1.3)
  3. ไคลเอ็นต์กำลังรอให้ SYN-ACK จาก IP ภายนอก
  4. เซิร์ฟเวอร์ส่งคำตอบของเขากลับไปยังลูกค้าโดยตรงเพราะอยู่ในเครือข่ายย่อยเดียวกัน มันไม่ได้ส่งแพ็กเก็ตไปยังเราเตอร์ซึ่งจะย้อนกลับ NAT
  5. ไคลเอนต์รับ SYN-ACK จาก 192.168.1.2 แทน 123.123.123.1 และทิ้งมันไป
  6. ลูกค้ายังคงรอ SYN-ACK จาก 123.123.123.1 และหมดเวลา
— ยินดีคืนเงิน
แหล่งที่มา
4

ทำไมไม่ใช้ split horizon dns แทนการเข้ารหัส hardcoding IP address ทุกแห่ง คุณจะมี ext.yourdomain ชี้ไปที่ 217.xxx ด้านนอกแล้ว 192.xxx ด้านใน

— Ryaner
แหล่งที่มา
1
หากคุณมีเวลาสักครู่คุณสามารถขยายความรู้ของ Split-Horizon DNS ได้อย่างไรมันทำงานอย่างไรและอุปสรรคสำคัญ นี่เป็นคำถามที่ยอมรับได้ในตอนนี้และน่ายินดีที่มีคำตอบที่สมบูรณ์ยิ่งขึ้น
— Chris S
2

หากเป็นเราเตอร์ D-Link ดั้งเดิม (เช่นไม่ใช่ Rev. D / เฟิร์มแวร์เวอร์ชั่น 1.00VG จาก Virgin Media) คุณควรจะสามารถปรับการตั้งค่าเพื่อหลีกเลี่ยงปัญหานี้ (อย่างไรก็ตามฉันเห็นด้วยกับคำแนะนำของผู้โพสต์ก่อนหน้าของ DD-WRT ด้วยเหตุผลอื่น ๆ อีกมากมาย!)

  1. ล็อกอินเข้าสู่เว็บอินเตอร์เฟสของเราเตอร์
  2. คลิกแท็บขั้นสูงที่ด้านบน
  3. คลิกที่แท็บการตั้งค่าไฟร์วอลล์ทางด้านซ้าย
  4. คลิกปุ่มตัวเลือกEndpoint Independentภายใต้การกรอง TCP Endpointดังแสดงในภาพหน้าจอด้านล่าง (หรือดูอีมูเลเตอร์เราเตอร์ที่เว็บไซต์ของ D-Link)
  5. บันทึกการเปลี่ยนแปลง; คุณทำเสร็จแล้ว

ภาพหน้าจอ UI เว็บเราเตอร์ D-Link

ภาพหน้าจอนี้มาจากโมเดล Rev. C คุณอาจแตกต่างกันเล็กน้อย

— เดวิด
แหล่งที่มา
2

เมื่อเร็ว ๆ นี้ตอบคำถามที่คล้ายกัน: Cisco Static NAT ไม่ทำงานบนฝั่ง LANและเพิ่งรู้ว่านี่เป็นคำถามที่ยอมรับได้ ดังนั้นอนุญาตให้ฉันสรุปการแก้ปัญหาที่นี่

ก่อนอื่น: ลืมเกี่ยวกับ NAT (ถ้าทำได้) - คำถามนั้นไม่เกี่ยวกับการกำหนดค่า NAT มันเกี่ยวกับการเข้าถึงเซิร์ฟเวอร์ที่อยู่ด้านหลัง NAT จากทั้งอินเทอร์เน็ตและ LAN การใช้ DNS สองโซนเป็นทางเลือกที่ทำงานได้ แต่ไม่ใช่วิธีแก้ปัญหาเสมอไป แต่วิธีการแก้ปัญหามีอยู่และเรียบง่ายอย่างเหลือเชื่อ (แม้ว่าจะไม่สมบูรณ์แบบอาจจะ):

(1) บนเซิร์ฟเวอร์: เพิ่มที่อยู่ IP สาธารณะเป็นที่อยู่ IP สำรองบนอินเทอร์เฟซเครือข่ายของเซิร์ฟเวอร์ที่มีหน้ากาก 255.255.255.255 (บริการเว็บหรือสิ่งที่คุณต้องการบนเซิร์ฟเวอร์ควรฟังที่อยู่ IP นี้ด้วย); ระบบปฏิบัติการที่ทันสมัยทั้งหมดจะอนุญาตให้คุณทำสิ่งนี้ (หรืออินเทอร์เฟซย้อนกลับที่มีที่อยู่ IP สาธารณะที่กำหนดให้สามารถใช้แทนการเพิ่ม IP สำรองไปยังอินเทอร์เฟซหลัก)

(2) บนโฮสต์ LAN: เพิ่มเส้นทางโฮสต์สำหรับที่อยู่ IP สาธารณะตัวอย่างเช่นสำหรับโฮสต์ Windows ใช้คำสั่งต่อไปนี้: เส้นทาง -p เพิ่ม 203.0.113.130 รูปแบบหน้ากาก 255.255.255.255 192.168.1.11 (คุณสามารถใช้ DHCP " ตัวเลือกเส้นทางคงที่ "เพื่อกระจายเส้นทาง) หรือหากมี (a) สวิตช์ L3 (es) / เราเตอร์ (s) อยู่ระหว่างไคลเอนต์และเราเตอร์ที่เชื่อมต่ออินเทอร์เน็ตให้กำหนดค่าโฮสต์เส้นทางนั้นบนสวิตช์ส่วนกลาง (เหล่านี้) / เราเตอร์ (s) ไม่ใช่ เกี่ยวกับลูกค้า

สำหรับผู้ที่เกี่ยวข้องกับการจับมือสามทาง TCP: มันจะทำงานได้ดีในการกำหนดค่าที่เสนอ

โปรดให้ข้อเสนอแนะ (อย่างน้อยโหวต)

— เซร์คิโอ
แหล่งที่มา
ความต้องการ # 2 ทำให้สิ่งนี้ไม่สามารถทำงานได้ดีบนเครือข่าย BYOD ...
— Michael
1

ป่วยตอบคำถามของฉันเพียงเพื่อขยายขอบเขตอันไกลโพ้นสำหรับผู้ที่มีปัญหาคล้ายกัน

ฉันติดต่อ ISP ของฉันและขอให้พวกเขาลองแก้ไขปัญหาของฉัน สิ่งที่พวกเขาเสนอให้ฉันคือที่อยู่ IP สาธารณะอีกอันสำหรับเซิร์ฟเวอร์ตอนนี้ฉันมีการรับส่งข้อมูลในท้องถิ่นบนฝั่ง WAN ของ FreeBSD และเราได้สร้างท่อเฉพาะสำหรับการรับส่งข้อมูลที่เร็วขึ้นในท้องถิ่นไปยัง IP สาธารณะของเซิร์ฟเวอร์

— adopilot
แหล่งที่มา
2
โซลูชันนี้ใช้เครือข่ายปริมณฑลหรือ DMZและเป็นทางเลือกที่ดีสำหรับทั้ง Hairpin NAT และ Split-Horizon DNS
— Chris S
1

จากมุมมองทางเทคนิคทางออกที่ดีที่สุดสำหรับปัญหานี้คือการเปิดใช้งาน IPv6 ในเครือข่ายของคุณ เมื่อเปิดใช้งาน IPv6 คุณจะต้องสร้างระเบียน AAAA สำหรับโดเมนของคุณ เก็บที่มีอยู่บันทึกชี้ไปที่ IPv4 ภายนอกของเราเตอร์ สร้างระเบียน AAAA ชี้ไปยังที่อยู่ IPv6 ของเซิร์ฟเวอร์

IPv6 มีที่อยู่เพียงพอที่จะหลีกเลี่ยง NAT ดังนั้นคุณไม่จำเป็นต้องใช้กิ๊บ NAT สำหรับ IPv6 และเมื่อคุณเปิดใช้งาน IPv6 และสร้างระเบียน AAAA แล้วไคลเอนต์ที่รองรับRFC 8305จะลองใช้ IPv6 ก่อน IPv4 ซึ่งหมายความว่าคุณไม่จำเป็นต้องใช้กิ๊บ NAT สำหรับ IPv4 เช่นกันเพราะลูกค้าจะไม่ใช้มัน

คุณจะยังคงต้องการ IPv4 NAT ที่มีอยู่สำหรับการเชื่อมต่อขาออกและการส่งต่อพอร์ตสำหรับการเชื่อมต่อขาเข้าจนกว่าส่วนใหญ่ของโลกจะเปิดใช้งาน IPv6 เช่นกัน

มันเร็วกว่าเช่นกัน

การใช้ IPv6 จะให้ประสิทธิภาพที่ดีกว่ากิ๊บ NAT

ด้วยกิ๊บ NAT ลูกค้าของคุณจะส่งแพ็กเก็ตผ่านสวิตช์ไปยังเราเตอร์เราเตอร์จะทำการแปลสองรอบและในที่สุดก็ส่งแพ็กเก็ตผ่านสวิตช์ไปยังเซิร์ฟเวอร์ แพ็คเก็ตจากเซิร์ฟเวอร์ไปยังลูกค้าจะผ่านเส้นทางทั้งหมดนั้นในสิ่งที่ตรงกันข้าม

ด้วย IPv6 คุณหลีกเลี่ยง NAT แทนที่จะส่งแพ็กเก็ตโดยตรงผ่านสวิตช์ระหว่างไคลเอนต์และเซิร์ฟเวอร์ ซึ่งหมายความว่าในการไปกลับคุณลดจำนวนการส่งผ่านสวิตช์จาก 4 เป็น 2 และคุณหลีกเลี่ยงการเดินทางผ่านเราเตอร์ 2 ครั้งและการแปล 4 ครั้งที่เราเตอร์จะดำเนินการ นี่แปลว่ามีประสิทธิภาพที่ดีขึ้น

สิ่งนี้เป็นจริงแม้ว่าคุณจะใช้สวิตช์ในกล่องเดียวกันกับเราเตอร์

เกิดอะไรขึ้นถ้า ISP ไม่มี IPv6

หากคุณใช้ ISP ซึ่งไม่รองรับ IPv6 ฉันจะถามว่าคุณควรโฮสต์เซิร์ฟเวอร์ในเครือข่ายนั้นหรือไม่ นี่คือคำแนะนำของฉันเกี่ยวกับสิ่งที่ต้องทำหาก ISP ไม่รองรับ IPv6 ในปัจจุบัน

ก่อนอื่นให้บอก ISP ว่าคุณต้องการ IPv6 และอาจเตือนพวกเขาว่าโพรโทคอล IPv6 มีมานานกว่า 20 ปีแล้วดังนั้นพวกเขาจึงใช้เวลานานในการสนับสนุน หากนั่นยังไม่เพียงพอที่ผู้ให้บริการอินเทอร์เน็ตจะพาคุณไปหาผู้ให้บริการรายอื่นอย่างจริงจัง

หากคุณพบ ISP ที่มีการสนับสนุน IPv6 คุณสามารถเรียกใช้กับ ISP ทั้งสองช่วงระยะเวลาการเปลี่ยนแปลง ในเราเตอร์ที่เชื่อมต่อกับ ISP ใหม่คุณสามารถปิดการใช้งาน IPv4 ที่ด้าน LAN แล้วเชื่อมต่อ LAN ด้านข้างของเราเตอร์ทั้งสองเข้ากับสวิตช์เดียวกัน IPv4 และ IPv6 เป็นสองโปรโตคอลอิสระและดังนั้นจึงไม่มีปัญหาหากการเชื่อมต่อเหล่านั้นผ่านเราเตอร์ที่แตกต่างกัน ประโยชน์ด้านข้างจะช่วยให้คุณมีจำนวนซ้ำซ้อนหากการเชื่อมต่อใด ๆ ขาดหายไป

หากคุณไม่พบ ISP ที่มีการสนับสนุน IPv6 คุณควรพิจารณาย้ายเซิร์ฟเวอร์ของคุณไปยังศูนย์บริการโฮสต์ ด้วยเซิร์ฟเวอร์ในสถานที่จัดการโฮสต์คุณจะพึ่งพาสถานที่ตั้งทางภูมิศาสตร์น้อยลงและด้วยเหตุนี้จึงมีการแข่งขันกันระหว่างผู้ให้บริการมากขึ้นซึ่งจะช่วยให้มั่นใจได้ว่ามีผู้ให้บริการที่ตรงกับความต้องการของคุณ

การย้ายเซิร์ฟเวอร์ไปยังสิ่งอำนวยความสะดวกในการให้บริการพื้นที่จะไม่ให้ IPv6 แก่ลูกค้าของคุณ แต่การย้ายเซิร์ฟเวอร์หมายความว่าคุณไม่จำเป็นต้องใช้กิ๊บ NAT เพื่อเข้าถึง

สิ่งที่คุณไม่ควรทำ

อย่าเปิด IPv6 และสร้างระเบียน AAAA หากคุณไม่มีวิธีกำหนดเส้นทางการรับส่งข้อมูลของ IPv6 หาก ISP ของคุณไม่รองรับ IPv6 แต่คุณเลือกที่จะเปิดใช้งาน IPv6 บน LAN ของคุณต่อไป (อาจใช้ที่อยู่ RFC 4193) และสร้างระเบียน AAAA มันจะทำงานให้กับลูกค้าบน LAN ของคุณไปยังเซิร์ฟเวอร์บน LAN ของคุณ แต่การสื่อสารระหว่าง LAN ของคุณกับโลกภายนอกจะลองใช้ IPv6 เป็นอันดับแรก (ซึ่งไม่ได้ผล) และคุณจะต้องพึ่งพาการถอยกลับไปสู่ ​​IPv4 ซึ่งที่ดีที่สุดคือช้าลงเล็กน้อยหรือแย่ที่สุดจะไม่เกิดขึ้น

— kasperd
แหล่งที่มา
0

เนื่องจากฉันถามคำถามนี้ด้วย (ดูฉันจะเข้าถึงบริการเครือข่าย NATed หลังไฟร์วอลล์จากภายในโดยใช้ IP ภายนอกได้อย่างไร ) และถูกเปลี่ยนเส้นทางที่นี่ แต่คำตอบที่นี่ไม่ได้ให้โซลูชัน (ตรงกันข้ามกับคำอธิบายทั่วไป) ให้ฉัน มอบiptablesโซลูชันLinux ( เฉพาะ) ของฉันที่นี่เพื่อช่วยให้ทุกคนทดลองใช้งานได้ไม่กี่ชั่วโมง ไฟล์นี้อยู่ในiptables-restoreรูปแบบและสามารถอ่านได้ใน iptables โดยตรง (หลังจากแก้ไขที่อยู่ IP ของหลักสูตร) สิ่งนี้มีไว้สำหรับเว็บเซิร์ฟเวอร์ (พอร์ต 80) และสำหรับ IPv4 เท่านั้น - กฎสำหรับ IPv6 และสำหรับ SSL (พอร์ต 443) นั้นคล้ายคลึงกัน


# 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

แทนที่lan.local, web.localและweb.public.comที่มีเครือข่ายท้องถิ่นของคุณ (เช่น. 10.0.x.0 / 24), IP เว็บเซิร์ฟเวอร์ของคุณท้องถิ่น (เช่น 10.0.1.2) และประชาชน IP เราเตอร์ของคุณ (เช่น. 4.5.6.7) นี่-4เป็นเพียงการอนุญาตให้ใช้กฎ IPv6 และ IPv4 ในไฟล์เดียวกัน (บรรทัดดังกล่าวถูกละเว้นip6tables) นอกจากนี้อย่าลืมใส่ที่อยู่ IPv6 ใน [วงเล็บ] [fe0a:bd52::2]:80เมื่อพวกเขารวมถึงการประกาศพอร์ตเช่น

นั่นคือทุกสิ่งที่ทำให้ฉันดึงผมออกมาเมื่อพยายามใช้คำอธิบายจริง ๆในคำถามนี้ ฉันหวังว่าฉันจะไม่เหลืออะไรเลย

— Jens
แหล่งที่มา
MASQUERADE บนอินเตอร์เฟส wan นั้นมีประโยชน์โดยทั่วไป แต่ไม่เกี่ยวข้องกับคำถาม "hairpin NAT" คำตอบที่ยอมรับได้นำเสนอ MASQUERADE บนอินเทอร์เฟซ LAN และคุณเสนอ SNAT แทน ( SNAT นั้นใกล้เคียงกับ MASQUERADE ) คุณบังคับ IP ต้นทางที่ค่อนข้างแปลก: การแทนที่พอร์ต
— kubanczyk
0

ฉันจะเพิ่มคำตอบที่นี่เนื่องจากความคิดเห็นที่นี่ไม่ได้แก้ปัญหาเฉพาะของฉัน ฉันสงสัยว่าเป็นเพราะฉันตีเคอร์เนลลินุกซ์ที่น่ารังเกียจ การตั้งค่าคือ:

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 ----------/
        +----------------------+

แม้จะมีรูปลักษณ์ที่ซับซ้อนการเปลี่ยนแปลงที่เกี่ยวข้องกับสถานการณ์ที่กล่าวถึงในความคิดเห็นอื่นเท่านั้นคือการเพิ่มบริดจ์ซอฟต์แวร์ br0 มีเพราะกล่องเกตเวย์เป็นจุดเชื่อมต่อไร้สายสำหรับ LAN

กล่องเกตเวย์ของเรายังคงทำหน้าที่ NAT สำหรับเครื่องบน LAN เนื่องจากมีพอร์ตอีเธอร์เน็ตเพียง 1 พอร์ตเท่านั้นจึงจำเป็นต้องทำกิ๊บ NAT ฉันสงสัยว่ามันควรจะทำงานกับกฎ iptables ที่ให้ไว้ในความคิดเห็นอื่น ๆ ที่นี่ แต่ใน Linux kernel 4.9 อย่างน้อยก็ไม่ได้ ภายใต้ 4.9 ของเราในขณะที่กล่องเกตเวย์ของเราสามารถเข้าถึงอินเทอร์เน็ตเครื่องบน LAN ที่พยายามเข้าถึงผ่าน NAT ไม่สามารถทำได้

tcpdumpแสดงการตอบสนองต่อแพ็กเก็ตที่เข้ามาซึ่งกดปุ่ม eth0 แต่มันไม่ได้ทำให้มันออกมาจาก br0 การรันคำสั่งนี้แก้ไขว่า:

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

ก่อนที่คำสั่งนั้นจะถูกเรียกใช้แพ็กเก็ตที่เข้ามาจะถูกประมวลผลตามลักษณะการทำงานเริ่มต้นของเมล็ดซึ่งจะมอบให้กับบริดจ์จากนั้นส่งผ่านโมดูลการกำหนดเส้นทางของเคอร์เนล คำสั่งบังคับให้แพ็กเก็ตที่ไม่ได้มาจาก LAN เพื่อข้ามบริดจ์และไปยังการกำหนดเส้นทางโดยตรงซึ่งหมายความว่าบริดจ์จะไม่ได้รับโอกาสให้วาง ที่อยู่ในการออกอากาศและมัลติคาสต์จะต้องเชื่อมโยงมิฉะนั้นสิ่งต่าง ๆ เช่น DHCP และ mDNS จะไม่ทำงาน ถ้าคุณใช้ IPv6 คุณต้องเพิ่มกฎให้ด้วย

คุณอาจถูกล่อลวงให้แก้ไขปัญหาโดยใช้สิ่งนี้:

brctl hairpin br0 eth0 on
brctl hairpin br0 wlan0 on

ฉันถูกล่อลวงอย่างแน่นอน - มันเป็นความพยายามครั้งแรกของฉัน ทันทีที่ฉันทำมันบนเครื่อง LAN ก็สามารถเข้าถึงอินเทอร์เน็ตได้ดังนั้นจึงใช้งานได้สักพัก จากนั้นมีสิ่งต่อไปนี้เกิดขึ้น (และฉันไม่สนใจที่จะทำการทดสอบซ้ำ):

  1. Ping เวลาข้าม LAN ไปยังเกตเวย์เพิ่มขึ้นเป็นสองเท่าในช่วงเวลาประมาณ 10 วินาทีเพิ่มขึ้นจาก 0.1ms เป็น 0.2ms, 0.4ms, 0.8ms, 2ms และต่อไปเรื่อย ๆ จนกว่ากล่องเกตเวย์จะไม่สามารถเข้าถึงได้จาก LAN มันมีกลิ่นเหมือนพายุแพ็คเก็ต แต่ STP เปิดอยู่ทุกที่
  2. ไม่นานหลังจากที่จุดเชื่อมต่อไร้สายทั้งหมดเสียชีวิต
  3. ในขณะที่พยายามวินิจฉัยสิ่งที่เกิดขึ้นกับระบบไร้สายโทรศัพท์ IP ทุกเครื่องจะรีบูต
  4. หลังจากนั้นไม่นานเครื่องสายเสียการติดต่อกับ LAN ทั้งหมด

ทางออกเดียวคือรีบูตเครื่องทุกเครื่องในอาคาร ข้อยกเว้นเดียวคือสวิตช์ฮาร์ดแวร์ซึ่งไม่สามารถรีบูตได้ พวกเขาจะต้องขี่จักรยานพลังงาน

— รัสเซลล์สจวร์ต
แหล่งที่มา
0

มันเป็นคำถามของบัญญัติ ฉันจะตอบถ้าคุณมีเราเตอร์ Sonicwall

นิพจน์ที่ควรทราบคือนโยบายย้อนกลับของ NAT

เอกสารนี้อธิบายถึงวิธีการโฮสต์บน SonicWall LAN สามารถเข้าถึงเซิร์ฟเวอร์บน SonicWall LAN โดยใช้ที่อยู่ IP สาธารณะของเซิร์ฟเวอร์เพื่อ FQDN ลองนึกภาพเครือข่าย NSA 4500 (SonicOS Enhanced) ซึ่ง Subnet LAN หลักคือ 10.100.0.0 / 24 และ IP WAN หลักคือ 3.3.2.1 สมมติว่าคุณมีเว็บไซต์สำหรับลูกค้าของคุณและชื่อโฮสต์ของเว็บไซต์นั้นคือ คุณได้เขียนนโยบายและกฎระเบียบที่จำเป็นเพื่อให้บุคคลภายนอกสามารถเข้าถึงเว็บไซต์ได้ แต่มันทำงานบนเซิร์ฟเวอร์ส่วนตัวด้านที่ 10.100.0.2 ตอนนี้ลองนึกภาพว่าคุณเป็นคนที่ใช้แล็ปท็อปในด้านความเป็นส่วนตัวด้วย IP ที่ 10.100.0.200 คุณต้องการเข้าถึงเซิร์ฟเวอร์โดยใช้ชื่อสาธารณะเพราะคุณทำสิ่งเดียวกันเมื่อแล็ปท็อปของคุณอยู่บนท้องถนน หากคุณนั่งบนฝั่งส่วนตัวและขอhttp://www.example.com>, loopback คือสิ่งที่ทำให้การทำงานนั้นเป็นไปได้แม้ว่าเซิร์ฟเวอร์นั้นจะอยู่ติดกับคุณในที่อยู่ IP ท้องถิ่น

เพื่อให้สามารถใช้งานฟังก์ชั่นนี้ได้คุณจะต้องสร้างนโยบายการย้อนกลับของ NAT หรือที่เรียกว่า NAT reflection หรือกิ๊บ

นโยบายลูปแบ็คโดยใช้ที่อยู่ IP ของ WAN Interface

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 จะรับรู้บริการภายนอกที่คุณพยายามติดต่อและจะเขียนที่อยู่ปลายทางใหม่เพื่อให้พอดีกับที่อยู่ของเซิร์ฟเวอร์ภายในดังนั้นจึงมีความโปร่งใสในคอมพิวเตอร์

— yagmoth555
แหล่งที่มา
-2

ใน FreeBSD โดยใช้ PF เป็นเรื่องง่ายเหมือน (ในไฟล์ pf.conf ของคุณ):

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

192.168.20.8 จะเป็นเว็บเซิร์ฟเวอร์ภายใน

— อ็อตโต
แหล่งที่มา
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.