iPhone Always On VPN: kaksi tunnelia voi jakaa yhden virtuaalisen IP:n

Valvotussa iPhonessa, jossa on hallinnoitu Always On -profiili, puhelin pitää tunnelia jokaista aktiivista IP-liitäntää kohden, joten matkapuhelinverkko ja Wi-Fi saavat kumpikin omansa. Palvelin luettelee tämän jälkeen kaksi IKE-turva-assosiaatiota yhtä laitetta kohden, usein jakaen yhden virtuaalisen osoitteen, ja ensimmäinen vaisto on kutsua sitä avaimen uusinnan silmukaksi ja alkaa muuttaa ajastimia. Tämä vaisto on yleensä väärä. Käy alla olevat vaiheet läpi siinä järjestyksessä, jossa todisteet ilmestyvät palvelimelle, ja jätä puhelimen asetukset rauhaan, kunnes palvelin kertoo, mikä tapaus sinulla on.

Aloita kahdesta rivistä, jotka palvelimella jo on

Luettele assosiaatiot komennolla swanctl --list-sas ja lue neljä kenttää molemmista merkinnöistä: etäosoite, todennettu identiteetti, osoitettu virtuaalinen IP ja luontiaika. Kaksi eri ulkoista osoitetta yhdellä identiteetillä ja yhdellä virtuaalisella IP:llä on muoto, joka aloitti tämän kysymyksen, ja se kannattaa kirjoittaa muistiin ennen mitään muutosta. Tarkista sitten kuhunkin liitetyt lapsiassosiaatiot, koska liikenteen valitsimet päättävät, voisiko kohdehaku koskaan erottaa kahta tunnelia toisistaan. Pari, joka ilmestyy ja katoaa sekunneissa, on eri eläin kuin pari, jotka molemmat elävät tunteja.

Järjestä luettelo luontiajan mukaan ennen johtopäätöksen tekemistä. Vierekkäisyys tulosteessa ei merkitse mitään, ja taulukkomuotoinen luettelo oikein kutsuu tuohon virheeseen.

Päätä, mitä päällekkäisyyttä katsot

IKEv2-avaimen uusinta ja make-before-break-uudelleentodennus luovat tarkoituksella lyhyen päällekkäisyyden, kun uusi assosiaatio perustetaan ennen vanhan poistamista. Aikaleimat ratkaisevat tapauksen, sillä vanha SA, joka katoaa sekunnin tai kaksi uuden ilmestymisen jälkeen, on uusintaa, joka tekee työnsä. Riippumattomat liitäntätunnelit eivät koskaan näytä siltä, koska kukin säilyy niin kauan kuin sen liitäntä on ylhäällä, eikä toisen poistaminen seuraa toisen luomisesta.

Applen hallinnoitu Always On -käyttäytyminen on liitäntäkohtaista, minkä vuoksi valvottu laite voi laillisesti näyttää kiireisemmältä kuin käsin määritetty profiili. Palveluntarjoajan sovelluksen automaattisen yhteyden kytkin ei tarkoita samaa, eikä tavallinen on-demand-sääntö. Applen käyttöönoton yleiskatsaus kuvaa liitäntäkohtaisen mallin; vertaa kahta riviäsi siihen ennen kuin oletat silmukan. Molemmat muodot ammentavat myös samasta palvelinvarannosta, joten päällekkäisyys on ainoa varhainen merkki.

Katso, miksi yksi virtuaaliosoite kahdelle tunnelille rikkoo vastaukset

Puhelimelle lähetetty vastaus osoitetaan sisäiseen osoitteeseen, ja ydin valitsee lähtevän tunnelin kohteen ja käytännön mukaan, ei sen liitännän mukaan, jota puhelin käytti. Kaksi samanaikaista assosiaatiota, jotka pitävät saman virtuaalisen IP:n yhtenevin käytännöin, jättävät reitityspäätöksen ilman keinoa sanoa, mihin istuntoon vastaus kuuluu. Jotkut vastaukset ottavat väärän tunnelin, ja puhelin näyttää yhteyden, joka toimii yhteen suuntaan tai kuolee, kun Wi-Fi nousee. Kaksi komentotulostetta todistaa tilan: swanctl --list-sas näyttää saman virtuaalisen IP:n molemmissa SA:issa ja ip xfrm policy näyttää kaksi identtistä valitsinta.

Juuri tuo tulostepari liitetään muutostietueeseen. Kumpikaan yksin ei ole vakuuttava, koska kumpikin voi näyttää uskottavalta erikseen.

Tämä on palvelinpuolen osoitusta ja käytäntöä, ei puhelimen virhekäyttäytymistä, eikä mikään asiakasasetus erota kahta identtistä sisäistä osoitetta. Varanto jakoi saman arvon kahdesti ja käytännön asentaja hyväksyi sen. Lue tulos palvelimen puolelta ennen kuin syytät asiakasta.

Muuta varantoa tai samanaikaisuusmallia, älä avaimen uusinnan ajastinta

swanctl-määrityksessä ainutlaatuisuus on nimenomainen käytäntö yhteydellä: unique = replace poistaa vanhemman yhteyden, kun uusi muodostetaan, ja unique = keep hylkää tulokkaan. Molemmat arvot vaikuttavat yhteyttä muodostettaessa, eivät sen sisäisiin lapsi-SA:ihin.

connections {
  ios-alwayson {
    unique = replace
  }
}

Kumpikaan arvo ei ole neutraali liitäntäkohtaiselle asiakkaalle. keep palauttaa siistin tilanäkymän hylkäämällä toisen tunnelin ja rikkoo hallinnoidun mallin, kun taas replace repii vanhemman tunnelin alas ja on sama kompromissi toiseen suuntaan. Jos molempia tunneleita todella tarvitaan, varannon taustajärjestelmän on myönnettävä erilliset vuokraukset yhdelle identiteetille, ja sen vuokrausavaimen on erotettava pyynnöt. Staattinen identiteetti-osoite-taulu palauttaa mielellään saman osoitteen kahdesti ja toisintaa alkuperäisen ongelman suuremmalla määrityksellä. Tarkista, miten taustajärjestelmä avaimistaa vuokraukset, ennen kuin lisäät toisen staattisen kuvauksen.

Testaa siirtymiä, jotka todella otat käyttöön

Kävele pois Wi-Fi-kantaman ulkopuolelle aktiivisen istunnon kanssa, kävele sitten takaisin ja tarkista, että vastaukset saapuvat molempiin suuntiin. Tee se kahdesti, sillä toinen siirtymä on paikka, jossa vanhentunut käytäntö yleensä näkyy. Testaa palvelulla, joka vastaa avaamallasi yhteydellä, ja toista poistuminen, kun tunneli kuljettaa liikennettä sen sijaan että seisoisi jouten. Puhelin, joka pystyy lähettämään mutta ei vastaanottamaan, näyttää terveeltä kättelylokissa ja rikkinäiseltä selaimessa.

Yhdeksi riviksi kutistettu tilanäkymä ei ole todiste toimivasta mallista, vain todiste siitä, että yksi tunneli on poissa. Molempien suuntien on toimittava ennen kuin siirtymä menee läpi. Kirjoita muistiin, mitä havaitsit, yhdessä päällekkäisyystarkistuksen kahden tulosteen kanssa, jotta seuraava insinööri voi verrata sen sijaan että toistaisi kävelyn.