DirectAccess là một công nghệ truy cập từ xa mới của Microsoft, cho phép bạn luôn kết nối với mạng công ty của mình dù ở bất cứ nơi đâu. Thêm vào đó, DirectAccess cho phép CNTT công ty luôn kết nối với tài nguyên đặt dưới sự quản lý của họ, để từ đó các hệ thống này luôn được quản lý, giám sát, được cập nhật và tuân thủ đúng các nguyên tắc, luật lệ và nằm trong sự điều khiển của công ty. DirectAccess được kích hoạt bằng cách kết hợp Windows 7 và Windows Server 2008 R2, nó sẽ trở nên hoàn hảo khi bạn bổ sung thêm Unified Access Gateway (UAG) 2010 vào hệ thống của mình. Trong khi DirectAccess hoàn toàn có thể khi không cần đến UAG nhưng sẽ là một giải pháp doanh nghiệp không khả thi nếu thiếu nó.

Nếu đã sử dụng DirectAccess một thời gian, chắn bạn sẽ không thể tiếp tục mà không có nó. DirectAccess quả là một thứ đặc biệt để có được sự kết nối liên tục.

Về ưu điểm là vậy, nhưng đặt dưới trách nhiệm một quản trị viên, để có được điều đó, mỗi quản trị viên cần phải biết cách khắc phục các sự cố kết nối DirectAccess. Mặc dù các kết nối DirectAccess có thể nói là khá tin cậy nhưng không gì có thể hoàn hảo và chắc chắn sẽ có lúc nào đó các máy khách của bạn không thể kết nối và nhiệm vụ của bạn, một quản trị viên mạng, cần chỉ ra vấn đề ở đâu và khắc phục nó nhanh nhất có thể. Đó cũng chính là những gì mà chúng tôi muốn giới thiệu cho các bạn trong bài này: một số bước cơ bản để giúp các bạn khắc phục sự cố các kết nối máy khách DirectAccess.

Dựa trên các tài liệu của Microsoft và qua thử nghiệm cũng như các lỗi bắt gặp, đây là kế hoạch 7 bước cho việc khắc phục sự cố kết nối máy khách DirectAccess:

Sau đây chúng ta hãy đi xem xét cụ thể từng bước một.

Xác nhận các thiết lập Group Policy

Các máy khách DirectAccess sẽ nhận các thiết lập khác DirectAccess của chúng thông qua Group Policy. Vì vậy nếu Group Policy không được sử dụng cho máy khách DirectAccess thì máy khách sẽ không thể làm việc như một máy khách DirectAccess thông thường. Có nhiều cách bạn có thể xác nhận các thiết lập Group Policy trên máy khách DirectAccess, tuy nhiên cách mà chúng tôi giới thiệu ở đây là kiểm tra các rule bảo mật kết nối trong Windows Firewall mà máy khách DirectAccess sử dụng để kết nối đến máy chủ UAG DirectAccess. Các rule này được gán bởi Group Policy, vì vậy nếu có chúng ở đây, thì có nghĩa Group Policy đã được gán.

Bạn có thể đánh wf.msc vào  hộp tìm kiếm Search trong máy tính Windows 7 để mở cửa sổ Windows Firewall with Advanced Security. Trong phần panel bên trái của cửa sổ, kích nút Connection Security Rules.

Hình 1

Nếu bạn thấy ba rule như thể hiện trong hình 1: UAG DirectAccess Client – Clients Access Enabling Tunnel – All, UAG DirectAccess Clients – Clients Corp Tunnel and UAG DirectAccess Clients – Example NLA, thì có nghĩa rằng Group Policy đã được áp dụng.

Xác nhận rằng máy khách biết rằng nó hiện không nằm trên mạng nội bộ

Máy khách DirectAccess cần biết liệu chúng có đang nằm trong mạng nội bộ của công ty hay không. Nếu nó đang nằm trong mạng công ty, máy khách sẽ tắt các đường hầm DirectAccess và sử dụng giải pháp phân định tên cục bộ dựa trên máy chủ DNS server được cấu hình trên NIC của nó. Nếu máy khách DirectAccess nằm ngoài mạng công ty, nó sẽ thiết lập các đường hầm DirectAccess để kết nối với máy chủ UAG DirectAccess và cho phép UAG DirectAccess server phân định tên cho máy khách DirectAccess.

