Az iOS elutasította a strongSwan alagutat: hasonlítsa össze az IKE javaslatokat

A tanúsítványban és a címben semmi nem magyarázza meg, miért bukik el idén az az iPhone, amely tavaly csatlakozott a strongSwanhoz. A címnek, az előre megosztott kulcsnak és az ügyfél identitásának nem kellett megváltoznia. Ami elmozdult, az a transzformációk listája, amelyekről a telefon beépített ügyfele hajlandó tárgyalni, és amint ez a lista többé nem fedi a kiszolgálóét, a csere véget ér, mielőtt bárki identitását megvizsgálnák.

A naplósor, amely dönt

Növelje a kapcsolat naplózását, és keresse meg a két bejegyzést, amelyek eldöntik az eredményt: mit ajánlott a telefon, és mit választott a kiszolgáló. Ha a napló kiválasztott javaslat nélkül ér véget, és azt jelenti, hogy semmi nem egyezett, a hitelesítésre sor sem került. Új tanúsítvány és új jelszó ezen a ponton semmit nem változtat, mert mindkettőt egy későbbi szakaszban használják fel. Egyik sem befolyásolhat olyan eredményt, amely már az identitás vizsgálata előtt eldőlt.

A két hibaformát különítse el, mielőtt bármit szerkesztene. Semmilyen transzformáció-módosítás nem menti meg az elutasított hitelesítő adatokat, és semmilyen hitelesítőadat-javítás nem menti meg az elutasított transzformációt. Az a naplóbejegyzés, amely megnevezi a kiválasztott javaslatot, megmondja, melyikben van. Bejegyzés nélkül csak találgat.

A kiválasztott sor a javaslatot a transzformációkészlete alapján nevezi meg, nem barátságos címke szerint. Hasonlítsa össze a sorban a titkosítási, integritási és csoportmezőket a telefon által küldött listával, mert egyetlen mező eltérése is elég a vereséghez.

Mi változott a telefonon

Az iOS egyik kiadása lefaragta azokat az algoritmusokat, amelyeket az ügyfele hajlandó használni. A gyenge integritású hash-ek, a kis Diffie-Hellman csoportok és az örökölt beállításokat elsőként felsoroló javaslatok megszűntek elfogadhatónak lenni.

A hosszabb listák itt nem biztonságosabbak. A választás a telefon által elfogadott halmazt és annak saját preferenciasorrendjét követi, ezért egy széles katalógust hirdető kiszolgáló is elbukhat a tárgyaláson, ha nem a modern tételek lesznek a kiválasztottak. Inkább rövid listát válasszon, amelynek élén a modern tételek állnak. Az örökölt beállításokkal kezdődő hosszú lista éppen azt a hibát hívja meg, amelyet el akar kerülni. Az elfogadott halmaz külső korlát, amely minden ügyfélfrissítéssel elmozdul, ezért a tegnap működő konfiguráció a tegnapról szóló bizonyíték.

Egy pár, amely még tárgyal

A jelenlegi telefonokhoz egyetlen modern kombináció elég. Egy tárgyaló pár így néz ki:

ike=aes256-sha2_256-modp2048
esp=aes256-sha2_256

Az ike sor hordozza a titkosítást, az integritást és a Diffie-Hellman csoportot, amelyeket a kulcscsere alatt használnak. Az esp sor csak az adatcsatornát fedi le, mert a csoport már eldőlt, mielőtt érvénybe lépne. Töltse újra a kapcsolatot, vagy indítsa újra a daemont, majd csatlakoztassa újra a telefont. Csak akkor tartsa meg ezt a csoportértéket, ha minden kiszolgált ügyfél még elfogadja, és ne szélesítse a javaslatot mindenki számára csak azért, mert egyetlen régi partnernek többre van szüksége.

Három hely a javításra, egy rendszerint zárva

• Egy modern javaslat minden partnernek. Helyes, ha minden ügyfél jelenlegi telefon és asztali gép. Törli a régi transzformációkat ahelyett, hogy körülöttük tárgyalna.
• Második kapcsolatdefiníció az Apple ügyfeleknek. Életben tart egy örökölt partnert, miközben a telefonnak elfogadható javaslatot ad. Egy további kapcsolatblokkba kerül, és láthatóvá teszi a kivételt.
• Az ügyfél lecserélése. Ritkán áll nyitva: amikor kezelőrendszer vagy alkalmazás szállítja a profilt, nincs szerkeszthető javaslatszerkesztő, a beépített ügyfél pedig nem tesz közzé ilyet.

A második lehetőséget válassza, ha az ellenőrzésén kívül eső eszköz nem frissíthető. Az elsőt válassza, ha nyugdíjazhatja az örökölt partnert, és inkább egyetlen házirendet visz.

Akárhogy is, a választás látszik a konfigurációban, és éppen ez a lényeg. A csendes visszaesés, amely régi transzformációig tárgyal le, rosszabb egy kifejezett blokknál, mert semmilyen felülvizsgálat nem hozza felszínre.

Bizonyítsa, aztán jegyezze fel

Csatlakozzon újra, és ellenőrizzen három külön tényt a kiszolgálón: kiválasztottak egy javaslatot, a kapcsolat létrejöttként látszik, és az ügyfél címet kapott. A távoli cím nélküli létrejött kézfogás a címkészletre vagy a forgalomválasztókra utal, és külön változtatásba tartozik. A kettő együtt kezelése egy megoldott tárgyalást megoldatlannak láttat.

Jegyezze fel az elfogadott transzformációkészletet, hogy mikor változtatta meg, és melyik ügyfélbuildet ellenőrizte. A következő frissítés ismét elmozdíthatja a követelményt, és a működött értékek az elsők, amelyeket az újjak mellé szeretne.