MTU VPN iPhone: tentukan pemilik sebelum menukar nombor

Setiap perbincangan tentang saiz paket VPN iPhone akhirnya menawarkan arahan Mac yang sama terhadap antara muka bernama ppp0, biasanya dengan nombor terlekat. Ia tidak terpakai, dan ia pun bukan kawalan yang betul walaupun pada Mac melainkan antara muka itu milik sambungan berkenaan. Pada telefon, nombor itu dimiliki oleh sesiapa yang melaksanakan terowong: sistem pengendalian untuk profil asli, penyedia terowong paket untuk aplikasi, atau gerbang apabila atribut berdokumen dirundingkan. Tiga soalan menentukan yang mana satu daripada kes itu yang anda hadapi.

Soalan pertama: klien mana yang berjalan

Profil IKEv2 asli, profil Cisco IPsec terbina dalam dan klien Cisco pihak ketiga ialah tiga pelaksanaan berbeza dengan tiga set atribut disokong yang berbeza. Jenis profil dalam Tetapan memberitahu anda yang mana telefon itu benar-benar mulakan, dan senarai aplikasi memberitahu sama ada penyedia ada di laluan. Mulakan dari situ, kerana baki keputusan mengikut daripadanya. Jika tiada penyedia muncul dalam senarai aplikasi, terowong dimiliki oleh sistem pengendalian.

Jangan simpulkan pelaksanaan daripada vendor gerbang. Sesuatu kepala Cisco boleh menamatkan sambungan daripada klien yang tidak berkongsi apa-apa kecuali nama vendor. Tangkapan skrin binaan lama pada keluaran lama memberitahu apa yang pasangan itu sokong, bukan apa yang telefon di tangan anda lakukan.

Soalan kedua: siapa yang memiliki nilai itu

Apple mendedahkan sifat MTU kepada pembangun terowong paket melalui objek tetapan sambungan rangkaian. Ia API untuk penyedia yang mengkonfigurasi terowongnya sendiri, bukan suis yang boleh dihidupkan oleh pengguna atau pentadbir pada klien terpasang orang lain. Aplikasi pihak ketiga boleh memilih untuk mendedahkannya, mengabaikannya atau mengodkan nilai secara keras.

Untuk profil asli, sistem pengendalian memilih saiz antara muka, dan telefon tidak mendedahkan sebarang penyunting untuknya. Untuk gerbang akses jauh Cisco ada atribut berdokumen untuk profil sambungan, dan sama ada ia terpakai bergantung pada klien, keluaran dan pengangkutan yang dirundingkan. Jurang antara yang berdokumen dan yang dipatuhi itulah tempat nombor yang disalin menjadi salah.

Soalan ketiga: adakah simptom bergantung pada saiz

Masalah saiz mempunyai tandatangan: permintaan kecil berjaya, muat naik besar atau respons besar tergantung, dan perkhidmatan yang sama berfungsi melalui rangkaian akses lain. Penapisan, had muatan aplikasi dan pelayan yang tersekat boleh menghasilkan aduan yang serupa, jadi catat satu operasi yang gagal di sebelah yang berjaya. Tulis kedua-duanya dengan masa dan saiz jika aplikasi melaporkannya. Tanpa pasangan itu, setiap perubahan kemudian hanyalah tekaan.

Jalankan ujian yang sama pada Wi-Fi dan pada rangkaian selular. Kegagalan yang mengikut rangkaian menunjuk kepada laluan; yang mengikut peranti menunjuk kepada klien atau profil, dan kedua-duanya memerlukan pemilik berbeza. Gunakan perkhidmatan dan akaun yang sama untuk kedua-dua larian, jika tidak perbandingan tidak memberitahu apa-apa.

Mengapa resipi Mac terus muncul

Bertahun-tahun VPN desktop berasaskan PPP menjadikan perubahan saiz antara muka sebagai jalan pintas setempat yang sah, dan arahan itu disalin ke dalam perbincangan mudah alih. Pada telefon tiada shell, tiada nama antara muka sedemikian dan tiada ketekalan selepas menyambung semula. Resipi yang menyelesaikan masalah desktop pada 2011 mengembara jauh lebih jauh daripada syarat yang menjadikannya benar. Klien mudah alih tidak menerima sebarang arahan shell untuk ini, apa pun yang didakwa oleh perbincangan itu.

Anggap nilai yang disalin sebagai hipotesis tentang laluan, bukan sebagai tetapan. Jika saiz lebih kecil membuat pemindahan berjaya dan saiz lebih besar gagal secara boleh dipercayai, anda mempunyai bukti tentang laluan itu; anda masih perlu mencari komponen yang dibenarkan bertindak ke atasnya. Pencarian itu biasanya berakhir pada profil gerbang atau vendor aplikasi, dan jarang pada telefon.

Pengangkutan mengubah jawapannya

Jika sesi berjalan melalui TLS dan bukan IPsec, pelarasan segmentasi TCP pada gerbang boleh membantu, kerana ia menulis semula saiz segmen yang diiklankan untuk aliran TCP. Ia tidak melakukan apa-apa untuk trafik UDP, yang merangkumi lebih banyak web moden daripada yang dijangka orang. Semak pengangkutan yang dirundingkan sebelum mencadangkan perubahan itu, dan namakan dalam tiket pengangkutan mana yang anda jangka akan terjejas.

Penemuan MTU laluan wujud supaya hujung-hujung dapat mempelajari had sebenar dan bukan meneka. Menyekat maklum balas dan mengodkan saiz kecil secara keras menukar pemindahan besar yang berfungsi dengan kos kekal dan tersembunyi pada setiap sambungan.

Apa yang perlu ditanya kepada pasukan gerbang

Minta tiga perkara: nama atribut yang tepat dan skopnya, sama ada klien yang digunakan mematuhinya, dan pengangkutan mana yang dirundingkan oleh sesi. Perubahan yang digunakan pada satu dasar kumpulan boleh diuji; suntingan global tidak, dan ia memindahkan risiko kepada pengguna yang tidak pernah melaporkan masalah. Minta juga rujukan dokumen, kerana nama atribut berubah antara keluaran.

Kemudian ubah satu perkara dan uji semula operasi asal yang gagal, bukan muat turun ujian kelajuan. Simpan rekod sebelum dan selepas bersama versi klien dan rangkaian akses, supaya laporan seterusnya boleh dibandingkan dan bukan dipertikaikan semula.

Jika operasi masih gagal pada saiz asal, saiz itu bukan puncanya. Catat juga kesimpulan itu, supaya orang seterusnya tidak membuka semula hipotesis yang sama.