Tắt ARP có làm hỏng VPN của bạn? Có thể, ở chặng ngoài

{Hai gói tin đi trong cùng một kết nối và tuân theo những quy tắc khác nhau. Một là gói riêng tư mà đường hầm chở, được giao diện ảo xử lý mà không cần bất kỳ tiêu đề Ethernet nào. Gói kia là gói đã mã hóa rời khỏi máy qua liên kết truy cập, và nó vẫn cần một chặng kế tiếp cục bộ được phân giải thành địa chỉ phần cứng. Nhầm lẫn hai thứ này là cách người ta tắt phân giải địa chỉ trên sai giao diện rồi thắc mắc tại sao đường hầm không bao giờ khởi động.}

{Một gói trong gói khác, hai mô hình chuyển giao}

{Giao diện ảo ở chế độ định tuyến nhận các gói IP. Nó không có tiêu đề Ethernet, không có miền quảng bá và không có địa chỉ nào để phân giải bên trong, nên gói bên trong do chính đường hầm chuyển giao. Những gì xảy ra trên mạng truy cập là một tầng chuyển giao riêng.}

inner packet: private address -> tunnel device -> the VPN process
outer packet: endpoint address -> access route -> next-hop hardware address

{Gói ngoài đó là một khung unicast thông thường khi rời giao diện Ethernet, và nó cần địa chỉ phần cứng đích của chặng kế tiếp. Phân giải địa chỉ cung cấp địa chỉ đó, và chặng kế tiếp thường là cổng mặc định cục bộ chứ không phải máy chủ từ xa. Hiểu rằng việc tra cứu dành cho cổng chứ không phải cho điểm cuối chính là phần lớn của chẩn đoán. Ghi lại cả hai địa chỉ trước khi thay đổi bất cứ điều gì.}

{Tìm người hàng xóm thực sự quan trọng}

{Hỏi bảng định tuyến xem điểm cuối dùng chặng kế tiếp nào, rồi kiểm tra bảng hàng xóm cho chặng đó. Bản thân điểm cuối hiếm khi xuất hiện ở đó, vì nó không nằm trên liên kết cục bộ.}

ip route get 198.51.100.20
ip neigh show 192.168.0.1

{Nếu mục đó có mặt và có thể tới được, đường ngoài vẫn ổn và lỗi nằm ở chỗ khác. Nếu thiếu hoặc đang ở trạng thái lỗi, nơi cần xem là liên kết, địa chỉ cổng hoặc một chính sách chặn phân giải. Thay đổi thiết lập mật mã trên đường hầm không thể giúp trong cả hai trường hợp. Ghi lại chuỗi trạng thái mà bảng hàng xóm báo cáo, vì nó phân biệt một lần thử đang diễn ra với một lỗi vĩnh viễn.}

{Một mục đã học có thể che giấu sự phụ thuộc}

{Một mục được lưu trong bộ nhớ đệm vẫn hoạt động một thời gian sau khi thứ tạo ra nó biến mất, nên một bài kiểm tra vài phút sau khi thay đổi có thể đạt vì lý do sai. Hãy chờ mục đó hết hạn, hoặc xóa nó một cách có chủ ý, trước khi kết luận rằng phân giải là không cần thiết.}

{Lỗi ngược lại cũng phổ biến không kém: một mục chưa phân giải được coi là bằng chứng rằng đường hầm đã hỏng. Trên thực tế nó chỉ vào đoạn mạng cục bộ, một địa chỉ trùng lặp hoặc một quy tắc bảo mật cổng loại bỏ các khung chở câu trả lời. Kiểm tra cổng chuyển mạch trước khi chạm vào cấu hình VPN.}

{Đọc thời gian như bằng chứng. Một mục phân giải được rồi hết hạn lặp lại gợi ý một liên kết chập chờn hoặc hai thiết bị cùng trả lời cho một địa chỉ, trong khi một mục không bao giờ phân giải được chỉ vào địa chỉ cổng hoặc việc lọc trên cổng truy cập.}

{Quyết định giữa phân giải động và một mục cố định}

{Phân giải động là mặc định vì một lý do: nó đi theo phần cứng khi cổng bị thay thế và không cần phối hợp với ai. Một mục tĩnh có thể biện hộ được khi mạng được quản lý có chủ ý và việc ghép địa chỉ với địa chỉ phần cứng là một phần của thiết kế có tài liệu.}

{Dù thế nào, hãy áp dụng lựa chọn cho giao diện truy cập chở gói ngoài. Tắt phân giải trên giao diện đó không làm đường hầm vững chắc hơn; nó lấy đi khả năng của máy khách trong việc tới được cổng chở đường hầm, và sự cố trông như một VPN đã chết chứ không phải vấn đề địa chỉ cục bộ.}

{Ghi nhớ ngăn xếp còn lại}

{IPv6 không dùng phân giải địa chỉ theo cùng hình thức; nó dùng khám phá hàng xóm. Câu hỏi theo tầng vẫn không đổi: gói ngoài thực sự tới một chặng kế tiếp cục bộ bằng cách nào, và điều gì chứng minh câu trả lời là hiện thời.}

{Kiểm tra cùng hai sự thật đó trên ngăn xếp còn lại trước khi tuyên bố thiết kế hoàn tất, vì một đường hầm chở cả hai họ giao thức có hai đường ngoài cần xem xét. Ghi lại bạn đã xác minh đường nào và đã giả định đường nào.}