1. Kiểm tra kết nối mạng
Trong rất nhiều trường hợp khi bạn mở trình duyệt Web và nhập một URL vào đó, nhưng URL thất bại không thể truy cập được trang Web. Trường hợp này nguyên nhân bạn nghĩ đến đầu tiên là do lỗi DNS. Tuy nhiên thực tế thì trong trường hợp này nguyên nhân có thể là do kết nối mạng của bạn.
Điều này càng đúng hơn nếu bạn sử dụng Laptop và kết nối mạng bằng Wifi. Với giao thức bảo mật không dây, key sẽ được “điều đình” lại hoặc cường độ tín hiệu của sóng vô tuyến sẽ bị yếu dần, dẫn đến kết nối mạng bị mất.
Nguyên nhân mất kết nối mạng có thể xảy ra trên bất kỳ loại mạng nào.
Nói cách khác, trước khi đổ lỗi cho DNS, hãy bắt đầu khắc phục sự cố bằng cách kiểm tra “OSU Layer 1 – Physical” đầu tiên sau đó kiểm tra kết nối mạng của bạn.
Lưu ý về cách Access là Local and Internet. Nếu Access hiển thị là Local, đồng nghĩa với việc địa chỉ mạng của bạn không hợp lệ (trong trường hợp này, bạn chỉ có một APIPA riêng bắt đầu với địa chỉ 169.x.x.x).
Tiếp theo bạn cần đảm bảo rằng bạn có một địa chỉ IP hợp lệ trên hệ thống mạng. Bạn có thể kiểm tra địa chỉ IP của mình bằng cách vào View Status sau đó chọn Details, kiểm tra địa chỉ IP và xác nhận địa chỉ IP của DNS Server. Nếu địa chỉ IP của bạn là 169.x.x.x đồng nghĩa với việc bạn không thể kết nối Internet được.
2. Xác nhận địa chỉ IP của DNS Server là “chuẩn” và đúng thứ tự
Sau khi bạn có địa chỉ IP hợp lệ và có thể kết nối được Internet, lúc này bạn có thể đi sâu vào các vấn đề bên trong DNS bằng cách xác nhận lại địa chỉ IP của DNS Server đã chuẩn và đúng thứ tự hay chưa.
Nếu quan sát trong hình thứ 2 ở trên bạn có thể nhìn thấy địa chỉ IP của IPv4 DNS Server. Lưu ý rằng địa chỉ IP của IPv4 DNS Server IP bao gồm cả Local LAN / Subnet để bạn có thể truy cập, thậm chí trong trường hợp nếu cổng mặc định bị hỏng.
Đây là cách nó làm việc trên hầu hết các mạng doanh nghiệp. Mặc dù vậy, các máy chủ DNS của bạn không phải lúc nào cũng nằm trên subnet. Trong thự tế, với hầu hết các ISP, các IP của DNS Server thậm chí còn không nằm trên cùng subnet với cổng mặc định (default gateway).
Trong hầu hết các cấu hình router của gia đình hay các doanh nghiệp vừa và nhỏ (home/SMB) không có các máy chủ DNS riêng và các SMB router sẽ proxy (ủy nhiệm) DNS đến các máy chủ DNS thực. Trong trường hợp đó, địa chỉ IP của DNS Server có thể cùng với địa chỉ IP Router của bạn.
Cuối cùng, bảo đảm rằng DNS Server của bạn nằm đúng thứ tự. Trong trường hợp thể hiện trong hình 2, DNS Server nội bộ là 10.0.1.20. Nó được cấu hình để “forward” tất cả các tên miền mà nó không thể phân giải đến 10.0.1.1, địa chỉ router nội bộ. Router đó sẽ proxy DNS đến DNS Server của ISP. Chúng ta thể tra cứu các DNS Server đó trên router của mình, xem thể hiện trong hình 3.
Đầu tiên, cần đảm bảo rằng DNS Server của bạn nằm ở đúng thứ tự. Nếu trường hợp bạn có một local DNS Server, giống như trên và đang tra cứu tên miền nội bộ (local DNS name), muốn PC client tra cứu local DNS name đó trong local DNS Server đầu tiên, trước Internet DNS Server. Khi đó, local DNS server của bạn phải nằm đầu tiên trong các thiết lập DNS.
Thứ hai, bạn có thể ping địa chỉ IP của DNS Server của ISP. Theo cách này, chỉ cần các DNS server được liệt kê nằm ở trên router của mình, bạn có thể thẩm định rằng mình có thể ping chúng thậm chí từ máy tính nội bộ của mình:
Lưu ý về thời gian đáp trả khi ping đến DNS Server của ISP. Quá trình này có thể làm chậm các tra cứu DNS hoặc thậm chí còn có thể làm thất bại nếu nó mất quá lâu thời gian để DNS server đáp trả.
Lưu ý về thời gian đáp trả từ hành động ping của bạn đến DNS Server của ISP. Điều này có thể làm chậm các tra cứu DNS hoặc thậm chí còn có thể làm thất bại nếu nó mất quá lâu thời gian để DNS server đáp trả.
3. Ping địa chỉ IP của host mà bạn muốn (trường hợp nếu bạn biết)
Cách nhanh chóng để chứng minh lỗi là do DNS chứ không phải do sự cố kết nối mạng đó là ping địa chỉ IP của Host mà bạn muốn truy cập đến. Nếu kết nối đến tên miền thất bại nhưng kết nối đến địa chỉ IP thành công đồng nghĩa với việc vấn đề của bạn nằm ở DNS.
Tuy nhiên nếu DNS Server của bạn không hoạt động thì rất khó có thể chỉ ra địa chỉ IP mà bạn đang kết nối đến là gì. Để thực hiện test này, bạn phải có một sơ đồ (diagram) mạng hoặc giống như nhiều Admin vẫn thực hiện, chỉ cần nhớ địa chỉ IP của host.
Nếu làm việc, chờ cho tới khi DNS server khả dụng lần nữa, bạn có thể đặt một entry trong file hosts của mình để map IP đến hostname.
4. Tìm DNS server đang được sử dụng bằng nslookup
Bạn có thể sử dụng lệnh nslookup để tìm kiếm các thông tin về DNS resolution của mình. Một trong những cách đơn giản là bạn có thể sử dụng lệnh này để xem DNS server nào đang cung cấp cho bạn câu trả lời và DNS server nào không.
Lưu ý trong hình 5, DNS server của ISP đã cung cấp cho chung ta thông tin “non-authoritative answer”, có nghĩa rằng nó không cấu hình miền nhưng vẫn có thể cung cấp hồi đáp.
Ngoài ra bạn cũng có thể sử dụng lệnh này để so sánh các hồi đáp từ các DNS server khác nhau bằng cách cung cấp DNS server nào sử dụng.
5. Kiểm tra hậu tố DNS
Nếu bạn đang tra cứu host nội bộ trên một DNS server mà máy tính của bạn là một thành viên nằm trong đó, khi đó bạn có thể kết nối đến một host, không cần sử dụng FQDN (fully qualified DNS name) và hy vọng vào hậu tố của DNS có thể giúp bạn tìm ra vấn đề.
Cho ví dụ, nếu chúng ta kết nối đến “server1”, DNS server có thể có nhiều entry cho tên miền đó. Khi đó Network Adaptor của bạn sẽ được cấu hình với hậu tố DNS kết nối.
Chẳng hạn như ví dụ trong hình 2, DNS là wiredbraincoffee.com. Do đó bất cứ khi nào bạn nhập vào một tên miền như server1, hậu tố DNS sẽ được bổ sung vào phần cuối của nó để tạo thành server1.wiredbraincoffee.com.
Bạn nên xác nhận hậu tố DNS của mình là đúng.
6. Đảm bảo rằng các thiết lập DNS của bạn được cấu hình để “kéo” IP của DNS từ máy chủ DHCP
Cũng giống như khi bạn muốn Network Adaptor của mình “thu” được các địa chỉ IP của DNS Server từ DHCP Server. Nếu quan sát vào hình trên, bạn có thể nhìn thấy daptor này đã được ghi rõ các địa chỉ IP của DNS Server.
Hình 6: Thẩm định các thiết lập của DNS Server
Bạn phải thay đổi “Obtain DNS server address automatically” theo thứ tự để có được IP mới của DNS server. Để thực hiện điều đó, bạn chỉ cần mở thẻ Properties của Network Adaptor, sau đó click vào Internet Protocol Version 4 (TCP/IPv4).
7. Giải phóng và “làm mới” địa chỉ IP của DHCP Server (và cả thông tin DNS)
Dù Adaptor của bạn đã được thiết lập để kéo các thông tin DNS từ DHCP, nhưng trong một số trường hợp nó có thể xảy ra hiện tượng xung đột địa chỉ IP hoặc nhận phải các thông tin DNS server cũ. Chính vì vậy sau khi đã lựa chọn “thu nhận” địa chỉ IP và DNS tự động, bạn nên “giải phóng” địa chỉ IP của mình và “renew – làm mới” nó.
Bạn có thể thực hiện điều này với Windows Diagnosis trong cấu hình Network của mình. Tuy nhiên cách nhanh nhất là sử dụng Command prompt. Nếu bạn đã kích hoạt UAC, chạy lệnh cmd của Windows dưới quyền Amin:
IPCONFIG /RELEASE
IPCONFIG /RENEW
Sau đó, thực hiện với lệnh IPCONFIG /ALL để xem những thông tin IP và DNS mới như thế nào.
8. Kiểm tra DNS Server và restart các dịch vụ hoặc reboot nếu cần thiết
Rõ ràng, nếu DNS server bị treo hoặc bị hỏng, hoặc bị cấu hình sai, bạn sẽ không thể khắc phục điều đó tại Client side. Tuy nhiên bạn có thể bypass máy chủ bị lỗi đó chứ không thể khắc phục được lỗi.
Theo cách đó, Admin – người chịu trách nhiệm cho DNS server sẽ phải kiểm tra trạng thái và cấu hình của DNS server để khắc phục vấn đề DNS.
9. Khởi động lại Router DNS văn phòng nhỏ hay gia đình
Như đã đề cập ở trên trong cách thứ 2 và được hiển thị trong hình minh họa thứ 3, trên các router của gia đình và các văn phòng nhỏ, thiết lập DNS server thường được thực hiện thông qua DHCP với DNS server thiết lập một địa chỉ IP của router và router sẽ proxy DNS đến DNS server của ISP.
Tuy vậy, máy tính nội bộ của bạn có thể có các thông tin mạng (gồm có các địa chỉ IP của DNS server), nhưng cũng có trường hợp router của bạn có thông tin sai. Để bảo đảm rằng router của bạn có các thông tin DNS server mới nhất, bạn có thể thực hiện “giải phóng” một DHCP và “renew – làm mới” giao diện WAN của router với ISP. Hoặc cách dễ dàng hơn có thể là reboot router để nó nhận được các thông tin mới nhất.
10. Liên hệ với ISP
Tất cả chúng ta đều biết rằng việc liên lạc với một ISP để khắc phục một vấn đề về mạng sẽ mệt mỏi như thế nào. Tuy nhiên nếu máy tính của bạn vẫn gặp vấn đề về DNS resolution từ các máy chủ DNS của ISP thì bạn cần phải liên lạc với họ, và đó cũng chính là cách giải quyết cuối cùng.
11. Kiểm tra DNS Resolution từ một hệ thống khách
Các công ty thường chạy DNS server của riêng mình và sử dụng nó để phân giải tên DNS thành địa chỉ IP Private, nhằm giúp cho người dùng dễ dàng truy cập hệ thống hơn. Một ví dụ đơn giản để hình dung là yêu cầu một người dùng hãy khởi động chương trình khách Remote Desktop của họ và kết nối với server1 thay vì kết nối với 192.168.70.243.
OpenVPN Access Server hỗ trợ đẩy một lệnh đến một máy khách OpenVPN đang kết nối để sử dụng một DNS server cụ thể. Trên thực tế nó hỗ trợ đẩy 2 DNS server, trong trường hợp server đầu tiên không phản hồi. Điều này có thể được cấu hình trong Admin UI (giao diện người dùng quản trị) thuộc phần VPN Settings. Access Server cũng hỗ trợ gửi các hướng dẫn bổ sung cho DNS Resolution Zones, có chức năng giống như một kiểu phân tách DNS, mà chỉ các truy vấn cho một vùng DNS cụ thể được gửi đến máy chủ VPN và DNS Default Suffix (Hậu tố mặc định DNS), cung cấp gợi ý cho Windows để ‘tự động hoàn thành’ tên máy chủ thành Fully Qualified Domain Name hoặc FQDN.
Thật không may, không phải mọi hệ điều hành đều hoạt động giống nhau, xét về DNS. Một số hệ thống sẽ thử tất cả các DNS server cùng một lúc và chấp nhận server phản hồi đầu tiên. Những server khác sẽ có thể làm phân chia DNS, và những server khác thì không. Điều này có thể dẫn đến một số vấn đề nhất định. Hướng dẫn bên dưới cung cấp một cách kiểm tra xem liệu truy vấn DNS bạn đang thực hiện từ thiết bị khách OpenVPN có đang thực hiện thông qua VPN tunnel tới OpenVPN Access Server hay không. Và từ đó, tất nhiên, sẽ đến DNS server đích. Thông tin này có giá trị trong việc xác định phía máy khách có gặp vấn đề hay không, hoặc lỗi là do máy chủ.
Bài viết sẽ giả định rằng bạn có một DNS server được cấu hình trong Admin UI của Access Server, thuộc phần VPN Settings. Giả định rằng bạn không sử dụng DNS Resolution Zones hoặc các trường DNS Default Suffix. Với cài đặt này, tất cả yêu cầu DNS sẽ được chuyển từ máy khách OpenVPN, thông qua OpenVPN Access Server và sau đó đến DNS server được chỉ định. Trong ví dụ ở bài viết này, ta đang đẩy Google Public DNS server 8.8.8.8 và các kết quả thử nghiệm cũng sẽ phản ánh điều này trong các kết quả đầu ra mẫu.
Hãy cài đặt chương trình OpenVPN trên hệ thống khách đã chọn. Trong ví dụ ở bài viết này, ta sẽ sử dụng một hệ thống máy khách Windows 10 Professional với OpenVPN Connect Client được cài đặt và kết nối với OpenVPN Access Server. Tiếp theo, mở một phiên giao diện điều khiển hoặc phiên SSH tới OpenVPN Access Server và nhận các đặc quyền root. Ta sẽ sử dụng công cụ tcpdump để giám sát hoạt động trên cổng 53 TCP và UDP, cổng mặc định nơi các truy vấn DNS được xử lý. Ta sẽ xóa bộ nhớ cache của trình phân giải DNS cục bộ ở phía máy khách, sau đó phân giải một số tên miền đơn giản bằng cách ping chúng theo tên.
Trong tình huống thử nghiệm này, chỉ có một số ít các máy khách được kết nối và hoạt động của các truy vấn DNS rất thấp, để bạn đọc có thể theo dõi dễ dàng. Nếu bạn đang thử nghiệm trên một hệ thống sản xuất và lệnh tcpdump cho quá nhiều đầu ra, bạn có thể nối thêm một bộ lọc grep theo địa chỉ IP, để lọc truy vấn chỉ từ địa chỉ IP của máy khách VPN cụ thể, để đọc và định vị kết quả truy vấn DNS dễ dàng hơn .
Trên Access Server, hãy chạy các lệnh sau:
apt-get update apt-get install tcpdump
Với TCPdump đã được cài đặt, hãy chạy nó với các tham số sau:
tcpdump -eni any port 53
Hoặc, nếu bạn muốn lọc nó theo địa chỉ IP của máy khách VPN (điều chỉnh khi cần):
tcpdump -eni any port 53 | grep “172.27.10.22”
Sau khi chạy lệnh này trong chế độ nền, hãy đi đến hệ điều hành máy khách VPN của bạn, và mở một command prompt. Trên Windows, ví dụ, bạn có thể chạy chương trình cmd để mở một DOS prompt kiểu cũ. Khi mở, sử dụng các lệnh sau để xóa bộ nhớ cache của trình phân giải DNS cục bộ, vì vậy nó sẽ không lấy kết quả từ bộ nhớ cục bộ của riêng nó, sau đó thực hiện truy vấn thực tế.
Xóa cache trình phân giải DNS cục bộ trên Windows:
ipconfig /flushdns
Phân giải một số tên miền:
ping www.google.com ping www.openvpn.net ping www.facebook.com
Mỗi tên miền trong số này sẽ mang lại kết quả trông giống như sau:
Pinging www.google.com [216.58.212.228] with 32 bytes of data: Reply from 216.58.212.228: bytes=32 time=4ms TTL=56 Reply from 216.58.212.228: bytes=32 time=3ms TTL=56 Reply from 216.58.212.228: bytes=32 time=3ms TTL=56 Reply from 216.58.212.228: bytes=32 time=3ms TTL=56 Ping statistics for 216.58.212.228: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 3ms, Maximum = 4ms, Average = 3ms
Trên OpenVPN Access Server, bạn sẽ thấy kết quả trông giống như sau:
18:03:07.976553 In ethertype IPv4 (0x0800), length 76: 172.27.232.2.49531 > 8.8.8.8.53: 53268+ A? www.google.com. (32) 18:03:07.976579 Out 00:0c:29:c7:60:e9 ethertype IPv4 (0x0800), length 76: 192.168.47.133.49531 > 8.8.8.8.53: 53268+ A? www.google.com. (32) 18:03:07.981162 In 34:31:c4:8e:b5:67 ethertype IPv4 (0x0800), length 92: 8.8.8.8.53 > 192.168.47.133.49531: 53268 1/0/0 A 216.58.211.100 (48) 18:03:07.981181 Out ethertype IPv4 (0x0800), length 92: 8.8.8.8.53 > 172.27.232.2.49531: 53268 1/0/0 A 216.58.211.100 (48)
Kết quả trên từ tcpdump cho thấy rằng một yêu cầu DNS đã được nhận từ máy khách VPN tại 172.27.232.2, và nó được chuyển hướng đến máy chủ DNS ở 8.8.8.8. Trong đó yêu cầu là tìm bản ghi A (địa chỉ IP) cho tên DNS www.google.com. Dòng đầu tiên cho thấy yêu cầu này đang đến OpenVPN Access Server, từ máy khách VPN. Dòng thứ hai cho thấy yêu cầu rời khỏi máy chủ truy cập thông qua giao diện mạng, với địa chỉ MAC 00:0c:29:c7:60:e9. Trong thiết lập thử nghiệm ở bài viết này, đây là giao diện mạng của Access Server đi vào Internet. Điều này có ý nghĩa là máy chủ DNS 8.8.8.8 có trên Internet. Dòng thứ ba cho thấy kết quả DNS đã được nhận và dòng thứ tư cho thấy kết quả này đã được chuyển tiếp trở lại máy khách VPN. Trong trường hợp này, DNS resolution đang hoạt động.
Các lỗi và nguyên nhân phổ biến
Dưới đây là một số vấn đề phổ biến và nơi mà bạn có thể tìm một giải pháp xử lý.
Ping request could not find domain (…).
Giải pháp: Vui lòng kiểm tra tên và thử lại.
Điều này có thể xảy ra khi máy chủ DNS mà hệ thống khách của bạn đang sử dụng bị cấu hình kém, không thể truy cập được, hoặc nếu máy chủ DNS đang sử dụng không biết miền bạn đang cố phân giải là gì. Ví dụ với các máy chủ DNS cục bộ trong mạng của bạn, rất có thể là chúng chỉ biết các hệ thống máy tính cục bộ và không có kiến thức về các tên trực tuyến như openvpn.net hay tương tự như vậy. Thông thường trong trường hợp này, bạn có thể cấu hình máy chủ DNS để chuyển tiếp các truy vấn DNS đến một máy chủ DNS Public mà không biết câu trả lời cho các truy vấn đó, để nó có thể trả lời cả hai truy vấn cho tên cục bộ và tên công khai. Một bước hữu ích trong tình huống này có thể là chạy lại tcpdump như mô tả trong phần thử nghiệm DNS resolution từ phần hệ thống máy khách ở trên, và kiểm tra xem đầu ra của tcpdump là gì.
Nếu bạn thấy kết quả như sau:
18:07:10.082330 In ethertype IPv4 (0x0800), length 94: 172.27.232.2.54519 > 8.8.8.8.53: 50281+ A? thisdomainreallydoesnotexist.com. (50) 18:07:10.082356 Out 00:0c:29:c7:60:e9 ethertype IPv4 (0x0800), length 94: 192.168.47.133.54519 > 8.8.8.8.53: 50281+ A? thisdomainreallydoesnotexist.com. (50) 18:07:10.082507 In ethertype IPv4 (0x0800), length 94: 172.27.232.2.57858 > 8.8.8.8.53: 65054+ AAAA? thisdomainreallydoesnotexist.com. (50) 18:07:10.082521 Out 00:0c:29:c7:60:e9 ethertype IPv4 (0x0800), length 94: 192.168.47.133.57858 > 8.8.8.8.53: 65054+ AAAA? thisdomainreallydoesnotexist.com. (50) 18:07:10.103610 In 34:31:c4:8e:b5:67 ethertype IPv4 (0x0800), length 167: 8.8.8.8.53 > 192.168.47.133.54519: 50281 NXDomain 0/1/0 (123) 18:07:10.103641 Out ethertype IPv4 (0x0800), length 167: 8.8.8.8.53 > 172.27.232.2.54519: 50281 NXDomain 0/1/0 (123)
Cụ thể là mục NXDomain ở đây rất quan trọng. Nó có nghĩa là DNS server này không biết tên miền mà ta đang cố gắng phân giải. Một DNS khác vẫn có thể biết tên domain, nhưng DNS này thì không. Tuy nhiên, trong ví dụ trên, ta đã chọn tên không tồn tại (hoặc ít nhất là không khi ta chạy thử nghiệm – dĩ nhiên có thể ai đó sẽ đăng ký tên này trong tương lai) một cách có chủ đích để chắc chắn lỗi sẽ xảy ra. Nếu bạn gặp phải sự cố này, bạn có thể thử sử dụng chương trình nslookup trên máy tính có quyền truy cập trực tiếp vào máy chủ DNS, và sử dụng nó để truy vấn trực tiếp vào máy chủ DNS cụ thể để xác nhận rằng nó biết domain đó.
Nếu bạn thấy kết quả như thế này, hãy lặp lại một vài lần:
18:19:29.935439 Out 00:0c:29:c7:60:e9 ethertype IPv4 (0x0800), length 76: 192.168.47.133.60180 > 1.2.3.4.53: 16427+ AAAA? www.google.com. (32) 18:19:29.935479 In ethertype IPv4 (0x0800), length 76: 172.27.232.3.51334 > 1.2.3.4.53: 37513+ A? www.google.com. (32)
Sau đó, những gì bạn có thể thấy ở đây là một truy vấn đến từ máy khách VPN, đi qua Access Server, sau đó ra ngoài Internet, nhưng không có phản hồi. Thông thường, điều này có nghĩa là máy chủ DNS này không thể truy cập được, hoặc đó không phải là máy chủ DNS. Trong ví dụ, tác giả đã chọn địa chỉ IP 1.2.3.4, thứ chắc chắn không phải là một máy chủ DNS. Rõ ràng truy vấn sẽ được lặp lại một vài lần nhưng cuối cùng sẽ thất bại.
Giải pháp rõ ràng ở đây là chọn một máy chủ DNS hoạt động, hoặc, để đảm bảo rằng không có tường lửa nào đang chặn các truy vấn từ các máy khách VPN đến máy chủ DNS. Trong một số trường hợp, khi việc định tuyến được sử dụng để cung cấp cho máy khách VPN quyền truy cập vào máy chủ trên mạng riêng kết nối với Access Server, thì nguyên nhân là router bị thiếu. Trong trường hợp này, các gói từ các máy khách VPN làm cho nó trở thành máy chủ DNS đích rất đáng tin cậy. Tuy nhiên, nó không thể phản hồi, vì nó nhận các gói từ một mạng con mà bản thân nó không biết cách phản hồi. Điều đó có thể được giải quyết bằng cách thực hiện các tuyến tĩnh cho việc giao tiếp VPN khách trực tiếp, hoặc chuyển sang cho phép truy cập bằng NAT thay thế. Trong các trường hợp khác, đặc biệt là trên các nền tảng Windows Server, Windows Firewall tích hợp có thể chặn truy vấn đến từ mạng con bên ngoài mạng cục bộ. Trong trường hợp này, việc điều chỉnh tường lửa là cần thiết để cho phép máy chủ DNS nhận được truy vấn và phản hồi nó.
Tham khảo thêm một số bài viết dưới đây:
- Kiểm tra tốc độ Internet không cần phần mềm
- 3 lý do “chính đáng” để đổi DNS Server
- Hướng dẫn thiết lập FTP Server cá nhân bằng FileZilla
Chúc các bạn thành công!
