เหตุใดองค์กรไม่มากขึ้นจึงใช้ NAT จากภายในสู่ภายในหรือโซลูชันที่คล้ายกันเพื่ออนุญาตให้แฮร์คิท NAT

22

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

จากประสบการณ์ของฉันผู้ดูแลระบบ / วิศวกรเครือข่ายต้องการให้ผู้ใช้ระบบต่าง ๆ เรียกใช้ split-dns แทนที่จะกำหนดค่าไฟร์วอลล์ของพวกเขาเพื่อจัดการกับ NAT hairpins อย่างเหมาะสม ทำไมนี้

networking  nat 
— MDMarra
แหล่งที่มา
อาจเป็นเพราะมุมมอง DNS ง่ายต่อการแก้ไขปัญหา
— NickW
2
อาจเป็นไปได้ แต่เมื่อใช้ DNS ในมุมมอง Domain Controllers (สถานการณ์ทั่วไป) ไม่มีอยู่
— MDMarra
2
ทำไมคุณต้องเผยแพร่โซนโฆษณาของคุณไปยังอินเทอร์เน็ต หากโฆษณาของคุณad.example.comคล้ายกัน (เช่นควรเป็น!) ปัญหานี้จะมีอยู่สำหรับexample.comรายการ DNS สาธารณะทั้งหมดและไม่มีการเผยแพร่ภายในใด ๆ จากภายนอก แน่นอนว่าถ้าคุณตั้งชื่อโฆษณาของคุณเหมือนกับการแสดงต่อสาธารณะคุณต้องใช้ split-DNS แต่นั่นไม่ใช่วิธีที่ดีที่สุดในการออกแบบโฆษณา
— MDMarra
5
ฉันต้องการเพิ่มว่ามุมมอง DNS เป็นเพียงง่ายต่อการแก้ไขปัญหาถ้าลูกค้าไม่เคยย้ายไปมาระหว่างพวกเขา สิ่งผิดปกติอย่างผิดปกติเมื่อลูกค้านำผลภายในแคชออกไป
— LapTop006
3
ลูกค้าไม่ควรแคช DNS คำตอบว่าเป็นสิ่งที่ DNS เซิร์ฟเวอร์มีการ ฉันรู้ว่า Windows ชื่นชอบการแคช (และร้ายแรง) อย่างเงียบ ๆ แต่นั่นเป็นหนึ่งในหลาย ๆ เหตุผลที่ฉันคิดว่ามันไม่เหมาะสำหรับการใช้งานจริง
— MadHatter สนับสนุน Monica

คำตอบ:

11

มีสาเหตุบางประการที่ทำให้ฉันไม่ทำ:

  • ทำไมต้องเครียดเป็นพิเศษในเราเตอร์และไฟร์วอลล์ DMZ หากคุณไม่ต้องการ? บริการภายในของเราส่วนใหญ่ไม่ได้อยู่ใน DMZ แต่เป็นพื้นที่ของ บริษัท ทั่วไปพร้อมบริการพร็อกซี่ใน DMZ สำหรับการเข้าถึงระยะไกลเป็นครั้งคราว การทำจากภายในสู่ด้านในเพิ่มน้ำหนักให้กับ DMZ มากขึ้นซึ่งในกรณีของเราจะมีความสำคัญ
  • หากคุณไม่ทำ DNAT + SNAT คุณจะได้รับการกำหนดเส้นทางแบบไม่เชิงเส้นซึ่งเป็นการยากที่จะทำให้ถูกต้อง ดังนั้นคุณ SNAT และสูญเสียข้อมูล IP ของแหล่งที่มา อย่างไรก็ตามมีประโยชน์อย่างยิ่งในการเชื่อมโยงแหล่ง IP กับบุคคลเพื่อการแก้ไขปัญหา หรือเป็นครั้งคราวเพื่อวัตถุประสงค์ nerfshooting ในกรณีที่โง่เขลา "นี่ IP นี่กำลังทำบางสิ่งที่แปลกใหม่ในบริการ X ที่ไม่ผ่านการตรวจสอบสิทธิ์" "เรามาดูในบันทึกเซิร์ฟเวอร์ของ imap ว่าเป็นใคร"
