Windows L2TP memuat sebagian situs: hapus bit DF di pfSense
Klien L2TP yang memuat intranet tetapi macet di sebagian situs publik mengalami masalah MTU. Hapus bit DF atau batasi MSS, lalu pastikan dengan rekaman.
Laptop terhubung, intranet termuat, dan beberapa situs publik macet. Autentikasi dan perutean jelas bekerja, sehingga ukuran paket menjadi penjelasannya. Di terowongan L2TP/IPsec MTU yang dapat dipakai lebih kecil daripada yang masih diumumkan adaptor, dan klien terus mengirim paket berukuran penuh dengan bit «jangan fragmentasi» aktif. Gateway pfSense dapat diperintahkan menghapus bit itu, dan itulah cara tercepat untuk memastikan diagnosis sebelum memperbaikinya dengan benar.
Mulai dari halaman yang gagal
Catat tujuan mana yang gagal dan mana yang berhasil sebelum menyentuh pengaturan apa pun. Jabat tangan yang tetap di bawah batas terowongan selesai normal, sedangkan transfer yang membutuhkan segmen berukuran penuh terhenti di tengah jalan. Pemisahan itu adalah ciri masalah ukuran, bukan penyaring, karena tujuan yang diblokir gagal saat koneksi dibangun, bukan di tengah halaman. Kedua pengamatan tidak memakan biaya dan langsung mempersempit pencarian.
Uji dengan ping yang menyetel bit dan mengendalikan ukuran muatan. Muatan terbesar yang bertahan memberi tahu MTU jalur sebenarnya, dan nilai yang diumumkan adaptor menunjukkan seberapa jauh keduanya.
Tulis kedua angka itu. Perbaikannya bergantung pada mana yang salah, dan pasangan itulah yang nanti dipastikan oleh rekaman.
Apa yang dilakukan bit DF saat keluar
Enkapsulasi adalah alasan angkanya berbeda. IPsec menambahkan ESP, L2TP menambahkan tajuk lain, sehingga terowongan membawa muatan lebih sedikit daripada tautan fisik. Windows masih melaporkan 1500 byte pada adaptor dan menyetel «jangan fragmentasi» pada yang dikirimnya. Ketika paket seperti itu tidak muat, jawaban yang benar dari gateway adalah pesan ICMP yang meminta pengirim mengecil. Itulah sebabnya terowongan yang meloloskan ping kecil tetap bisa menggagalkan unduhan berkas.
Pesan itu sering tidak pernah tiba. Sebuah hop dapat menyaring ICMP, atau tidak ada yang menghasilkannya, dan pengirim mengulangi ukuran yang sama sampai transfer menyerah.
Diam adalah tampilan normal di sini, karena itu gejalanya terbaca sebagai pemblokiran selektif. Tidak ada yang mencatat pesan ICMP yang hilang di log klien.
Opsi pfSense, dan apa yang tidak dilakukannya
Opsi itu ada di halaman Sistem, Lanjutan, Firewall dan NAT, berlabel «Hapus bit DF tidak valid alih-alih menjatuhkan paket». Alih-alih membuang paket kebesaran yang membawa tanda, penyaring melepas tanda itu dan membiarkan paket dipecah lebih jauh ke hilir. Paket dihitung tidak valid ketika tidak dapat melintasi antarmuka keluar dalam satu bagian.
Opsi itu memulihkan konektivitas tanpa menyentuh klien, karena itu populer. Ini juga akal-akalan: fragmentasi memakan CPU dan membuat setiap fragmen yang hilang lebih mahal.
Opsi ini hanya berlaku untuk lalu lintas yang diteruskan, bukan lalu lintas yang dibuat firewall itu sendiri. Halaman yang sama menawarkan «Nonaktifkan Pembersihan Firewall», yang mematikan normalisasi sepenuhnya, dan itu perubahan yang jauh lebih luas daripada yang dibutuhkan masalah ini.
Perbaikan lebih sempit yang menjaga TCP tanpa fragmentasi
Hampir semua aliran yang macet adalah TCP, dan TCP dapat menegosiasikan segmen lebih kecil alih-alih mengandalkan fragmentasi. Membatasi MSS pada antarmuka terowongan menulis ulang nilai yang diumumkan selama jabat tangan, sehingga tiap sisi mengirim apa yang benar-benar muat. Jalur kemudian berperilaku dapat diprediksi dan tidak ada paket yang perlu dipecah.
Itu menyisakan UDP untuk penemuan atau opsi DF. Ketika situs yang gagal adalah halaman web biasa, pembatasan itulah perubahan yang sebaiknya dipilih.
Klien dapat melaporkan MTU adaptornya sendiri melalui netsh interface ipv4 show subinterfaces. Bandingkan angka itu dengan yang dianggap server telah dinegosiasikan, karena keduanya tidak selalu sama. Nilai itulah yang benar-benar akan dipakai sistem operasi, apa pun yang dilaporkan negosiasi.
Pastikan dengan rekaman, lalu atur ulang keadaan
Rekam di kedua sisi sebelum memutuskan: satu jejak di tempat terowongan berjalan, satu lagi di tempat antarmuka WAN berjalan. Paket yang keluar berukuran penuh tanpa ICMP yang kembali menunjuk pembatasan sebagai lapisan yang tepat. Balasan yang tiba lalu mati dalam perjalanan pulang menunjuk MTU terowongan sebagai gantinya.
Bersihkan tabel keadaan sebelum mencoba lagi, karena aliran yang ada mempertahankan ukuran segmen lamanya. Lalu muat halaman yang gagal dan baca tampilan keadaan untuk lalu lintas dua arah alih-alih penghitung satu sisi. Jika masih macet, rekam lagi alih-alih mencoba kotak centang lain.