L2TP tanpa IPsec di Linux: xl2tpd, pppd dan NAT

L2TP kosong ialah PPP di dalam sampul, dan tidak lebih. Ia membawa bingkai anda; ia tidak menyulitkannya dan tidak membuktikan siapa duduk di hujung sana, sebab itulah hampir setiap penggunaan menyelitkan IPsec di bawahnya. Sebab jujur untuk menjalankan versi bogel masih ada: bangku makmal, langkah migrasi, atau pautan yang sudah berada di dalam laluan terlindung yang lain.

Jika anda teruskan, catat amaran itu dalam nota reka bentuk dan biarkan ia di sana. Yang berikut ialah laluan operasi yang saya gunakan pada hos keluarga Debian dan RHEL: fail mana bertanggungjawab atas apa, MTU yang menghalang tersekat klasik, dan peraturan penghantaran yang menjadikan terowong itu berbaloi.

Tiga fail berkongsi kerja

xl2tpd menamatkan sambungan kawalan dan menyerahkan setiap sesi kepada daemon PPP, jadi konfigurasi terbahagi antara dua program yang tidak pernah membaca fail satu sama lain. Pendengar berada di /etc/xl2tpd/xl2tpd.conf, di dalam bahagian [lns default] yang menamakan kolam alamat dengan ip range, hujung pelayan dengan local ip, dan penyerahan kepada PPP dengan pppoptfile. Hidupkan require authentication = yes, biarkan length bit dan flow bit dihidupkan, dan pilih kolam yang belum digunakan oleh apa-apa lagi pada hos.

Dasar PPP tergolong dalam fail yang dinamakan pilihan itu, biasanya /etc/ppp/options.xl2tpd: auth, penolakan untuk pap, chap dan mschap, require-mschap-v2, MTU dan MRU 1460, dan alamat DNS yang boleh dicapai klien selepas pautan naik. Kredensial ialah fail ketiga pula, /etc/ppp/chap-secrets, di mana medan kedua mesti sepadan dengan nama bahagian LNS dan medan keempat boleh memakukan alamat tertentu daripada kolam.

Mengapa terowong bersambung lalu tersekat

Bingkai Ethernet 1500 bait tidak muat di dalam laluan yang sudah membelanjakan bait pada pengepalanya sendiri. Pengepala IPv4 luar mengambil 20, UDP 8, dan pengepala L2TP kira-kira 12, yang meninggalkan 1460 untuk PPP dan muatannya. Mengumumkan angka yang lebih kecil itu dalam PPP itulah yang menghalang paket besar daripada dipecahkan atau digugurkan secara senyap di suatu tempat di tengah.

Gejalanya ialah terowong yang kelihatan sihat sehingga trafik sebenar tiba: ping dan mesej kawalan lalu, salinan fail tersekat, tiada apa dalam log menjelaskannya. Turunkan MTU dan MRU bersama-sama di kedua-dua hujung. Melaras klien sahaja biasanya menukar tersekat keras kepada tersekat sekali-sekala, yang lebih sukar didiagnosis.

Satu port membawa dua perbualan

UDP 1701 berada di bawah kedua-dua separuh protokol, dan fakta tunggal itu memecahkan lebih banyak peraturan firewall daripada mana-mana bahagian lain persediaan. Mula-mula datang permintaan permulaan sambungan kawalan dan jawapannya; permintaan sesi dan pengesahan yang menyusul tidak menubuhkan apa-apa melebihi pasangan pengecam. Selepas itu PPP mengambil alih: kawalan pautan, kemudian pengesahan, kemudian protokol kawalan IP untuk menyelesaikan alamat. Setiap peringkat mempunyai kosa kata sendiri dalam log, dan tiada satu pun mengumumkan dirinya sebagai kegagalan L2TP.

Membaca tangkapan tepat dalam urutan itu memberitahu anda peringkat mana yang gagal, dan kegagalan pengesahan PPP tidak akan dibaiki dengan menyunting xl2tpd. Port yang dikongsi menjelaskan satu lagi kegagalan lazim: peraturan yang hanya membenarkan paket pertama sesuatu aliran membiarkan sesi terbentuk dan kemudian menyekat pemindahan. Benarkan 1701 untuk seluruh perbualan, dalam kedua-dua arah.

Menjadikan terowong berguna: penghantaran dan NAT

Sesi dengan sendirinya hanya sampai ke pelayan. Akses internet klien memerlukan penghantaran, peraturan NAT untuk kolam pada pautan atas, dan DNS yang benar-benar boleh ditanya oleh klien selepas pautan naik. Kolam juga mesti kekal di luar julat LAN, jika tidak balasan yang dialamatkan kepada klien dihantar secara setempat dan bukannya ditolak kembali ke dalam terowong.

Pada pelayan, hidupkan penghantaran dengan sysctl -w net.ipv4.ip_forward=1, terjemahkan kolam dengan iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE, kemudian terima trafik terowong keluar dengan peraturan FORWARD untuk -i ppp0 -o eth0 dan trafik balik dengan peraturan cermin serta -m state --state RELATED,ESTABLISHED. Kekalkan peraturan itu selepas but semula, kerana pelayan yang kembali tanpa peraturan itu kelihatan tepat seperti konfigurasi L2TP yang rosak.

Mencapai LAN pelayan itu sendiri ialah tugas lain: tambah laluan balik untuk kolam pada penghala LAN, atau proxy ARP pada pelayan. Menyembunyikan klien di belakang NAT apabila sesuatu di dalam LAN mesti menujukan mereka secara langsung hanya menjadualkan sesi penyahpepijatan kedua untuk kemudian.

Apa yang tindanan bogel tidak lakukan, dan cara mengesahkannya

Tiada bahagian dalam tindanan ini menyulitkan bingkai PPP, dan tiada apa di dalamnya mengesahkan hujung jauh sebagai pelayan yang benar-benar anda pilih. MS-CHAPv2 memang melindungi pertukaran kredensial daripada pendengar yang hanya memerhati, tetapi penyerang yang berada di laluan masih boleh mengganggu sesi. Klien asli Windows menawarkan L2TP hanya bersama IPsec, jadi perhitungkan Linux, firmware penghala dan klien pihak ketiga sebagai rakan anda. Anggap konfigurasi bogel sebagai batu loncatan diagnostik, tidak pernah sebagai tempat untuk berhenti.

Sahkan dalam urutan tetap: jalankan xl2tpd -D di latar depan, perhatikan jurnal untuk peringkat PPP, baca alamat yang diberikan daripada ip addr di kedua-dua hujung, kemudian tangkap UDP 1701 untuk mengesahkan data mengalir selepas sesi naik. Jika keempat-empatnya sepadan dan trafik masih gagal, kesalahannya pada penghalaan, NAT atau MTU, bukan pada L2TP itu sendiri.