— เดนนิสคาร์เซเมเกอร์
แหล่งที่มา
2
เพียงแค่ทราบหากไฟร์วอลล์ของคุณกำลังทำเส้นทาง L3 และคุณมีเส้นทางของคุณสำหรับลูกค้าภายนอกและภายในของคุณจะกระโดดขึ้นไปบนไฟร์วอลล์คุณไม่ควรกังวลเกี่ยวกับการกำหนดเส้นทางแบบไม่สมมาตรใช่ไหม
— MDMarra
12

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

  1. ความสง่างาม: NAT ไม่ได้สวยงามมากที่เริ่มต้นด้วย แต่ความจำเป็นของพื้นที่ที่อยู่ที่ จำกัด ของ IPv4 ถ้าฉันสามารถหลีกเลี่ยง NAT ฉันจะ ด้วย IPv6 ปัญหาจะหายไปในอัตราใด
  2. ความซับซ้อน: โดยเฉพาะอย่างยิ่งในกรณีที่คุณไม่มีเราเตอร์ "คอร์" เดียวที่สร้างขอบเขตความปลอดภัยทั้งหมดของคุณการกำหนดค่าตัวกรองอาจกลายเป็นเรื่องยุ่งยาก ไม่ว่าคุณจะต้องแพร่กระจายและรักษากฎ NAT ในอุปกรณ์เราเตอร์ของคุณเกือบทั้งหมด
  3. การอ้างอิง: ไม่ว่าผู้ดูแลระบบไฟร์วอลล์จะแตกต่างจากผู้ดูแลระบบเซิร์ฟเวอร์คนอื่น ๆ พวกเขาอาจเข้าถึงได้ยาก เพื่อให้แน่ใจว่าการเปลี่ยนแปลงไม่ได้เกิดจากการค้างของผู้ดูแลระบบไฟร์วอลล์ (หรือวันหยุดพักผ่อน) ตัวเลือกในการรักษาความรับผิดชอบในทีมเดียวกันจะถูกเลือก
  4. ความสะดวกในการพกพาและการใช้งานทั่วไป: การใช้มุมมอง DNS คือ "สิ่งที่ทุกคนรู้จะทำ" เพื่อแก้ปัญหานี้ ไม่ใช่เราเตอร์ที่มีขอบเขตทุกตัวที่จะรองรับการวนรอบ NAT ในวิธีที่ตรงไปตรงมามีคนน้อยกว่าที่จะรู้วิธีตั้งค่าอย่างถูกต้องในสภาพแวดล้อมเฉพาะของคุณ เมื่อแก้ไขปัญหาเครือข่ายลูกเรือจะต้องตระหนักถึงการกำหนดค่า NAT ของกิ๊บและผลกระทบทั้งหมด - แม้เมื่อพวกเขากำลังไล่ล่าปัญหาที่ไม่เกี่ยวข้องอย่างเห็นได้ชัด
