Mất Ping trên VPN: nhóm các yêu cầu Echo trước khi tính phần trăm

Một bản ghi có sáu yêu cầu Echo và ba phản hồi, và ai đó viết mất 50 phần trăm gói trong phiếu. Con số đó có thể đúng cho bản ghi và sai cho đường hầm. Sáu yêu cầu có thể thuộc hai cuộc trò chuyện khác nhau với hai hợp đồng giao hàng khác nhau. Hãy nhóm chúng trước khi chia, và tỷ lệ không còn là phần thú vị của báo cáo.

Bước 1: tách các luồng theo nguồn và đích

Một yêu cầu Echo mang một nguồn và một đích, và hai trường đó xác định nó thuộc cuộc trò chuyện nào. Đầu dò do cổng tạo ra dùng địa chỉ đường hầm của cổng, trong khi đầu dò được chuyển tiếp thay mặt một máy chủ LAN giữ địa chỉ của máy chủ đó. Phía xa có thể có tuyến trả về cho cái này mà không có cho cái kia, khiến hai nhóm hành xử khác nhau vì những lý do không liên quan đến đường hầm.

Chia bản ghi theo các trường đó trước khi đếm bất cứ thứ gì, và giữ đích như một phần của khóa. Hai luồng đến các đối tác khác nhau không thể so sánh ngay cả khi chúng chia sẻ nguồn.

Ghi lại các nhóm cùng số lượng của chúng, vì bước tiếp theo quyết định phản hồi nào thuộc nhóm nào. Một nhóm có ba yêu cầu và không có phản hồi khớp là một phát hiện. Một nhóm có ba yêu cầu và ba phản hồi là đường cơ sở.

Bước 2: khớp theo định danh và trình tự

Định dạng Echo trong RFC 792 mang một định danh và một số thứ tự, và coi chúng là các trường ghép một phản hồi với yêu cầu của nó. Cả hai đều cần cho việc đó. Chỉ số thứ tự không duy nhất, vì những người gửi hoặc tiến trình khác nhau có thể dùng lại cùng một giá trị trong một cửa sổ bắt gói. Định danh thu hẹp người gửi và trình tự thu hẹp vị trí, và chính cặp này cùng nhau làm cho sự khớp có thể bảo vệ được.

Phản hồi đảo ngược chiều địa chỉ của yêu cầu, nên một sự khớp là cặp yêu cầu-phản hồi chứ không phải hai bộ tuple giống hệt. So sánh nguồn của yêu cầu với đích của phản hồi và đích của yêu cầu với nguồn của phản hồi, rồi xác nhận rằng định danh và trình tự đồng ý.

Cũng giữ cửa sổ quan sát, vì một bản ghi dài có thể chứa việc dùng lại hợp pháp của cả hai trường. Cắt cửa sổ xuống một đợt sẽ loại bỏ phần lớn sự mơ hồ đó. Nó cũng làm cho các số đếm có thể tái tạo cho bất kỳ ai đọc phiếu.

tshark -r capture.pcap -Y 'icmp.type == 8' -T fields -e frame.time -e ip.src -e ip.dst -e icmp.ident -e icmp.seq
tshark -r capture.pcap -Y 'icmp.type == 0' -T fields -e frame.time -e ip.src -e ip.dst -e icmp.ident -e icmp.seq

Bước 3: so sánh các tuple tại cùng một ranh giới

Nếu dịch địa chỉ mạng nằm giữa điểm bắt gói và đối tác, các địa chỉ trong yêu cầu và phản hồi sẽ khác nhau theo thiết kế. So sánh các tuple tại một ranh giới, hoặc mang ánh xạ một cách tường minh để phần khác biệt được tính đến. Trộn yêu cầu trước khi dịch với phản hồi sau khi dịch tạo ra những sai lệch chưa từng tồn tại trên dây.

Quyết định ranh giới trước khi bắt đầu đếm, và nêu nó trong báo cáo để người tiếp theo có thể tái tạo việc nhóm. Một bản ghi ở phía máy khách và một bản khác ở phía máy chủ là hai ranh giới khác nhau. Mỗi ranh giới trả lời một câu hỏi khác nhau về nơi phản hồi biến mất.

Một nhóm đầu dò đã dịch cũng thừa hưởng trạng thái của chính thiết bị dịch, điều có thể là lý do thật sự khiến phản hồi không bao giờ đến. Hãy kiểm tra trạng thái đó trước khi đổ lỗi cho đường đi phía sau nó.

tcpdump -ni any icmp and host 10.90.0.1 -c 20
tshark -r capture.pcap -Y 'icmp' -T fields -e ip.src -e ip.dst -e ip.ttl | head -20

Bước 4: nói rõ bản ghi có thể chứng minh gì và không thể chứng minh gì

Một khoảng trống quan sát được không chứng minh rằng máy chủ xa đã im lặng. Điểm bắt gói có thể chỉ thấy một chiều, một bộ lọc có thể bỏ phản hồi, hoặc bộ đệm có thể đã tràn trong cửa sổ. Mỗi điều trong số đó tạo ra cùng một sự vắng mặt và một kết luận khác nhau.

Ghi vị trí bắt gói, biểu thức lọc và các bộ đếm bỏ gói bên cạnh các số đếm, vì một tỷ lệ không có chúng thì không thể kiểm toán. Chính ba dòng đó làm cho con số có thể bảo vệ được về sau.

Sau đó tách điều mà quan sát thiết lập khỏi điều nó gợi ý, trong hai câu thay vì một. Câu đầu nêu các số đếm và ranh giới. Câu thứ hai nêu giả thuyết và điều gì sẽ xác nhận nó.

Khi câu hỏi là liệu một đường cụ thể có bỏ gói hay không, một đầu dò có kiểm soát với địa chỉ nguồn rõ ràng là bằng chứng mạnh hơn một phép đếm thụ động lưu lượng hỗn hợp. Gửi nó từ cùng máy, cùng thời điểm, đến cùng đối tác. Thay đổi một biến và sự so sánh vẫn đứng vững.

Báo cáo các nhóm và ranh giới tiếp theo

Báo cáo có ba dòng: định nghĩa nhóm, các số đếm khớp trong mỗi nhóm và ranh giới nơi việc so sánh được thực hiện. Khi đó người đọc có thể thấy rằng một nhóm trả lời đầy đủ và nhóm kia thì không, điều này chỉ ra một tuyến hoặc một quyền chứ không phải mất mát ngẫu nhiên.

Đính kèm tệp bắt gói và các biểu thức lọc để việc nhóm có thể được tái tạo. Một bản tóm tắt không có tệp là một khẳng định, không phải kết quả.

ping -c 5 -I 10.80.0.6 10.90.0.1
ping -c 5 -I 10.30.0.25 10.90.0.1
tshark -r capture.pcap -Y 'icmp.type == 8 || icmp.type == 0' -T fields -e ip.src -e ip.dst -e icmp.ident -e icmp.seq | sort | uniq -c | head

Khi một nhóm cho thấy năm phản hồi và nhóm kia không có gì, phát hiện là một nguồn có tuyến trả về hoạt động và nguồn kia thì không. Đó là một phiếu tốt hơn nhiều so với một tỷ lệ trộn, và nó hướng lần kiểm tra tiếp theo vào tuyến trả về thay vì vào một phiên bản VPN không liên quan.