แก้ไขการชนกันของที่อยู่ IP ภายในหลังเชื่อมต่อ VPN

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

สามความผิดพลาดที่ใช้ข้อความแจ้งข้อผิดพลาดเดียวกัน

ตัวซ้ำหมายถึงเครื่องสองเครื่องในเซกเมนต์เดียวกันต่างอ้างที่อยู่เดียวกัน เคอร์เนลสังเกตได้เพราะคำตอบต่อโพรบของมันเองมาจาก MAC อีกตัว และสิ่งที่เกิดขึ้นต่อไปขึ้นอยู่กับสแตก: Linux บันทึกไว้ในล็อก Windows ปิดใช้งานอินเทอร์เฟซและเขียนรายการในล็อกระบบ และไคลเอนต์ DHCP อาจปฏิเสธข้อเสนอ

การทับซ้อนไม่ทำให้ที่อยู่ใดซ้ำเลย LAN ของคุณคือ 192.168.1.0/24 เครือข่ายสำนักงานก็คือ 192.168.1.0/24 และตอนนี้เส้นทางไปสำนักงานชี้ไปยังที่อยู่ที่เป็นทั้งเครื่องพิมพ์และ NAS ของคุณ ไม่มีอะไรขัดแย้งในความหมายของ ARP แพ็กเก็ตเพียงแต่ไปยังอุปกรณ์ผิดตัวในหนึ่งในสองเครือข่าย

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

ทดสอบ 1: ตัวซ้ำอยู่บนเซกเมนต์ของคุณเองหรือไม่

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

ip -br addr
ip neigh
ip route show table all | grep -E 'wg|tun|ppp'

บน Windows ข้อมูลเดียวกันมาจาก ipconfig /all และ Get-NetIPAddress โดยมีแคชเพื่อนบ้านอยู่ใน arp -a ถ้าที่อยู่ที่โต้แย้งอยู่บนอะแดปเตอร์จริงและอาการปรากฏขึ้นโดยที่ VPN ไม่ได้ทำงาน แสดงว่า VPN เป็นเพียงผู้สังเกต และคุณควรหยุดวินิจฉัยมัน

เพื่อพิสูจน์ตัวซ้ำแทนการเดา ให้โพรบที่อยู่จากอุปกรณ์ที่ไม่ได้เป็นเจ้าของ arping -D ส่งโพรบด้วยที่อยู่ต้นทางเป็นศูนย์ คำตอบจาก MAC ที่ไม่คาดคิดจึงพิสูจน์ว่าโฮสต์อื่นตอบที่อยู่นั้นอยู่แล้ว

sudo arping -D -I eth0 -c 3 192.168.1.50

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

ทดสอบ 2: สองเครือข่ายทับซ้อนกันหรือไม่

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

ip route get 192.168.1.10
ip -br addr show

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

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

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

ทดสอบ 3: ทันเนลแจกที่อยู่เดียวสองครั้งหรือไม่

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

wg show all allowed-ips
wg show wg0 latest-handshakes
wg show wg0 transfer

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

OpenVPN มีพูล และการชนกันที่พบบ่อยคือโปรไฟล์ไคลเอนต์ที่ใช้ร่วมกันซึ่งมีบรรทัด --ifconfig แบบตายตัวถูกคัดลอกไปยังเครื่องที่สอง ไคลเอนต์ทั้งสองจึงขอที่อยู่ทันเนลเดียวกัน และเซิร์ฟเวอร์ยอมรับเซสชันที่ประมวลผลก่อน การใช้พูลจนหมดด้วย --duplicate-cn ให้ผลคล้ายกันเมื่อหลายเซสชันของใบรับรองเดียวแย่งชิงรายการเดียว

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

ซ่อมที่ต้นเหตุ แล้วตรวจสอบอุปกรณ์ทั้งสองอีกครั้ง

ลำดับสำคัญ ให้แก้ตัวซ้ำใน LAN ก่อน เพราะไคลเอนต์ที่รักษาที่อยู่ไม่ได้ก็รักษาทันเนลไม่ได้เช่นกัน จากนั้นแก้การจัดสรรฝั่ง VPN เพราะการแก้ไขการกำหนดจากพูลฝั่งไคลเอนต์จะถูกย้อนกลับเมื่อเชื่อมต่อครั้งถัดไป สุดท้ายจัดการตัวตนที่ซ้ำกัน: คู่คีย์แยกกันบน WireGuard ใบรับรองแยกกัน หรืออย่างน้อยโปรไฟล์แยกกันบน OpenVPN

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

sudo dhclient -r eth0 && sudo dhclient eth0
ipconfig /release && ipconfig /renew

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

สิ่งที่ไม่ควรทำระหว่างทาง

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

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