— ที่ Wabbit
แหล่งที่มา
1
1. ในสถานการณ์นี้กำลังใช้ NAT อยู่แล้ว นี่ไม่ได้เป็นการเพิ่ม NAT โดยที่ไม่เคยมี NAT มาก่อน 2 ในตัวอย่างของฉันมันถูกจัดการโดยอุปกรณ์หรือกลุ่มอุปกรณ์เดียวกัน 4. ตามที่ระบุไว้ในความคิดเห็นของฉันข้างต้นสถานการณ์ที่พบบ่อยมากคือการใช้ตัวควบคุมโดเมนโฆษณาสำหรับ DNS ภายใน Windows DNS ไม่รองรับมุมมอง นอกจากนี้ฉันยังพบว่าเฟิร์มแวร์เราเตอร์ / ไฟร์วอลล์ที่ค่อนข้างทันสมัยรองรับแฮร์ไพน์ผมไม่ทางใดก็ทางหนึ่ง
— MDMarra
1
@Marra คำพูดบางอย่าง: 1. - "จะมี NAT แปลกหนึ่งที่น้อยกว่าที่จะสนใจ" เป็นสิ่งที่ฉันหมายถึงโดยทั่วไป 2 - คำถามของคุณไม่ได้พูดอย่างชัดเจน แต่มีเพียงเราเตอร์เดียวแน่นอนจะง่ายต่อการจัดการ , 4. ด้วย DNS ภายในที่ใช้บังคับกับไคลเอนต์ทั้งหมดคุณไม่จำเป็นต้องมีมุมมอง - คุณเพียงแค่สร้างเขตภายในและรับผลเช่นเดียวกับที่คุณพูดถึงในคำถามของคุณเหตุผลข้างต้นยังคงใช้อยู่
— the-wabbit
1
สิ่งที่แปลกประหลาด NAT แม้ว่า? พฤติกรรมแบบใดที่แนะนำนี้ที่ทำให้เกิดปัญหา? ฉันทำงานในมหาวิทยาลัยที่มีการกำหนดค่า NAT hairpinning ในคลัสเตอร์ Netscreen สำหรับโฮสต์ภายนอก 100+ แห่งและเราไม่เคยมีปัญหา
— MDMarra
โปรดทราบด้วยว่าการใช้กิ๊บ NAT ในสถานการณ์นี้ทำให้ดูเหมือนโซลูชั่น IPv6 มากขึ้นเนื่องจากภายใต้ IPv6 ระบบจะมีที่อยู่หนึ่งที่เข้าถึงได้ทั่วโลก กิ๊บ NAT จำลองพฤติกรรมดังกล่าว
— พอลเกียร์
@MDMarra "NAT weirdness" ที่โดดเด่นที่สุดสำหรับกรณี "hairpin NAT" จะเป็นเส้นทางที่ไม่เหมาะสมที่สุดซึ่งหมายความว่าแพ็กเก็ตที่เขียนใหม่จะต้องเดินทางเส้นทางส่วนใหญ่ที่พวกเขากลับมา เห็นสิ่งนี้ในการถ่ายโอนข้อมูลแพ็คเก็ตเมื่อการแก้ไขปัญหาการเชื่อมต่อจะสับสนที่ดีที่สุด ฉันเชื่อว่าคนอื่น ๆ ได้กล่าวถึงปัญหาเส้นทางไม่สมมาตรแล้วในคำตอบของพวกเขาซึ่งเกี่ยวข้องกัน ไม่ต้องสงสัยเลยว่าคุณสามารถทำให้มันใช้งานได้ดี แต่มันก็ไม่คุ้มค่ากับความพยายามในกรณีส่วนใหญ่ IMO
— the-wabbit
7

คำปฏิเสธ - นี่คือคำตอบ flamebait

สาเหตุส่วนใหญ่ที่ผมคิดว่าการแก้ปัญหาเช่นนี้จะหลีกเลี่ยงคือกลัวไม่มีเหตุผล / ความเกลียดชังของ NAT ในส่วนของวิศวกรเครือข่าย หากคุณต้องการดูตัวอย่างของการสนทนาเกี่ยวกับเรื่องนี้ลองดูสิ่งเหล่านี้:

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

ไปที่นั่น - ลงคะแนนไปที่เนื้อหาหัวใจของคุณ! :-)

— พอลเกียร์
แหล่งที่มา
1
ฉันไม่รู้ว่าฉันคิดว่ามันเป็นความกลัวอย่างไม่มีเหตุผลหรือไม่ ประสบการณ์สอนฉันว่า NAT สามารถทำลายหรือทำสิ่งแปลก ๆ ได้หลายอย่าง
1
@Kce แต่ถ้าคุณใช้ NAT บนอินเทอร์เฟซภายนอกของคุณแล้วการกำหนดค่า NAT loopback จะมีความแตกต่างกันอย่างไร
— MDMarra
@MDMarra - ไม่มีจริงๆ ฉันกำลังทำให้จุดอวดรู้ที่บางครั้งความกลัวของทีมบริการเครือข่ายของ NAT ไม่ได้ไม่มีเหตุผล
ฉันไม่ได้กลัว NAT ฉันเกลียดมัน
— Michael Hampton
1
โพสต์ที่แก้ไขเพื่อรวมความเกลียดชัง :-)
— พอลเกียร์
3

