Đường thuê riêng cho VPN? Hãy dịch yêu cầu trước

Bản đề xuất nêu một đường thuê riêng cụ thể cho VPN văn phòng, và con số đến mà không có lời giải thích. Trước khi ký, hãy tách câu đó thành bốn yêu cầu mà nó thực sự che giấu: bàn giao vật lý, cách phân phối IP, dung lượng ở cả hai chiều, và cam kết hỗ trợ phía sau mạch. Hãy kiểm tra chúng như những cổng theo đúng thứ tự đó, vì một mạch thất bại ở khâu bàn giao không thể cứu bằng một con số băng thông lớn hơn. Sau đó đối chiếu những gì đã được bàn giao với những gì bạn đã ghi.

Dịch yêu cầu, không phải tên sản phẩm

IPsec bảo vệ lưu lượng ở tầng IP và để việc truyền tải cho mạch bạn mua. Kiến trúc IPsec mô tả cách lưu lượng được bảo vệ giữa các bên; nó không nói gì về kiểu bàn giao, tốc độ cam kết hay thời hạn sửa chữa. Đó là những thuộc tính của hợp đồng dịch vụ.

Chính sự phân biệt này là toàn bộ lý do khiến một yêu cầu về mạch có thể hợp lý mà vẫn không phải là yêu cầu về VPN. Một cổng chỉ có giao diện nối tiếp thực sự cần bàn giao nối tiếp, và đó là ràng buộc phần cứng chứ không phải giao thức. Thay thiết bị và ràng buộc biến mất. Hãy viết mỗi yêu cầu theo dạng «cổng cần X vì Y» và từ chối mọi dòng không thể hoàn thành.

Đặt tên bàn giao trước khi đặt tên tốc độ

Bàn giao là kết nối vật lý và tầng liên kết tại điểm phân giới: Ethernet đồng, cáp quang với bộ thu phát cụ thể, giao diện nối tiếp, hoặc một thứ cũ hơn chỉ tồn tại vì thiết bị hiện tại có nó. Sai ở đây đắt theo cách mà băng thông không bao giờ đắt, vì nó thường có nghĩa là phần cứng mới ở cả hai đầu. Một module quang bị thiếu không phải là vấn đề dung lượng và không bản nâng cấp nào sửa được.

Xác nhận đầu nối, thương lượng tốc độ và ai cung cấp bộ chuyển đổi phương tiện hoặc bộ định tuyến. Sau đó xác nhận trách nhiệm của bạn kết thúc ở đâu, vì điểm phân giới quyết định ai được chạm vào thứ gì khi đường truyền sập lúc 03:00. Hãy ghi ranh giới đó vào bản ghi bên cạnh mã định danh mạch. Đó là dòng duy nhất biến một cuộc gọi hỗ trợ thành cuộc trò chuyện năm phút thay vì một giờ chuyển giao.

ip -br link show
ethtool eth0 | head -20
sudo lshw -class network -short

Xác nhận việc phân phối IP, không chỉ địa chỉ

Hỏi dịch vụ thực sự cung cấp địa chỉ hay tiền tố nào, và liệu nó có tĩnh không. Một mạch cấp địa chỉ động không phù hợp với cổng giữa các site, vì cấu hình của đối tác phải chịu được một thay đổi mà bạn không lên kế hoạch. Cũng xác nhận độ dài tiền tố, vì một địa chỉ và một /29 được định tuyến là hai sản phẩm khác nhau.

Sau đó hỏi xem có thứ gì dịch địa chỉ trước khi nó đến chỗ bạn không. NAT phía nhà cung cấp hoặc NAT cấp nhà mạng phía trước dịch vụ phá vỡ các phiên vào, nên một cổng mong nhận IPsec từ các site xa không thể được chạm tới. Tốc độ không bù đắp được: một link nhanh phía sau bộ dịch mà bạn không kiểm soát vẫn không thể nhận kết nối vào trên một cổng mà không ai chuyển tiếp.

Ghi lại ai sở hữu bộ định tuyến và DNS. Nếu nhà cung cấp cấp bộ định tuyến, bạn thừa hưởng firmware, hành vi NAT và quan niệm của nó về tuyến mặc định, và mọi thay đổi sau đó đều qua phiếu hỗ trợ. Hãy nhờ một người ngoài mạng của bạn thử kết nối vào cổng mà bạn cho là có thể chạm tới, vì đó là thử nghiệm duy nhất chứng minh câu chuyện dịch địa chỉ.

