Tunneling terbelah PPTP tidak berfungsi: betulkan laluan GRE dahulu
Tunneling terbelah PPTP gagal atas dua sebab berbeza: GRE disekat, atau laluan dalaman tiada. Uji pengangkutan dahulu, kemudian dasar.
Tonton sambungan PPTP naik dan mudah percaya bahagian sukar sudah selesai: klien mengesahkan dirinya, penyesuai ppp0 atau WAN Miniport muncul, dan tetingkap status menjadi hijau. Kemudian permintaan pertama ke hos dalaman tamat masa, dan profil dipersalahkan. Dalam amalan ada dua lapisan bebas untuk dibersihkan: pengangkutan luar yang membawa TCP 1723 dan GRE, dan dasar dalaman yang menentukan destinasi mana menggunakan antara muka PPP. Status hijau hanya membuktikan lapisan pertama telah berunding; tentang lapisan kedua ia tidak berkata apa-apa.
Ikuti klien dari profil ke soket kawalan
Buka log klien dan cari titik ia menghubungi pelayan. PPTP mula-mula membuka sambungan TCP ke port 1723 dan merundingkan parameter terowong melalui saluran itu. Jika langkah ini gagal, tiada apa selepasnya penting, dan ralat biasanya menyebut alamat pelayan atau tamat masa.
Sahkan sambungan kawalan pada wayar sebelum menyentuh mana-mana laluan. Pada klien atau port cermin, tangkap TCP 1723 untuk satu percubaan sambungan:
sudo tcpdump -ni any 'tcp port 1723' -c 20
Jabat tangan selesai dan sesi terjalin bermakna saluran kawalan luar berfungsi. SYN yang tidak pernah menerima SYN-ACK menunjukkan dinding api, alamat pelayan yang salah, atau penyedia yang menapis port. Jabat tangan diikuti tetapan semula segera selalunya bermakna pelayan menolak kelayakan atau jenis terowong.
GRE ialah protokol kedua, bukan port
PPTP membawa muatan PPP di dalam GRE diperluas, protokol IP 47, yang tidak mempunyai nombor port untuk dijejaki penghala. Itulah sebabnya peraturan yang membenarkan TCP 1723 masih boleh meninggalkan terowong tanpa laluan data. Peranti NAT berkeadaan perlu memahami ID panggilan di dalam GRE untuk memetakan balasan, dan banyak yang tidak melakukannya. Spesifikasi PPTP menyimpan saluran kawalan dan muatan GRE sebagai bahagian berasingan, dan pelan ujian anda juga harus begitu.
Perhatikan protokol 47 dalam tangkapan yang sama, kemudian bandingkan apa yang keluar dengan apa yang kembali:
sudo tcpdump -ni any 'proto gre' -c 20
Paket yang keluar tanpa balasan, sementara TCP 1723 kekal sihat, ialah tandatangan klasik GRE tersekat. Passthrough PPTP pada penghala pengguna ialah ciri firmware tertentu itu, jadi rangkaian hotel yang berfungsi tidak membuktikan apa-apa tentang rangkaian seterusnya. Jika penghala tidak menawarkan passthrough dan anda tidak boleh mengubahnya, masalahnya ialah pilihan protokol, bukan jadual laluan.
Buktikan terowong memindahkan satu paket
Sebaik GRE mengalir, rundingan PPP memberikan alamat kepada antara muka klien. Baca penetapan itu dan jangan menganggapnya:
ip -4 addr show ppp0
Ping alamat rakan yang ditunjukkan sebagai destinasi pautan titik ke titik. Balasan pada peringkat ini membuktikan laluan terkapsul berfungsi dari hujung ke hujung dan pelayan menjawab di dalam terowong. Jika rakan menjawab tetapi hos dalaman tidak, pengangkutan luar baik dan kegagalan telah bergerak ke dalam.
Lakukan ini sebelum menambah mana-mana laluan terbelah. Perubahan laluan yang dibuat semasa pengangkutan rosak mencipta pemboleh ubah kedua dan menyembunyikan yang pertama.
Tulis dasar terbelah, termasuk DNS
Penghalaan terbelah ialah senarai keputusan, bukan kotak semak. Setiap awalan peribadi yang mesti melintasi terowong memerlukan laluan melalui antara muka PPP, dan setiap awalan yang mesti kekal setempat mesti tiada daripadanya. Laluan untuk subrangkaian aplikasi tanpa laluan sepadan ke penyelesai peribadinya ialah cara biasa mencipta gangguan yang kelihatan seperti aplikasi rosak.
Periksa keputusan yang dibuat kernel untuk satu alamat dalam setiap kategori:
ip route get 10.20.5.10
ip route get 203.0.113.25
Yang pertama harus menamakan ppp0, yang kedua get laluan biasa. Jika kedua-duanya menamakan antara muka yang sama, dasar itu tidak terbelah sama sekali. Tambah alamat pelayan DNS itu sendiri ke senarai terowong, jika tidak penyelesaian nama untuk hos dalaman keluar melalui penyelesai setempat dan tidak memulangkan apa-apa yang berguna.
Semakan yang boleh diulang dalam lima langkah
Jalankan lapisan mengikut urutan dan berhenti pada yang pertama gagal: saluran kawalan, keterlihatan GRE, balasan rakan PPP, laluan terbelah untuk satu alamat dalaman, dan permintaan aplikasi melalui terowong. Setiap langkah mempunyai arahan sendiri, jadi kegagalan boleh diatribusikan dan bukan misteri.
Versi ringkas untuk klien Linux kelihatan seperti ini:
sudo tcpdump -ni any 'tcp port 1723 or proto gre' -c 40
ip -4 addr show ppp0
ping -c 3 192.0.2.1
ip route get 10.20.5.10
Pada Windows urutan yang sama terpakai dengan route print dan status penyesuai yang ditunjukkan dalam klien. PPTP ialah protokol lama, dan jika pelayan menawarkan SSTP atau IKEv2, berpindah biasanya penggunaan masa yang lebih baik daripada menala laluan yang bergantung pada protokol 47 melintasi setiap hop. Periksa sijil dan kontrak pengesahan pengganti dan jangan salin profil lama ke keluaran baharu.