Vì sao BGP trên VPN không kiểm soát đường đi của lớp nền

Hai site peering BGP qua một tunnel IPsec, học tiền tố của nhau, và sơ đồ được đổi tên thành kiểm soát đường đi. Chính cái nhãn đó là khởi đầu của sự nhầm lẫn. Phiên thực sự trao đổi khả năng tiếp cận và thực sự áp dụng chính sách, nhưng nó không có tiếng nói về việc nhà cung cấp, cáp hay router nào chở các gói tin đã mã hóa. Tôi đã thấy một nhóm xây lại một tunnel đang chạy vì họ kỳ vọng một thay đổi tuyến BGP sẽ chuyển lưu lượng sang một đường cáp quang khác mà phiên không bao giờ có thể tác động.

Điều mọi người tưởng một phiên mua được

Phần lớn kỳ vọng đến từ việc một thay đổi tuyến trông thế nào trong phòng thí nghiệm. Bạn quảng bá một tiền tố qua tunnel, phía xa cài đặt nó, và lưu lượng di chuyển. Cùng chuỗi đó cũng xảy ra trên một router thực sự có các nút điều khiển kỹ thuật lưu lượng, nên hai thứ bị lẫn lộn. Trong phòng thí nghiệm hai site thường dùng chung một đường truy cập, và đó chính là lý do sự khác biệt không bao giờ lộ ra ở đó.

BGP là một giao thức khả năng tiếp cận. Nó nói với một peer rằng bạn có thể giao gói tin cho một tiền tố và cho mỗi bên xếp hạng các đề nghị nhận được. Điều này thực sự hữu ích qua tunnel: tiền tố xuất hiện và biến mất khi các site đến và đi, và bạn có thể từ chối một dải mà không phải viết tuyến tĩnh trên mọi thiết bị biên. Điều nó không làm là đưa router của nhà cung cấp vào dưới sự kiểm soát của bạn.

Lớp nền chở phần đầu bên ngoài. Điểm cuối tunnel của bạn gửi gói tin đã mã hóa tới một địa chỉ peer, và mạng giữa hai địa chỉ đó chuyển tiếp chúng bằng các tuyến mà nhà vận hành của nó đã cài đặt. Không gì trong phiên BGP thay đổi quyết định đó, trừ khi cùng nhà cung cấp đó cung cấp một dịch vụ được hỗ trợ làm việc ấy.

Điều phiên thực sự chở

Bộ nói BGP mở một kết nối TCP tới cổng 179 của peer, dùng các định dạng thông điệp và thuộc tính tuyến được định nghĩa trong RFC 4271. Khi địa chỉ peer nằm trong tunnel, tunnel phải được bật lên và địa chỉ đó phải tiếp cận được trước khi phiên có thể bắt đầu. Một trao đổi IKE đã hoàn tất không phải là láng giềng BGP. Các triển khai IPsec dựa trên tuyến chỉ cho lưu lượng đi qua khi tồn tại một tuyến tunnel khớp, còn loại dựa trên chính sách cần địa chỉ peer nằm trong bộ chọn được bảo vệ. Đảo ngược điều này tạo ra trạng thái kinh điển: tunnel xanh nhưng phiên ngồi không.

Khi phiên đã lên, chính sách quyết định cái gì đi qua nó. Danh sách tiền tố, bộ lọc AS-path, mức trần số tiền tố tối đa và một quyết định rõ ràng về tuyến mặc định là mức tối thiểu, và chúng áp dụng ở cả hai chiều. Một peer chấp nhận mọi thứ nhận được có thể cho bạn một tuyến mặc định lặng lẽ thay thế truy cập internet cục bộ. Hai chiều cần danh sách riêng, vì điều bạn chấp nhận từ peer và điều bạn quảng bá cho nó là hai quyết định khác nhau.

router bgp 65010
 neighbor 10.255.0.2 remote-as 65020
 address-family ipv4 unicast
  neighbor 10.255.0.2 prefix-list SITE-B-IN in
  neighbor 10.255.0.2 prefix-list SITE-B-OUT out
  neighbor 10.255.0.2 maximum-prefix 50

Tiếp theo MTU cắn. Đóng gói làm giảm tải trọng dùng được, nên một cập nhật lớn có thể làm dừng một phiên trông như đã thiết lập hoàn hảo: peer vẫn ở trên, tiền tố không bao giờ đến và không có gì rõ ràng rơi vào nhật ký. Giới hạn TCP MSS trên giao diện tunnel, hoặc đặt MTU tunnel có chỗ cho phần phụ trội, trước khi đổ lỗi cho các bộ lọc.

Gói tin bên ngoài vẫn đi đâu

Gói tin đã mã hóa từ site này sang site kia đi ra qua thứ mà router cục bộ chọn cho địa chỉ công khai của peer. Nếu hai site mua transit từ cùng một nhà cung cấp, đi qua cùng một cơ sở metro, hoặc một bên nằm sau NAT cấp nhà mạng, tunnel chỉ sống sót qua sự cố nhà cung cấp một cách tình cờ. Đếm biểu tượng tunnel trong công cụ giám sát không nói gì với bạn về điều này.

Chọn tuyến và cài đặt chuyển tiếp cũng là hai sự kiện riêng. Một tiền tố có thể nằm trong bảng BGP là tốt nhất và vẫn thiếu trong bảng chuyển tiếp, vì bước nhảy kế tiếp không giải được hoặc một tuyến cụ thể hơn thắng. Khi ai đó báo rằng BGP đã học tiền tố nhưng lưu lượng không chảy, câu hỏi hữu ích là nó đã được cài đặt chưa và trỏ tới bước nhảy kế tiếp nào.