ฉันเดาว่า:

  1. การแบ่ง DNS นั้นเข้าใจได้ง่ายกว่า
  2. NAT Hairpin ใช้ทรัพยากรบนเราเตอร์ในขณะที่ Split-DNS ไม่ได้
  3. เราเตอร์อาจมีข้อ จำกัด แบนด์วิดท์ที่คุณไม่ได้รับผ่านการตั้งค่าแบบแยกส่วน
  4. Split-dns จะทำงานได้ดีขึ้นในขณะที่คุณหลีกเลี่ยงขั้นตอนการเราต์ / NAT

ด้านบวกสำหรับกิ๊บ NAT

  • เมื่อติดตั้งแล้วมันก็ใช้งานได้
  • ไม่มีปัญหากับแคช DNS สำหรับแล็ปท็อปที่ย้ายระหว่างเครือข่ายทำงานและอินเทอร์เน็ตสาธารณะ
  • DNS สำหรับเซิร์ฟเวอร์ได้รับการจัดการในที่เดียวเท่านั้น

สำหรับเครือข่ายขนาดเล็กที่มีปริมาณการรับส่งข้อมูลต่ำไปยังเซิร์ฟเวอร์ภายในฉันต้องการใช้กิ๊บ NAT สำหรับเครือข่ายขนาดใหญ่ที่มีการเชื่อมต่อกับเซิร์ฟเวอร์จำนวนมากและมีความสำคัญของแบนด์วิดท์และเวลาแฝงให้ไปที่ split-dns

— ด้าน
แหล่งที่มา
2

จากมุมมองของฉันสิ่งนี้เปลี่ยนไปเล็กน้อยระหว่างการเปลี่ยน Cisco Pix เป็น ASA สูญเสียaliasคำสั่ง และโดยทั่วไปการเข้าถึงที่อยู่ภายนอกจากอินเทอร์เฟซภายในบนไฟร์วอลล์ของ Cisco ต้องใช้กลอุบายบางอย่าง ดู: ฉันจะเข้าถึงเซิร์ฟเวอร์ภายในของฉันบน IP ภายนอกได้อย่างไร

แม้ว่าเราไม่จำเป็นต้องดูแลโซน DNS ภายในซ้ำกันเสมอไป Cisco ASA สามารถเปลี่ยนเส้นทางการสืบค้น DNS สำหรับที่อยู่ภายนอกไปยังที่อยู่ภายในหากกำหนดค่าไว้ในคำสั่ง NAT แต่ฉันต้องการเก็บโซนภายในไว้สำหรับโซน DNS สาธารณะเพื่อให้มีความละเอียดและสามารถจัดการสิ่งนี้ได้ในที่เดียวแทนที่จะก้าวไปยังไฟร์วอลล์

โดยทั่วไปมีเพียงไม่กี่เซิร์ฟเวอร์ที่อาจต้องใช้สิ่งนี้ในสภาพแวดล้อม (อีเมล, เว็บ, บริการสาธารณะไม่กี่แห่ง) ดังนั้นจึงไม่มีปัญหาใหญ่หลวง

— ewwhite
แหล่งที่มา
มันเป็นเรื่องยุ่งยากหรือไม่ถ้าซิสโก้สนับสนุนและจัดทำเอกสาร ? แน่นอนว่ามันใช้งานได้มากกว่าเดิมเล็กน้อย แต่นั่นทำให้มันยุ่งยากหรือแฮ็ค?
— MDMarra
เล่ห์เหลี่ยมในที่คนไม่รู้ / คาดหวัง / คิดเกี่ยวกับมันหากพวกเขาไม่ได้ตระหนักถึง เป็นคำถามที่พบบ่อย: ฉันจะเข้าถึง IP ภายนอกจากภายในไฟร์วอลล์ของ Ciscoได้อย่างไร
— ewwhite
Typically, there are only a few servers that may require this within an environmentอาจจะอยู่ในบางสถานที่ แต่ฉันทำงานในมหาวิทยาลัยที่มีเซิร์ฟเวอร์ / อุปกรณ์มากกว่า 100 แห่งใน DMZ และฉันยังทำงานที่ผู้ให้บริการทดสอบ / ออกใบรับรองด้วยเซิร์ฟเวอร์ 40+ ที่กระจายอยู่ทั่วทั้งสาม DMZ สำหรับ บริษัท ขนาดเล็กคุณอาจมีเซิร์ฟเวอร์เพียงหนึ่งหรือสองเซิร์ฟเวอร์ที่เปิดเผยจากภายนอก
— MDMarra
หากเซิร์ฟเวอร์อยู่ใน DMZ นี่เป็นปัญหาน้อยใช่ไหม?
— ewwhite
ในอินสแตนซ์นี้ "DMZ" หมายถึงการเชื่อมต่อกับอินเทอร์เฟซภายนอกของไฟร์วอลล์ดังกล่าวพร้อมกับกฎการปฏิเสธเริ่มต้นระหว่างโซนที่มีอยู่
— MDMarra
2

