Đường hầm đã lên, không có internet: chuyển tiếp dừng ở đâu

Máy khách kết nối, đường hầm chở ping tới cổng và không gì phía sau trả lời. Trạng thái đó là bình thường với một cổng vốn chỉ nhằm cung cấp quyền truy cập vào các mạng được bảo vệ, và đó là lỗi với cổng được quảng cáo là lối ra của đường hầm đầy đủ. Trước khi đổi quy tắc, hãy xác nhận dịch vụ nào đã được hứa. Sau đó theo dõi một yêu cầu công khai qua bốn nơi mà nó có thể dừng lại. Một yêu cầu và một lần bắt gói giải quyết nhiều hơn một trang phỏng đoán.

Xác nhận lối ra internet có phải là thiết kế ngay từ đầu

Hồ sơ chia đường hầm chỉ định tuyến các mạng con được bảo vệ vào VPN, nên duyệt web công khai tiếp tục qua liên kết cục bộ và không bao giờ chạm tới cổng. Hồ sơ đường hầm đầy đủ cài đặt một tuyến mặc định vào đường hầm, khiến cổng chịu trách nhiệm cho toàn bộ đường đi. Cả hai đều là thiết kế hợp lệ, và việc nhầm lẫn chúng tạo ra báo cáo sự cố ở nơi không có sự cố. Hãy đọc các tuyến mà máy khách công bố trước khi thử bất cứ điều gì khác, vì bảng tuyến trả lời câu hỏi mà phiếu thường đặt sai.

Những gì máy khách cài đặt không phải lúc nào cũng là điều hồ sơ dự định. Một tuyến bị đẩy có thể bị tuyến cục bộ có metric thấp hơn lấn át, và máy khách giữ tuyến LAN trong khi thêm tuyến mặc định sẽ hành xử như đường hầm chia cho mạng con đó.

Theo dõi một yêu cầu công khai

Chọn một điểm đích và theo dõi nó từ máy khách ra ngoài. Trên máy khách, hãy kiểm tra xem gói có thực sự chọn đường hầm không và dùng địa chỉ cục bộ nào làm nguồn. Sau đó kiểm tra cổng: gói có đến không, và có rời giao diện công cộng không. Mỗi câu trả lời đó loại bỏ cả một nhóm nguyên nhân.

ip route get 1.1.1.1
ip -4 addr show tun0
conntrack -L | grep 1.1.1.1
tcpdump -ni any host 1.1.1.1

Nếu cổng không bao giờ thấy gói, tuyến của máy khách hoặc việc chọn đường hầm là sai. Nếu gói đến mà không rời đi, vấn đề nằm ở cổng, và ba kiểm tra còn lại sẽ áp dụng.

Kiểm tra chuyển tiếp, tuyến và biên dịch địa chỉ

Hướng dẫn chuyển tiếp đi kèm strongSwan áp dụng cho cổng của mọi loại đường hầm: nhân phải được phép chuyển gói giữa các giao diện, và một tuyến sử dụng được phải hướng về internet. Sau đó chính sách tường lửa phải cho phép lưu lượng, và địa chỉ nguồn phải là địa chỉ mà phía công cộng có thể trả lời. Một địa chỉ máy khách riêng được chuyển tiếp nguyên trạng ra internet sẽ không bao giờ nhận được phản hồi.

sysctl net.ipv4.ip_forward
ip route get 1.1.1.1
nft list ruleset | grep -A6 forward
sysctl net.ipv4.conf.all.rp_filter

Biên dịch địa chỉ nguồn là phần thường thiếu. Với nó, cổng ghi lại nguồn của máy khách thành địa chỉ công cộng của mình và theo dõi luồng; không có nó, phản hồi không có nơi để đi. Các nền tảng đám mây thêm một ranh giới thứ hai, nơi bảng tuyến hoặc nhóm bảo mật của máy ảo có thể bỏ lưu lượng mà tường lửa của khách cho phép. Ranh giới đó dễ bị bỏ sót vì hệ thống khách trông như được cấu hình đúng từ bên trong.

Lọc đường ngược trong một thiết lập không đối xứng cũng có thể loại bỏ các gói hợp lệ. Hãy đọc bộ đếm của quy tắc đó thay vì cho rằng nó ổn, vì một thiết lập nghiêm ngặt trên giao diện công cộng sẽ từ chối lưu lượng đến theo đường khác với đường mà bảng tuyến dự đoán.

Đường phản hồi và trình phân giải là hai câu trả lời khác nhau

Cũng hãy để ý phản hồi, không chỉ yêu cầu. Nếu yêu cầu đi ra đã được biên dịch và phản hồi quay về luồng đã biên dịch, chuyển tiếp vẫn hoạt động kể cả khi ứng dụng còn lỗi, và cuộc điều tra tiếp theo thuộc về ứng dụng hoặc DNS.

Một trang trả về lỗi HTTP là bằng chứng rằng chuyển tiếp ra internet hoạt động. Một tên không phân giải được trong khi truy cập bằng địa chỉ vẫn hoạt động là vấn đề của trình phân giải, không phải của NAT.

Sau một chỉnh sửa hẹp, hãy kiểm tra lại máy khách cùng mọi tài nguyên riêng bị hạn chế có chủ đích. Việc cấp quyền truy cập internet không được âm thầm mở rộng quyền truy cập tới mọi mạng gắn với cổng.