Câu trả lời trung thực cho một buổi đánh giá thiết kế là danh sách các phụ thuộc chia sẻ: đường truy cập, nhà cung cấp thượng nguồn, cơ sở và bất kỳ thiết bị giữ trạng thái nào trên đường về. Một phiên qua tunnel không thể loại bỏ một phụ thuộc mà nó không ngồi trên.

Ba quyết định đáng tách ra

Khi một thiết kế trộn những thứ này, mọi cuộc trò chuyện về sự cố đều đi vòng tròn. Hãy tách chúng trên giấy trước, rồi ánh xạ từng cái tới thiết bị thực sự thực thi nó.

Mỗi dòng có một chủ sở hữu khác nhau. Dòng đầu là đàm phán, dòng thứ hai là cấu hình trên thiết bị của bạn, dòng thứ ba phần lớn là mạng của người khác. Một yêu cầu thay đổi nêu tên dòng nó chạm vào dễ được phê duyệt hơn nhiều so với một yêu cầu nói rằng có vấn đề BGP.

Các kiểu hỏng đáng lên kế hoạch

Chấp nhận tuyến tổng hợp của peer là vết thương tự gây phổ biến nhất. Ai đó quảng bá một tổng hợp ngắn để đơn giản hóa việc trao đổi, phía xa chấp nhận nó, và lưu lượng cho các dải không nằm sau tunnel đi theo tunnel và chết. Hãy lọc theo đúng các tiền tố kỳ vọng, hoặc dùng một danh sách tiền tố với ranh giới đúng, và đừng bao giờ chấp nhận một tổng hợp trần vì nó làm phiên trông gọn gàng.

Thời điểm rút là thứ hai. Việc phát hiện phụ thuộc vào bộ đếm thời gian giữ, vào BFD nếu bạn bật nó, vào phát hiện peer chết của tunnel và vào việc phía xa ngừng quảng bá nhanh đến đâu. Các phiên đang tồn tại là một vấn đề riêng: một tuyến mới có thể khôi phục các kết nối mới trong khi các phiên TCP đã thiết lập tiếp tục dùng địa chỉ cũ, và tường lửa có trạng thái hoặc NAT trên đường có thể giữ các mục không còn khớp. Hãy đưa việc phục hồi ứng dụng vào tiêu chí chấp nhận thay vì giả định một thay đổi tuyến giải quyết mọi thứ.

Thứ ba là sự bất đối xứng của đường về. Lưu lượng có thể đến qua tunnel và quay về qua một đường của nhà cung cấp chưa bao giờ được thiết kế để chở nó, điều này hiện ra như âm thanh một chiều, bắt tay thất bại hoặc một tường lửa ném bỏ các phản hồi. Hãy kiểm tra cả hai chiều riêng rẽ.

Viết gì vào hợp đồng và xác minh thế nào

Yêu cầu bằng văn bản các tiền tố được phép: ai có quyền tạo từng dải, tuyến mặc định có được phép không và dịch vụ tunnel hỗ trợ những họ địa chỉ nào. RFC 8212 đã biến chính sách nhập và xuất rõ ràng thành kỳ vọng cho eBGP ở những triển khai tuân theo nó, nên một peer vẫn dựa vào hành vi ngầm chấp nhận mọi thứ thì đáng bị chất vấn.

Rồi xác minh từ thiết bị chứ không phải từ sơ đồ. Các lệnh hữu ích trên router kiểu FRR:

show bgp summary
show bgp ipv4 unicast 10.10.0.0/16
show bgp ipv4 unicast neighbors 10.255.0.2 advertised-routes
show ip route 10.10.0.0/16

Thêm hai quan sát mà bảng tuyến không thể cho bạn. Bắt gói trên giao diện bên ngoài để xác nhận các gói đã đóng gói thực sự nhắm tới địa chỉ nào, ví dụ tcpdump -ni eth0 udp port 51820 cho một tunnel WireGuard, hoặc một bộ lọc ESP cho IPsec. Sau đó trace về phía địa chỉ công khai của peer và so sánh các bước nhảy với một trace bên trong tunnel; nếu cả hai đi theo cùng một chuỗi nhà cung cấp, dự phòng của bạn sống trong chính sách tuyến chứ không phải trong mạng.

Cuối cùng, hãy cố ý thử một lần rút tuyến. Hạ tunnel trong một cửa sổ bảo trì, ghi lại tiền tố còn được cài đặt bao lâu, điều gì xảy ra với các phiên đang tồn tại và liệu phía xa có quay về một tuyến mà bạn thực sự sẽ chấp nhận. Bài tập đó nói về thiết kế nhiều hơn bất kỳ sơ đồ nào.

Một tuyến không phải là sự cho phép. Các tiền tố bạn đồng ý trao đổi không nói gì về việc người dùng nào có thể chạm tới dịch vụ nào sau tunnel, nên hãy giữ xác thực, các dịch vụ được phép và tường lửa máy chủ đúng chỗ cũ. Một peer tiếp cận được cũng không phải là sự cho phép cho transit không giới hạn hay tạo địa chỉ tùy ý, và loại thẩm quyền đó thuộc về hợp đồng như một câu hỏi thương mại, không phải một dòng chính sách BGP.

• Nêu tên các tiền tố mỗi bên có thể tạo, và những tiền tố không bao giờ được chấp nhận.
• Giới hạn MSS trên tunnel và xác nhận các cập nhật lớn thực sự đến.
• Liệt kê các phụ thuộc lớp nền chia sẻ, không phải số tunnel.
• Đo một lần rút thực tế và ghi lại ứng dụng làm gì.