Belajar PPTP - Legacy System Integration

#Pendahuluan

Di dunia nyata, server PPTP tidak hanya berbasis Linux. Banyak organisasi menjalankan PPTP di Windows Server atau di belakang perangkat keras vendor seperti Cisco dan Juniper. Episode 18 membahas integrasi dengan ekosistem legacy ini.

Kalau kalian bekerja dengan infrastruktur enterprise, besar kemungkinan bertemu dengan RRAS, NPS, atau firewall vendor yang meneruskan PPTP. Memahami peran masing-masing akan membuat kalian lebih percaya diri saat merawat atau menggantinya.

#Windows Server dan RRAS

#Routing and Remote Access

Di Windows Server, layanan PPTP disediakan oleh RRAS (Routing and Remote Access). RRAS membuka port 1723, menerima koneksi PPTP, dan menangani tunnel lewat fitur VPN bawaan.

Get-Service RemoteAccess

Get-Service RemoteAccess di PowerShell menampilkan status layanan RRAS. Setelah RRAS dikonfigurasi sebagai VPN server dengan protocol PPTP, interface WAN Miniport (PPTP) akan muncul di daftar interface.

#Konfigurasi VPN Server

Konfigurasi dilakukan lewat Routing and Remote Access console atau PowerShell. Administrator menunjuk interface mana yang menerima koneksi VPN, memilih rentang alamat untuk klien, dan menentukan metode autentikasi. Untuk PPTP, metode yang diizinkan umumnya MS-CHAPv2 dengan enkripsi MPPE 128-bit.

#Autentikasi Windows vs RADIUS

RRAS bisa mengautentikasi langsung ke Active Directory atau meneruskan permintaan ke RADIUS (NPS). Pendekatan kedua lebih disukai di organisasi besar karena kebijakan terpusat dan log yang lengkap.

Keputusan ini menentukan arsitektur: jika NPS dipakai, pastikan shared secret antara RRAS dan NPS konsisten, dan client (NAS) terdaftar dengan benar di NPS. Kegagalan di titik ini muncul sebagai error autentikasi yang sering keliru dikira masalah password.

#NPS: Kebijakan dan Autentikasi Terpusat

#Network Policy Server

Di belakang RRAS, NPS (Network Policy Server) menyediakan autentikasi dan otorisasi terpusat. RRAS mengirim permintaan autentikasi ke NPS, yang menentukan apakah koneksi diterima berdasarkan kebijakan.

NPS menggantikan peran RADIUS server dan bisa menjadi titik tunggal untuk mengelola siapa yang boleh terhubung dan hak apa yang didapat. Koneksi PPTP yang gagal autentikasi sering kali bisa ditelusuri dari log NPS.

Show-NpsRadiusServer

#Menganalisis Log NPS

Log NPS adalah sumber utama saat koneksi PPTP ditolak di sisi kebijakan. Peristiwa autentikasi bisa dibaca lewat Windows Event Log:

Get-WinEvent -LogName "Microsoft-Windows-NPS/Operational" -MaxEvents 50

Get-WinEvent -LogName "Microsoft-Windows-NPS/Operational" -MaxEvents 50 menampilkan 50 event terakhir dari log operasional NPS. Cocokkan timestamp dengan kegagalan di sisi klien untuk mengetahui kebijakan mana yang menolak koneksi, lengkap dengan alasan penolakannya.

#Perangkat Cisco dan Juniper

#PPTP di Ekosistem Vendor

Perangkat jaringan vendor seperti Cisco dan Juniper umumnya tidak menyediakan server PPTP sebagai fitur utama, tapi mereka sering berperan sebagai gateway yang meneruskan atau memblokir traffic PPTP. Di Cisco, misalnya, kebijakan firewall dan konfigurasi GRE passthrough menentukan apakah TCP 1723 dan GRE bisa lewat.

access-list 100 permit tcp any host 203.0.113.10 eq 1723
access-list 100 permit gre any host 203.0.113.10

Pola access-list 100 permit gre any host 203.0.113.10 menggambarkan aturan yang mengizinkan GRE menuju server PPTP. Konfigurasi persisnya berbeda antar vendor, tapi prinsipnya sama: kedua jalur (TCP 1723 dan GRE) harus diizinkan.

#Perbedaan Pendekatan Vendor

Walaupun kebanyakan perangkat vendor hanya meneruskan PPTP, beberapa model tertentu pernah menyediakan kemampuan server PPTP atau termination tunnel. Implementasi semacam ini sering kali tidak lengkap dibandingkan RRAS atau pptpd di Linux.

Ketika mengintegrasikan perangkat seperti itu, periksa dokumentasi versi firmware untuk fitur VPN mana yang benar-benar didukung. Mengasumsikan fitur yang sama antar vendor adalah sumber kesalahan konfigurasi yang paling umum di lapangan.

#Isu Interoperabilitas

#Masalah yang Sering Muncul

Saat PPTP melewati ekosistem campuran, beberapa isu klasik sering muncul:

• MTU mismatch: perangkat di tengah menurunkan MTU, tapi tunnel tidak menyesuaikan.
• ALG conflict: PPTP ALG di satu perangkat justru memecah koneksi di perangkat lain.
• Perbedaan implementasi MS-CHAPv2: beberapa vendor lama tidak mendukung varian tertentu.
• NAT ganda: dua lapis NAT membuat GRE tidak bisa diteruskan.

Diagnosis lintas vendor membutuhkan pendekatan sistematis: verifikasi konektivitas per lapisan, bukan langsung menyalahkan satu perangkat.

#Matriks Pengujian Lintas Vendor

Sebelum menyerah pada isu interoperabilitas, bangun matriks pengujian sederhana: kombinasi klien dan server yang harus didukung, dengan hasil tes untuk setiap pasangan. Catat parameter penting seperti versi firmware, setelan MTU, dan status ALG di setiap titik.

Dengan matriks ini, masalah yang tadinya terlihat acak menjadi pola yang bisa dilacak. Perbaikan pun bisa diarahkan ke pasangan spesifik, bukan menebak-nebak konfigurasi global yang justru membuat masalah baru.

Jangan lupa peran dokumentasi vendor: banyak perangkat mencatat alasan penolakan koneksi di log internal. Log ini sering mengungkap detail yang tidak terlihat di sisi klien atau server, misalnya perbedaan setelan MTU atau versi protokol yang tidak didukung.

Gabungkan log vendor dengan log RRAS/NPS dan capture di jalur untuk membangun gambaran lengkap. Dengan begitu, kesimpulan akhir didasarkan pada bukti dari semua lapisan, bukan tebakan dari satu sudut pandang.

#Penutup

Episode 18 memetakan integrasi PPTP di dunia enterprise legacy: RRAS di Windows Server, NPS sebagai pusat kebijakan, peran perangkat Cisco dan Juniper sebagai gateway, serta isu interoperabilitas yang umum terjadi.

Inti yang harus dibawa pulang:

• RRAS menyediakan server PPTP di Windows Server.
• NPS memberi autentikasi dan kebijakan terpusat untuk RRAS.
• Perangkat Cisco dan Juniper umumnya meneruskan atau memblokir PPTP.
• Jalur TCP 1723 dan GRE harus diizinkan di perangkat gateway.
• MTU mismatch dan ALG conflict adalah isu interop yang paling umum.
• Diagnosis lintas vendor harus dilakukan per lapisan.

Di episode 19 selanjutnya kita akan membahas migrasi dari PPTP ke OpenVPN atau WireGuard — perencanaan migrasi, pilot deployment, periode paralel, cutover, dan decommission server PPTP.