ฉันนึกถึงเหตุผลสองสามข้อ:

  1. องค์กรจำนวนมากได้แยก DNS แล้วเนื่องจากไม่ต้องการเผยแพร่ข้อมูล DNS ภายในของพวกเขาทั้งหมดไปทั่วโลกดังนั้นจึงไม่ใช่ความพยายามเพิ่มเติมในการจัดการกับเซิร์ฟเวอร์จำนวนน้อยที่ถูกเปิดเผยผ่าน IP สาธารณะ
  2. ในขณะที่องค์กรและเครือข่ายมีขนาดใหญ่ขึ้นพวกเขามักแยกระบบที่ให้บริการคนภายในออกจากเซิร์ฟเวอร์ที่ให้บริการภายนอกดังนั้นการกำหนดเส้นทางไปยังบุคคลภายนอกเพื่อการใช้งานภายในอาจเป็นเส้นทางเครือข่ายที่ยาวกว่ามาก
  3. การแก้ไขน้อยลงที่อุปกรณ์สื่อกลางทำกับแพ็คเก็ตยิ่งดีเมื่อมันมาถึงเวลาแฝงเวลาตอบสนองโหลดอุปกรณ์และการแก้ไขปัญหา
  4. (น้อยมากเป็นที่ยอมรับ) มีโปรโตคอลที่ NAT จะยังคงพังหากอุปกรณ์ NATing ไม่ได้อยู่เหนือส่วนหัวของแพ็กเก็ตและแก้ไขข้อมูลในนั้นด้วยที่อยู่ IP ใหม่ แม้ว่ามันจะเป็นเพียงความทรงจำเชิงสถาบัน แต่ก็ยังเป็นเหตุผลที่ถูกต้องสำหรับคนที่จะหลีกเลี่ยงมันโดยเฉพาะอย่างยิ่งหากพวกเขากำลังจัดการกับโปรโตคอลที่พวกเขาไม่แน่ใจ 100% เกี่ยวกับ
— เจดแดเนียลส์
แหล่งที่มา
0

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

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

— เคนต์ประเทศอังกฤษ
แหล่งที่มา
ขออภัยฉันอาจเข้าใจผิดในสิ่งที่คุณพูด แต่ที่อยู่ RFC1918 ไม่ได้ถูกส่งผ่านทางอินเทอร์เน็ตดังนั้นฉันไม่เห็นสิ่งที่พยายามหลอกลวงพวกเขาข้าม WAN ว่าจะทำอย่างไร พวกเขาไม่แม้แต่จะกระโดดครั้งแรก
— MDMarra
ที่อยู่ปลายทางคือที่อยู่สาธารณะของ NAT บนพอร์ตที่แมปกับเซิร์ฟเวอร์ ที่อยู่แหล่งที่มาเป็นหนึ่งในที่อยู่ IP ส่วนตัวด้านในของ NAT ที่อยู่แหล่งที่มาไม่ได้ใช้ในการกำหนดเส้นทางและไม่ได้ตรวจสอบโดยเราเตอร์สาธารณะทุกเครื่อง ข้อแตกต่างจากการสืบค้นภายในที่ถูกต้องคือแพ็คเก็ตมาจาก WAN
— Kent England
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.