Giới thiệu và các tùy chọn khác
Giống như 5,5 năm, vì vậy tôi chủ yếu để lại câu trả lời này cho mọi người, cố gắng giải quyết các vấn đề tương tự với Cisco Anyconnect 4.x hiện đại. Trong trường hợp của tôi, Anyconnect đang gói lưu lượng truy cập vào cụm Kubernetes cục bộ do Minikube đưa lên trên macOS.
Các phương thức như _ZN27CInterfaceRouteMonitorLinux20routeCallbackHandlerEvhoặc __ZN25CInterfaceRouteMonitorMac20routeCallbackHandlerEvđược mô tả trong:
Có vẻ như không còn làm việc nữa. Ngoài ra, rất nhiều hướng dẫn có liên quan đến việc sửa tường lửa OS X được thể hiện trong các phiên bản trước bởi ipfwtiện ích như ở đây , vì vậy chúng không liên quan.
Vá vpnagentd
Năm 2019, chúng tôi vẫn chiến đấu với cả hai vấn đề cho các công ty tránh định tuyến phân chia và đưa ra các quy tắc tường lửa không hợp lý. Đây là sửa chữa.
Bạn cần vá lỗi gọi phương thức
CHostConfigMgr::StartInterfaceAndRouteMonitoring()trong vpnagentdnhị phân, trong phiên bản của tôi nằm ở 0x09cbf6. Đó là một jmp qwordlệnh đơn giản , không bao giờ được trả lại cho nơi này, vì vậy độc thân nopcó thể là đủ. Tuy nhiên, nó có thể có giá trị xóa sạch hoàn toàn lệnh trong 6 nopgiây.
Ở đây tập lệnh Python có thể tự động hóa thủ tục này cho bạn, tuy nhiên mọi tiện ích tháo gỡ đều có thể giúp bạn ở đó. Trong nghiên cứu ban đầu và hack tôi đã sử dụng radare2khá tiện dụng cho những người không thực hiện các hành động đó hàng ngày:
#!/usr/bin/python3
MAGIC_OFFSET = "0x09cbf6"
MAGIC_BYTE = 144
def eff_anyconnect(file):
print("Opening {} to patch it".format(file))
with open(file, "rb+") as f:
print("Going to {}".format(MAGIC_OFFSET))
print("Current command to call method for watching our routing table")
f.seek(int(MAGIC_OFFSET, 16))
print(hex(int.from_bytes(f.read(6), "big")))
f.seek(int(MAGIC_OFFSET, 16))
f.write(bytes([MAGIC_BYTE]))
print("NOP any longer:")
f.seek(int(MAGIC_OFFSET, 16))
print(hex(int.from_bytes(f.read(6), "big")))
eff_anyconnect("/your/path/to/cisco/bin/vpnagentd")
Bước tiếp theo, sau khi bạn vá lỗi nhị phân, bạn nên hủy vpnagenttiến trình hiện tại và kết nối lại với VPN của mình. Bạn có thể thấy rằng các tuyến mong muốn vẫn bị ảnh hưởng, nhưng hack ở trên sẽ mở khóa bảng định tuyến, do đó bạn có thể ghi đè các tuyến.
Tuyến đường
Tôi sẽ đề nghị thêm -staticnhững cái không bị can thiệp bởi AnyConnect, trong khi không tĩnh vẫn bị trùng lặp bởi những cái được tạo đường hầm. Tôi không có giải pháp tốt ở đây, đối với trường hợp của tôi, tuyến tĩnh duy nhất là đủ:
sudo route -n delete $(minikube ip)
sudo route -n add $(minikube ip) -interface bridge100 -static
Bức tường lửa
Cuối cùng, bước tường lửa. Điều đó khá đơn giản, bạn cần kiểm tra các quy tắc từ chối hoặc chỉ cho phép các quy tắc được gắn thẻ AnyConnect là gì. Trong trường hợp của tôi, mọi thứ không được gắn thẻ đều bị chặn, vì vậy tôi đã tạo một tệp có các mục sau:
nat on utun1 proto {tcp, udp, icmp} from 192.168.64.0/24 to any -> utun1
pass in log on bridge0 inet all flags S/SA keep state tag cisco_anyconnect_vpn_pass
pass in log on bridge100 inet all flags S/SA keep state tag cisco_anyconnect_vpn_pass
Hãy nhớ những điều sau:
utun1 là giao diện AnyConnect của bạnbridge0và bridge100là cầu Minikube / Docker của bạn. Vì một số lý do, AnyConnect đổi tên các cây cầu.192.168.64.0/24 là mạng con Minikube của bạn.
Sau đó chạy:
sudo pfctl -e enable packet-filtering
sudo pfctl -f <your_file_with_rules> -v
Từ giờ trở đi, cho đến khi kết nối lại lần sau, bạn sẽ giỏi về các tuyến đường và tường lửa.