Tidak ada internet di VPN Windows? Kumpulan alamat adalah tersangkanya

Windows menampilkan tunnel sebagai tersambung dan memberinya label Tidak Ada Akses Internet, yang dibaca orang sebagai keanehan Windows. Itu pernyataan tentang apa yang diterima klien: tidak ada gateway default yang bisa dipakai, tidak ada resolver yang bekerja, atau tidak ada jalur balik bagi alamat di dalam tunnel. Saat servernya Incoming Connection Windows, satu pengaturan menjelaskan sebagian besar laporan semacam itu. Label itu bukan diagnosis, tetapi mempersempit pencarian ke tiga tempat.

Baca sewa sebelum mengubahnya

Jalankan ipconfig /all di klien dan temukan adapter VPN di antara entri. Alamat, gateway default, dan server DNS yang dicantumkannya adalah fakta yang Anda butuhkan, dan sering berbeda dari yang dianggap administrator telah dibagikan.

Tiga pola memetakan ke tiga kesalahan. Alamat di 169.254.0.0/16 berarti klien tidak menerima apa pun dan memberi dirinya alamat link-local. Alamat yang masuk akal tanpa gateway berarti kumpulan disajikan tanpa opsi yang memberi klien rute default. Sewa lengkap yang tetap tidak mencapai apa pun menunjuk ke penerusan atau penerjemahan di sisi server.

Catat nilainya sebelum menyentuh server. Langkah berikutnya membandingkannya dengan rentang yang dianggap server sedang dibagikan, dan ingatan adalah pengganti yang buruk untuk sewa.

Mengapa penetapan otomatis bisa meninggalkan tanpa gateway

Entri Incoming Connections punya properti IPv4 sendiri, terpisah dari adapter fisik. Default di sana menawarkan penetapan alamat otomatis, yang bergantung pada pengalokasi bawaan koneksi untuk menyediakan alamat, mask, gateway, dan DNS.

Pada workstation mandiri, pengalokasi itu tidak punya cakupan untuk diambil kecuali ada hal lain di mesin yang menyediakannya, sehingga klien bisa berakhir dengan alamat link-local atau dengan alamat tetapi tanpa gateway. Koneksi tampak terbentuk karena tautan naik, sementara konfigurasi di belakangnya tidak lengkap.

Itulah sebabnya beralih ke rentang tertentu memperbaiki begitu banyak laporan ini. Anda berhenti meminta layanan yang mungkin tidak berjalan untuk mengarang sewa dan mulai menyatakan sewa itu sendiri.

Kebingungan yang sama muncul ketika seseorang mengharapkan server DHCP router LAN melayani klien tunnel. Penemuan broadcast tidak melintasi tunnel yang dirutekan, jadi server itu tidak pernah melihat permintaannya. Menganggap sebaliknya adalah alasan paling umum kumpulan disalahkan atas klien yang tidak pernah menanyakannya apa pun.

Tetapkan rentang eksplisit yang bisa dirutekan server

Pilih blok kecil di dalam subnet yang dapat dijangkau server, di luar rentang yang dibagikan router LAN, dan di luar kumpulan lain di jaringan. Jika server berada di 172.20.10.0/24 dan router memegang 172.20.10.1, blok pendek di dekat atas subnet itu, katakanlah 172.20.10.201 sampai 172.20.10.209, menjaga sewa tunnel jauh dari pembagian yang sudah dikelola router.

Masukkan di properti IPv4 Incoming Connection, sambungkan ulang klien, dan baca adapter lagi sebelum mengubah hal lain. Pembacaan kedua yang memberi tahu apakah kumpulan itu kesalahannya atau hanya satu kesalahan di antara beberapa.

Perintah ini mencetak konfigurasi hasilnya dan rute yang kini dimiliki klien:

ipconfig /all
route print -4
Get-NetIPConfiguration -InterfaceAlias \"Incoming Connection\"

Gateway dalam sewa seharusnya alamat yang dipegang server, dan rute default klien seharusnya mengarah ke sana. Jika sewa lengkap tetapi tidak ada rute, server menetapkan tanpa mendorong gateway, dan pengaturan kumpulan tetap tempat untuk dicari.

Alamat bukan jalur internet

Menerima sewa hanya memindahkan paket dari klien ke server. Untuk akses internet server harus meneruskan paket itu dan menerjemahkannya ke uplink-nya sendiri, dan itu konfigurasi terpisah dengan mode kegagalannya sendiri.

Internet Connection Sharing adalah jalan pintasnya. Itu mengubah adapter yang menghadap internet menjadi gateway bersama dan menjalankan pengalamatan sendiri, yang dapat menulis ulang alamat adapter itu dan meninggalkan aturan NAT yang ada menunjuk ke nilai yang tidak lagi ada. Catat pengaturan aslinya sebelum mengaktifkannya.

Alternatif yang dirutekan menjaga pengalamatan tetap stabil dan meminta Anda mengonfigurasi penerusan dan penerjemahan secara eksplisit. Tak satu pun pendekatan itu salah; mencampurnya setengah jalan menghasilkan tunnel dengan sewa dan tanpa jalan keluar, yang persis gejala yang Anda mulai. Pilih satu model dan selesaikan sebelum menambahkan yang lain.

Singkirkan dulu jalur luar

Tidak ada kumpulan yang bisa membantu jika tunnel tidak pernah terbentuk. Protokol menentukan apa yang harus dibawa jalur: PPTP menginginkan TCP 1723 dan GRE, yaitu protokol IP 47 bukan port; L2TP/IPsec menginginkan UDP 1701 plus 500 dan 4500; SSTP menginginkan TCP 443.

Router yang meneruskan port tetapi bukan protokolnya menghasilkan upaya koneksi yang tidak pernah terautentikasi. Itu kegagalan berbeda dari tunnel yang terbentuk lalu tidak mencapai apa pun, dan keduanya tidak boleh di-debug bersama.

Uji dari LAN yang sama dan dari jaringan jarak jauh. Jika upaya LAN berhasil dan yang jauh tidak pernah mencapai autentikasi, jalur luarlah masalahnya. Jika keduanya terautentikasi dan hanya klien jauh yang tidak punya internet, kembali ke kumpulan dan jalan keluar.