Cầu nội bộ SoftEther hay SecureNAT: bật cái nào

Mở SoftEther Manager, và quyết định thực sự đầu tiên về một hub không phải là một ô đánh dấu, mà là câu hỏi về cấu trúc liên kết. Cầu nội bộ gắn hub đó vào một bộ điều hợp vật lý và để phân đoạn hiện có cung cấp địa chỉ, còn SecureNAT cho hub bộ định tuyến ảo, NAT và DHCP của riêng nó. Chọn giữa hai cách sẽ thay đổi địa chỉ đến từ đâu và thiết bị nào trả lời cho chúng. Bật cả hai và hy vọng một cái thắng là cách một phòng lab đang chạy trở thành một chuỗi hỗ trợ.

Bắt đầu từ hub mà bạn thực sự đang sửa

Manager hiển thị một cây máy chủ và hub, và rất dễ cấu hình hub mặc định trong khi các máy khách kết nối tới một hub khác có tên khác. Nhấp vào hub, đọc tên của nó, và xác nhận rằng các phiên được liệt kê bên dưới là những máy khách bạn đang cố phục vụ. Chính lần kiểm tra đó ngăn phần lớn sự nhầm lẫn mà sau này bị đổ lỗi cho giao thức.

Sau đó quyết định máy khách cần gì từ đầu xa. Hành vi Ethernet chia sẻ với phát quảng bá và dịch vụ LAN chỉ về một cầu nối, truy cập riêng được định tuyến tới một dải địa chỉ nhỏ chỉ về SecureNAT, và lối ra internet là một quyết định định tuyến mà cả hai cách sắp xếp đều có thể chịu đựng kém.

Viết câu trả lời trước khi nhấp vào bất cứ thứ gì, vì hai thiết lập không thể hoán đổi cho nhau và việc hoàn tác mất nhiều thời gian hơn việc quyết định. Hai phút viết tiết kiệm một giờ kết nối lại.

Cầu nội bộ làm gì với việc đánh địa chỉ

Cầu nội bộ kết nối hub với một bộ điều hợp vật lý, nên hub trở thành một phần của phân đoạn Ethernet đó. Máy khách nhận địa chỉ từ những gì đã phục vụ phân đoạn, và cổng mặc định của chúng là bộ định tuyến của phân đoạn. Từ góc nhìn của máy khách, nó đã gia nhập LAN của văn phòng, với toàn bộ khả năng tiếp cận và toàn bộ mức phơi nhiễm mà điều đó kéo theo.

Điều đó cũng có nghĩa là cầu nối cần một bộ điều hợp thật với hỗ trợ trình điều khiển phù hợp, và người quản trị phải được phép mở rộng phân đoạn đó. Đăng nhập VPN chứng minh xác thực, không phải quyền đặt một máy chủ trên VLAN sản xuất. Hãy kiểm tra rằng tên trình điều khiển khớp với bộ điều hợp bạn định dùng, vì bắc cầu sai cổng sẽ làm sập một phân đoạn rất nhanh. Nếu danh sách bộ điều hợp trống hoặc cầu nối báo lỗi thì nguyên nhân thường liên quan tới trình điều khiển hoặc quyền, không phải mật mã.

Đọc bảng cầu nối từ dòng lệnh khi cây đồ họa không rõ ràng. Kết quả nêu tên bộ điều hợp, điều mà cây không phải lúc nào cũng làm.

vpncmd /SERVER localhost /HUB VPN /CMD BridgeList
vpncmd /SERVER localhost /HUB VPN /CMD SessionList

Danh sách cầu nối trống với các phiên đang kết nối là một bức tranh hữu ích: máy khách nằm bên trong hub ảo và chưa có gì mở rộng nó ra một phân đoạn.

SecureNAT thêm gì và giấu gì

SecureNAT cho hub một bộ định tuyến ảo, một chức năng NAT và một dịch vụ DHCP, tất cả bên trong tiến trình SoftEther. Máy khách nhận địa chỉ từ dải DHCP ảo, bộ định tuyến ảo trả lời cho cổng mặc định, và lưu lượng cần đi ra được dịch địa chỉ. Không có bộ điều hợp vật lý nào tham gia, đó là lý do nó chạy trên một máy chủ có một card mạng và không cần cấu hình switch.