Bạn có thể xác định một cách dễ dàng việc máy khách DirectAccess có biết nó hiện đang nằm trên mạng hay không bằng cách sử dụng lệnh sau:

netshdns show state

Lệnh này sẽ trả về kết quả giống như thể hiện trong hình 2 bên dưới:

Hình 2

Như những gì bạn thấy trong hình, vị trí của máy được báo cáo là bên ngoài mạng công ty. Nếu máy tính đã báo cáo rằng nó nằm trong mạng công ty thì nó đã sai, khi đó bạn cần chỉ ra tại sao nó lại báo cáo như vậy. Ngược lại nếu máy tính đang báo cáo nó nằm ngoài mạng công ty nhưng sự thật thì nó đang ở trong mạng thì bạn cần phải chỉ ra tại sao nó lại nó mình nằm ngoài mạng như vậy. Trong trường hợp sau, nguyên nhân thường là vấn đề kết nối với Network Location Server (NLS).

Xác nhận các thiết lập của bảng chính sách phân định tên trên máy khách DirectAccess

Name Resolution Policy Table (NRPT) được sử dụng bởi máy khách DirectAccess nhằm phát hiện DNS server nào mà nó sử dụng để phân định tên. Khi máy khách DirectAccess nằm trong mạng nội bộ, NRPT sẽ được tắt bỏ và chỉ máy chủ DNS server mà máy khách sử dụng là DNS server được cấu hình trên NIC của nó. Mặc dù vậy, khi máy khách DirectAccess nằm ngoài mạng công ty, NRPT sẽ tự bật và được sử dụng để xác định DNS server nào mà nó sẽ sử dụng để phân định các tên miền dựa trên tên cần được phân giải.

Bạn có thể xem các thiết lập NRPT bằng cách sử dụng lệnh sau:

netsh namespace show effectivepolicy

Hình 3

Ở đây, trong hình 3, bạn có thể thấy bất cứ tên nào trong miền corp.contoso.com sẽ đều được gửi đến DNS server tại địa chỉ 2002:836b:3::836b:3, đây là địa chỉ 6to4 trên UAG DirectAccess server. UAG DirectAccess server được sử dụng như DNS server vì UAG DirectAccess sử dụng DNS64 làm DNS proxy cho các máy khách DirectAccess. Lưu ý tên miền nls.corp.contoso.com không có địa chỉ DNS server được liệt cho nó, vì đây là một trường hợp ngoại lệ từ các máy chủ trong miền corp.contoso.com. Lý do cho điều này là rằng bạn không muốn máy khách DirectAccess kết nối với NLS khi nó không nằm trong mạng công ty, do máy khách DirectAccess sử dụng kết nối đến NLS để phân biệt khi nào nó nằm trong mạng nội bộ!

Xác nhận các địa chỉ IPv6 trên máy khách DirectAccess

Máy khách DirectAccess sử dụng IPv6 để truyền thông với máy chủ DirectAccess. Đó luôn là sự thực. Máy khách DirectAccess cũng có thể sử dụng IPv6 để truyền thông với các tài nguyên trên mạng nội bộ. Điều này sẽ là sự thực nếu tài nguyên mạng nội bộ có thể phân định theo địa chỉ IPv6. Mặc dù vậy, nếu tài nguyên trên mạng nội bộ của bạn không có khả năng này, thì UAG DirectAccess server sẽ sử dụng NAT64/DNS64 để dịch dữ liệu IPv6 từ máy khách DirectAccess sang tài nguyên IPv4 trên mạng nội bộ. Điều quan trọng cần hiểu ở đây là máy khách DirectAccess luôn sử dụng IPv6 khi kết nối với máy chủ UAG DirectAccess server.

Bạn có thể xác định kỹ thuật dịch IPv6 nào đang được sử dụng bằng cách sử dụng lệnh ipconfig /all.

Hình 4

Trong hình 4 ở trên, bạn có thể thấy rằng Tunnel adapter 6TO4 Adapter hiện đang được sử dụng để kết nối với UAG DirectAccess server và nó có địa chỉ IP và gateway mặc định được gán trước. Gateway mặc định mà bạn thấy ở đây là địa chỉ 6to4 của UAG DirectAccess server.