ip -br addr
ip route get 198.51.100.10
traceroute -n 198.51.100.10

Tính dung lượng từ khối lượng công việc, theo cả hai chiều

Dung lượng phải được mô tả bằng công việc, không phải bằng một con số trên mỗi người dùng. Truy cập tệp lớn, quản trị tương tác và sao lưu qua đêm mỗi thứ tạo ra một mẫu lưu lượng khác nhau, và chỉ một trong số đó quan tâm đến thông lượng tải lên duy trì. Con số băng thông trên mỗi chỗ ngồi là sự tiện lợi bán hàng, không phải mô hình.

Ước lượng cả hai chiều, cộng thêm chi phí đóng gói, và ghi lại lưu lượng là bùng nổ hay duy trì. Sau đó kiểm tra tốc độ cam kết của hợp đồng chứ không phải tốc độ quảng cáo, vì một hạn mức bùng nổ hết hạn sau vài giây không giúp ích cho sao lưu ban đêm. Hãy đưa cả giới hạn của chính cổng vào cùng ngân sách, vì xử lý mã hóa và số phiên đồng thời có thể trở thành giới hạn sớm hơn nhiều so với mạch. Một đường nhanh hơn sẽ không sửa được cổng đã bão hòa.

Chốt các cam kết vận hành

Khả dụng, phản hồi sửa chữa, đường leo thang và thông báo bảo trì phải bằng văn bản, với phương pháp đo được nêu tên. Tốc độ internet quảng cáo không thiết lập bất kỳ thuộc tính nào trong số đó, và một trang tiếp thị hứa hẹn độ tin cậy mà không định nghĩa sự cố cũng vậy. Hỏi đồng hồ bắt đầu khi nào, vì thời gian phản hồi đo từ xác nhận của chính nhà cung cấp không phải là con số giống như đo từ cảnh báo giám sát của bạn. Hai định nghĩa đó có thể khác nhau hàng giờ mà không ai nói dối.

Cũng ghi lại ranh giới hỗ trợ. Nếu trách nhiệm của nhà cung cấp kết thúc tại một điểm bàn giao mà bộ định tuyến của bạn kết thúc, giờ đầu tiên của mọi sự cố sẽ dành để xác định lỗi thuộc về ai, và không có đồng hồ SLA nào bao phủ điều đó.

Kiểm tra mạch theo các điều khoản bằng văn bản

Khi dịch vụ hoạt động, hãy đo những thuộc tính bạn thực sự đã ký kết, không phải những gì người lắp đặt trình diễn. Thông lượng, độ trễ và mất gói trên đường thực là bằng chứng, và chúng phải được ghi lại vào thời điểm và từ vị trí bạn có thể kể tên. Lặp lại phép đo vào giờ cao điểm, không chỉ lúc bàn giao. Một bài kiểm tra nghiệm thu chạy lúc 10:00 vào ngày yên tĩnh nói rất ít về đường truyền lúc 15:00.

iperf3 -c speed.example.net -t 30 -P 4
mtr -n --report -c 50 198.51.100.10
curl -sS -o /dev/null -w '%{time_connect} %{time_starttransfer}\n' https://speed.example.net/

Giữ kết quả cùng với hợp đồng, vì một cuộc thảo luận hiệu năng không có đường cơ sở là cuộc tranh cãi về cảm nhận. Nếu một phép đo không đạt cam kết, hãy nêu lên khi bằng chứng còn mới và dịch vụ vẫn trong cửa sổ nghiệm thu mà hợp đồng quy định. Một máy chủ được nêu tên trong yêu cầu cũng giữ bắt tay TLS hợp lệ, để cảnh báo chứng chỉ không bị nhầm với mạch hỏng.

Cuối cùng, đọc lại bốn cổng so với những gì đã bàn giao. Bàn giao, phân phối IP, dung lượng và điều khoản hỗ trợ mỗi thứ có một dòng trong bản ghi, và mỗi dòng có một cái tên bên cạnh.