iPhone VPN:n MTU: valitse omistaja ennen kuin muutat numeroa
Kolme kysymystä ratkaisee, voiko sovellus, yhdyskäytäväprofiili vai ei kukaan puhelimessa muuttaa kokoa. Vastaa niihin ennen kuin lainaat numeroa Macista.
Jokainen iPhone VPN:n pakettikokoa käsittelevä ketju tarjoaa lopulta saman Mac-komennon ppp0-nimistä liitäntää vastaan, yleensä numero mukanaan. Se ei siirry, eikä se olisi oikea hallintakeino edes Macissa, ellei tuo liitäntä kuuluisi kyseiseen yhteyteen. Puhelimessa numeron omistaa se, joka toteuttaa tunnelin: käyttöjärjestelmä natiivissa profiilissa, pakettitunnelin tarjoaja sovelluksessa tai yhdyskäytävä, kun dokumentoitu attribuutti neuvotellaan. Kolme kysymystä selvittää, kumpi tapaus sinulla on.
Kysymys yksi: mikä asiakas on käynnissä
Natiivi IKEv2-profiili, sisäänrakennettu Cisco IPsec -profiili ja kolmannen osapuolen Cisco-asiakas ovat kolme eri toteutusta, joilla on kolme eri tuettujen attribuuttien joukkoa. Asetusten profiilityyppi kertoo, minkä puhelin todella käynnisti, ja sovellusluettelo kertoo, onko polulla ylipäätään tarjoajaa. Aloita siitä, koska muu päätös seuraa siitä. Jos sovellusluettelossa ei näy tarjoajaa, käyttöjärjestelmä omistaa tunnelin.
Älä päättele toteutusta yhdyskäytävän toimittajasta. Cisco-keskus voi lopettaa yhteyksiä asiakkailta, joilla ei ole yhteistä muuta kuin toimittajan nimi. Kuvakaappaus vanhasta koontiversiosta vanhassa julkaisussa kertoo, mitä tuo pari tuki, ei sitä, mitä kädessäsi oleva puhelin tekee.
Kysymys kaksi: kuka omistaa arvon
Apple tarjoaa MTU-ominaisuuden pakettitunnelikehittäjille verkkolaajennuksen asetusobjektin kautta. Se on API tarjoajalle, joka määrittää oman tunnelinsa, ei kytkin, jonka käyttäjä tai ylläpitäjä voisi kytkeä toisen asennettuun asiakkaaseen. Kolmannen osapuolen sovellus voi valita sen tarjoamisen, sivuuttamisen tai arvon kovakoodaamisen.
Natiivissa profiilissa käyttöjärjestelmä valitsee liitännän koon, eikä puhelin tarjoa siihen mitään editoria. Ciscon etäkäyttöyhdyskäytävälle on dokumentoitu attribuutti yhteyden profiilille, ja sen soveltuminen riippuu asiakkaasta, julkaisusta ja neuvotellusta siirrosta. Juuri siinä raossa dokumentoidun ja noudatetun välillä kopioitu numero menee pieleen.
| Owner | Who can change it | Reachable from the phone |
|---|---|---|
| Packet-tunnel provider | The app vendor through its API | Only if the app exposes a setting |
| Native IKEv2 or Cisco IPsec profile | The operating system | No user control |
| Gateway group policy attribute | The gateway administrator | If the client honours it |
Kysymys kolme: riippuuko oire ylipäätään koosta
Koko-ongelmilla on allekirjoitus: pienet pyynnöt onnistuvat, suuret lataukset tai suuret vastaukset jumittuvat ja sama palvelu toimii toisen liityntäverkon kautta. Suodatus, sovelluksen hyötykuorman raja ja jumiutunut palvelin voivat tuottaa samanlaisen valituksen, joten kirjaa yksi epäonnistuva toiminto toimivan viereen. Kirjoita molemmat muistiin aikoineen ja kokoineen, jos sovellus raportoi ne. Ilman tätä paria jokainen myöhempi muutos on arvailua.
Tee sama testi Wi-Fi-verkossa ja matkapuhelinverkossa. Verkkoa seuraava vika osoittaa polkuun; laitetta seuraava vika asiakkaaseen tai profiiliin, ja ne tarvitsevat eri omistajat. Käytä samaa palvelua ja samaa tiliä molemmissa ajoissa, muuten vertailu ei kerro sinulle mitään.
Miksi Mac-resepti ilmestyy yhä uudelleen
Vuosien PPP-pohjaiset työpöytä-VPN:t tekivät liitännän koon muuttamisesta laillisen paikallisen kiertotien, ja ne ohjeet kopioitiin mobiiliketjuihin. Puhelimessa ei ole kuorta, ei sellaista liitännän nimeä eikä pysyvyyttä uudelleenyhdistämisen yli. Resepti, joka ratkaisi työpöytäongelman vuonna 2011, matkasi paljon kauemmas kuin ne olosuhteet, jotka tekivät siitä totta. Mobiiliasiakkaat eivät hyväksy tähän mitään kuorikomentoa, mitä ketju väittääkin.
Käsittele kopioitua arvoa polkua koskevana hypoteesina, älä asetuksena. Jos pienempi koko saa siirron toimimaan ja suurempi epäonnistuu luotettavasti, sinulla on todisteita polusta; sinun on silti löydettävä komponentti, jolla on lupa vaikuttaa siihen. Se etsintä päättyy yleensä yhdyskäytäväprofiiliin tai sovelluksen toimittajaan ja harvoin puhelimeen.
Siirto muuttaa vastausta
Jos istunto kulkee IPsecin sijaan TLS:n yli, TCP-segmentoinnin säätö yhdyskäytävässä voi auttaa, koska se kirjoittaa uudelleen TCP-virroille ilmoitetun segmentin koon. Se ei tee mitään UDP-liikenteelle, joka kattaa enemmän nykyisestä verkosta kuin ihmiset odottavat. Tarkista neuvoteltu siirto ennen muutoksen ehdottamista ja nimeä tiketissä, mihin siirtoon odotat sen vaikuttavan.
Polun MTU:n etsintä on olemassa, jotta päät voivat oppia todellisen rajan arvaamisen sijaan. Palautteen estäminen ja pienen koon kovakoodaaminen vaihtaa toimivan suuren siirron pysyvään, piilotettuun kustannukseen jokaisessa yhteydessä.
Mitä yhdyskäytävätiimiltä kannattaa kysyä
Pyydä kolmea asiaa: attribuutin tarkka nimi ja sen laajuus, noudattavatko käyttöön otetut asiakkaat sitä, ja minkä siirron istunto neuvotteli. Yhteen ryhmäkäytäntöön sovellettu muutos on testattavissa; globaali muokkaus ei ole, ja se siirtää riskin käyttäjille, jotka eivät koskaan ilmoittaneet ongelmaa. Pyydä myös asiakirjan viite, koska attribuuttien nimet vaihtuvat julkaisujen välillä.
Muuta sitten yhtä asiaa ja testaa uudelleen alkuperäinen epäonnistuva toiminto, älä nopeustestin latausta. Pidä ennen ja jälkeen -kirjausta yhdessä asiakasversion ja liityntäverkon kanssa, jotta seuraavaa raporttia voi verrata sen sijaan että se riidellään uudelleen.
Jos toiminto epäonnistuu edelleen alkuperäisellä koolla, koko ei ollut syy. Kirjaa myös tämä päätelmä, jotta seuraava henkilö ei avaa samaa hypoteesia uudelleen.