Split tunneling PPTP tidak berfungsi: perbaiki jalur GRE lebih dulu

Amati koneksi PPTP naik dan mudah percaya bahwa bagian tersulit sudah selesai: klien melakukan autentikasi, adaptor ppp0 atau WAN Miniport muncul, dan jendela status menjadi hijau. Lalu permintaan pertama ke host internal habis waktu, dan profil disalahkan. Dalam praktik ada dua lapisan independen yang harus dibereskan: transport luar yang membawa TCP 1723 dan GRE, serta kebijakan dalam yang menentukan tujuan mana yang memakai antarmuka PPP. Status hijau hanya membuktikan lapisan pertama sudah bernegosiasi; soal lapisan kedua ia tidak berkata apa-apa.

Ikuti klien dari profil sampai soket kendali

Buka log klien dan temukan titik ketika ia menghubungi server. PPTP lebih dulu membuka koneksi TCP ke port 1723 dan menegosiasikan parameter tunnel melalui kanal itu. Jika langkah ini gagal, tidak ada yang penting setelahnya, dan galat biasanya menyebut alamat server atau batas waktu.

Pastikan koneksi kendali di jaringan sebelum menyentuh rute apa pun. Di klien atau port cermin, tangkap TCP 1723 untuk satu percobaan koneksi:

sudo tcpdump -ni any 'tcp port 1723' -c 20

Jabat tangan yang selesai dan sesi yang terbentuk berarti kanal kendali luar bekerja. SYN yang tidak pernah mendapat SYN-ACK menunjuk ke firewall, alamat server yang salah, atau penyedia yang menyaring port. Jabat tangan yang langsung diikuti reset sering berarti server menolak kredensial atau jenis tunnel.

GRE adalah protokol kedua, bukan port

PPTP membawa muatan PPP di dalam GRE yang diperluas, protokol IP 47, yang tidak punya nomor port untuk dilacak router. Karena itu aturan yang mengizinkan TCP 1723 masih bisa meninggalkan tunnel tanpa jalur data. Perangkat NAT stateful harus memahami ID panggilan di dalam GRE untuk memetakan balasan, dan banyak yang tidak melakukannya. Spesifikasi PPTP memisahkan kanal kendali dan muatan GRE sebagai bagian terpisah, dan rencana uji Anda juga harus begitu.

Pantau protokol 47 pada tangkapan yang sama, lalu bandingkan apa yang keluar dengan apa yang kembali:

sudo tcpdump -ni any 'proto gre' -c 20

Paket yang keluar tanpa balasan, sementara TCP 1723 tetap sehat, adalah tanda khas GRE terblokir. Passthrough PPTP pada router konsumen adalah fitur firmware tertentu itu, jadi jaringan hotel yang berfungsi tidak membuktikan apa pun tentang jaringan berikutnya. Jika router tidak menawarkan passthrough dan Anda tidak bisa mengubahnya, masalahnya adalah pilihan protokol, bukan tabel rute.

Buktikan tunnel memindahkan satu paket

Setelah GRE mengalir, negosiasi PPP memberi alamat pada antarmuka klien. Baca penetapannya alih-alih menganggapnya:

ip -4 addr show ppp0

Ping alamat peer yang ditampilkan sebagai tujuan tautan titik-ke-titik. Balasan pada tahap ini membuktikan jalur terenkapsulasi bekerja dari ujung ke ujung dan server menjawab di dalam tunnel. Jika peer menjawab tetapi host internal tidak, transport luar baik-baik saja dan kegagalan berpindah ke dalam.

Lakukan ini sebelum menambahkan rute terpisah apa pun. Perubahan rute yang dibuat saat transport rusak menciptakan variabel kedua dan menyembunyikan yang pertama.

Tulis kebijakan terpisah, termasuk DNS

Perutean terpisah adalah daftar keputusan, bukan kotak centang. Setiap prefiks privat yang harus melewati tunnel memerlukan rute melalui antarmuka PPP, dan setiap prefiks yang harus tetap lokal harus tidak ada di dalamnya. Rute untuk subnet aplikasi tanpa rute yang cocok ke resolver privatnya adalah cara umum menciptakan gangguan yang terlihat seperti aplikasi rusak.

Periksa keputusan yang diambil kernel untuk satu alamat di tiap kategori:

ip route get 10.20.5.10
ip route get 203.0.113.25

Yang pertama harus menyebut ppp0, yang kedua gateway biasa. Jika keduanya menyebut antarmuka yang sama, kebijakan itu tidak terpisah sama sekali. Tambahkan alamat server DNS itu sendiri ke daftar tunnel, jika tidak resolusi nama untuk host internal keluar melalui resolver lokal dan tidak mengembalikan apa pun yang berguna.

Pemeriksaan yang bisa diulang dalam lima langkah

Jalankan lapisan secara berurutan dan berhenti pada yang pertama gagal: kanal kendali, visibilitas GRE, balasan peer PPP, rute terpisah untuk satu alamat internal, dan permintaan aplikasi melalui tunnel. Setiap langkah punya perintahnya sendiri, jadi kegagalan bisa diatribusikan, bukan misterius.

Versi ringkas untuk klien Linux tampak 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

Di Windows urutan yang sama berlaku dengan route print dan status adaptor yang ditampilkan di klien. PPTP adalah protokol lama, dan jika server menawarkan SSTP atau IKEv2, pindah biasanya lebih baik penggunaan waktu daripada menyetel jalur yang bergantung pada lolosnya protokol 47 di setiap lompatan. Periksa sertifikat dan kontrak autentikasi penggantinya alih-alih menyalin profil lama ke rilis baru.