Khi khắc phục sự cố máy khách DirectAccess, cần bảo đảm rằng nó có một địa chỉ IPv6. Nếu không có địa chỉ IPv6 thì các chỉ thị sẽ cho bạn thấy rằng có một vấn đề gì đó với cấu hình IPv6 của máy khách và bạn nên tập trung nỗ lực của mình vào đây. Cũng có thể có các vấn đề kết nối với máy chủ UAG DirectAccess server, vì vậy cần bảo đảm rằng bạn có thể ping địa chỉ IPv6 của máy chủ UAG, chẳng hạn như IPv6 mà bạn thấy là cổng mặc định cho bộ điều phối 6to4.

Xác nhận quá trình nhận thực máy khách DirectAccess

Khi máy khách DirectAccess kết nối với máy chủ UAG DirectAccess, nó sử dụng các đường hầm Ipsec để cho phép kết nối với mạng công ty. Có hai đường hầm được sử dụng đó là:

Câu hỏi đặt ra là: làm thế nào để bạn thấy được cơ chế nhận thực nào đang được sử dụng và những gì đang làm việc, những gì hiện không làm việc? Có một cách bạn có thể tìm ra câu trả lời là sử dụng giao diện điều khiển Windows Firewall with Advanced Security. Mở nút Monitoring sau đó mở nút Security Associations và sau đó kích nút Main Mode. Ở đây bạn có thể thấy các liên kết bảo mật Main Mode cho các đường hầm cơ sở và cục bộ, như thể hiện trong hình 5. Lưu ý rằng trong phần 2nd Authentication Method, có các kết nối đang sử dụng NLTMv2 và Kerberos V5. NTLM được sử dụng để nhận thực đường hầm cơ sở và Kerberos được sử dụng để nhận thực cho đường hầm cục bộ.

Hình 5

Thông thường bạn sẽ không gặp phải vấn đề gì với việc nhận thực NTLM. Tuy nhiên có thể bạn sẽ thấy nhiều hơn các vấn đề với nhận thực Kerberos. Cần bảo đảm rằng tài khoản người dùng không bị vô hiệu hóa và bảo đảm rằng tài khoản người dùng đang sử dụng mật khẩu hiện hành, không phải mật khẩu được cache. Lưu ý rằng bạn sẽ thấy bất cứ kết nối đường hầm cục bộ Kerberos nào cho tới khi có gắng kết nối với một tài nguyên nào đó không nằm trong bộ sưu tập các máy chủ mà bạn đã biểu thị là các máy chủ cơ sở. Các kết nối này đi qua đường hầm cơ sở được nhận thực NTLM.

Xác nhận kết nối với các máy chủ DNS và bộ điều khiển miền

Như kịch bản khắc phục sự cố non-DirectAccess, bạn cần bảo đảm rằng máy khách DirectAccess có thể liên hệ với các bộ điều khiển miền và DNS server.

Cho ví dụ, bạn có thể chạy lệnh:

nltest /dsgetdc:

và bạn sẽ nhận được kết quả như những gì thể hiện trong hình 6 bên dưới. Kết quả này thể hiện rằng máy khách DirectAccess có thể kết nối với các bộ điều khiển miền và nó cũng cung cấp các thông tin về địa chỉ IPv6 của bộ điều khiển miền. Lưu ý rằng nếu bộ điều khiển miền không có địa chỉ IPv6, bạn sẽ vẫn thấy địa chỉ IPv6 ở đây, tuy nhiên nó sẽ là một địa chỉ NAT64.

Hình 6

Bạn có thể dễ dàng kiểm tra sự phân giải tên bằng cách ping, như những gì thể hiện trong hình 7 bên dưới.

Hình 7

Nếu không thể ping một tài nguyên nào đó bằng tên, bạn hãy kiểm tra để xác định xem mình có thể ping tài nguyên bằng địa chỉ IPv6 của nó hay không. Nếu tài nguyên không hỗ trợ IPv6, bạn có thể ping nó bằng địa chỉ NAT64 của nó.

Kết luận

Trong bài này, chúng tôi đã giới thiệu cho các bạn một số vấn đề cơ bản cho việc khắc phục sự cố máy khách DirectAccess. Bằng cách kiểm tra bảy vấn đề được đưa ra, bạn sẽ có các thông tin cần thiết để đưa các cố gắng của mình đi theo đúng hướng. Việc khắc phục chắc chắn sẽ còn nhiều vấn đề, và nó tùy thuộc vào những sự cố cụ thể. Tuy nhiên đây là những gì cơ bản nhất giúp các bạn khắc phục sự cố nhanh nhất có thể.

(Theo Windowsnetworking)