Cái giá là các địa chỉ ảo thuộc về hub và không thuộc về gì khác. Một máy trong LAN văn phòng không thể định tuyến tới địa chỉ SecureNAT của máy khách mà không có trợ giúp, và mọi thứ ghi lại địa chỉ nguồn đều thấy địa chỉ đã dịch của máy chủ SoftEther. Nếu các quy tắc truy cập hoặc dấu vết kiểm toán của bạn phụ thuộc vào địa chỉ thật của máy khách, đó là thay đổi thiết kế chứ không phải chi tiết. Nó cũng quyết định liệu một quy tắc địa chỉ nguồn có bao giờ nhìn thấy máy khách hay không.

Nó cũng là một máy chủ DHCP. Chạy nó trên một phân đoạn đã có sẵn một cái, hoặc bắc cầu phân đoạn đó cùng lúc, tạo ra hai bên trả lời và các hợp đồng thuê không đoán trước được. Sách hướng dẫn coi hai chức năng này là hai lựa chọn riêng biệt chính vì lý do đó.

Hãy kiểm tra hub đang phục vụ gì ngay bây giờ trước khi bạn bật bất cứ thứ gì khác. Mỗi lệnh in ra trạng thái hiện tại chứ không phải trạng thái dự định.

vpncmd /SERVER localhost /HUB VPN /CMD SecureNatStatusGet
vpncmd /SERVER localhost /HUB VPN /CMD NatGet
vpncmd /SERVER localhost /HUB VPN /CMD DhcpGet

Bật một cái mà không làm hỏng cái kia

Chọn cách sắp xếp, bật nó lên, và để cái kia tắt. Một hub có cả cầu nối và SecureNAT cùng hoạt động là hub có hai câu trả lời khả dĩ cho cùng một câu hỏi, và máy khách sẽ tin câu trả lời đến trước. Khi bạn chuyển từ cái này sang cái kia, hãy tắt chức năng cũ và kết nối lại máy khách thay vì giả định thiết lập mới có hiệu lực trên một phiên đang tồn tại.

Sắp xếp thay đổi sao cho nhóm máy khách không trùng với dải LAN. Các mạng con trùng nhau là nguyên nhân phổ biến thứ hai của một đường hầm kết nối được rồi không tới được đâu, và chúng vô hình cho tới khi bạn so sánh hai kế hoạch địa chỉ cạnh nhau.

Sau đó kết nối lại từ máy khách và đọc xem nó nhận được gì, vì góc nhìn của hub về phiên không phải góc nhìn của máy khách về mạng của chính nó. Kết nối lại là cách đáng tin cậy duy nhất để buộc một hợp đồng thuê mới.

Kiểm tra cổng mặc định và bộ phân giải trên máy khách

Xác thực thành công cho bạn biết thông tin đăng nhập hoạt động và hub đã chấp nhận phiên. Nó không nói gì về việc máy khách có tới được đâu hay không, vì điều đó phụ thuộc vào địa chỉ, mặt nạ, cổng mặc định và máy chủ DNS mà nó nhận được. Hãy đọc bốn giá trị đó trên máy khách trước khi bạn chạm lại vào một thiết lập máy chủ.

Trên Windows, chi tiết bộ điều hợp hiển thị hợp đồng thuê và bộ phân giải, còn bảng định tuyến cho thấy đường hầm có thực sự là đường mặc định hay không.

ipconfig /all
route print -4
nslookup intranet.corp.internal

Trên máy khách Linux, cùng thông tin đó đến từ các tệp địa chỉ, tuyến đường và bộ phân giải. Tuyến mặc định là giá trị quyết định lưu lượng có ra khỏi đường hầm hay không. Nếu cổng mặc định chỉ vào bộ định tuyến của văn phòng trong khi đường hầm mong được mang lưu lượng, cấu trúc liên kết đã được bắc cầu trên danh nghĩa và hỏng trên thực tế. Hãy sửa nguồn địa chỉ trước, sau đó kiểm tra lại ứng dụng, và chỉ sau đó mới cân nhắc đổi chế độ còn lại.