Miért nem elég a PPP CHAP önmagában egy MPPE-követelményhez

A titkosítást megkövetelő PPTP-profil általában ugyanazon a ponton hasal el: a PPP olyan hitelesítési cserében állapodik meg, amely soha nem állítja elő az MPPE-hez szükséges kulcsanyagot. Az alagút félig életveszélyesnek tűnik, a jelszót elfogadják, és a kapcsolat megszakad, mielőtt bármilyen forgalom átkelne rajta. A CHAP legördülő menühöz nyúlni, amíg valami csatlakozik, elrejti az igazi hibát, az pedig szerződés a hitelesítési mód és a védelmi szabályzat között. Az alábbi ellenőrzések úgy vannak sorrendezve, hogy mindegyik olcsóbb okot zárjon ki a következőnél.

Két tárgyalás fut egyetlen PPTP-kapcsolaton belül

A PPTP normál PPP-munkamenetet szállít egy GRE-alagúton belül, és a kettő külön tárgyal. A külső réteg dönti el, hogyan csomagolódnak a csomagok és melyik vezérlőcsatorna létezik; a belső PPP-munkamenet dönti el, ki a partner és milyen védelem ül rajta. A jelszókérés tehát csak a belső rétegről bizonyít valamit, a befejezett külső kézfogás pedig egyikről sem bizonyít semmit. A profilok itt azért hasalnak el, mert az emberek az alagutat hibakeresik, miközben a nézeteltérés a PPP-n belül ül.

A sima CHAP az RFC 1994 kihívás-válasz cseréje, amely közös titokra és semmi másra épül. Az MS-CHAPv2 más üzenetekkel és más kimenettel rendelkező másik csere, amelyet az RFC 2759 szabványosít. A két név közös szava az egyetlen, amit a vezetéken közösen birtokolnak. Egyik név sem mondja meg, mit állít elő a csere, és éppen ez az egyetlen fontos rész.

Ezért a csupán CHAP-nak nevezett beállítás kétértelmű egy régi profilban. Amikor a kiszolgáló MS-CHAPv2-t akar, az ügyfél pedig sima CHAP-ot kínál, a kapcsolatvezérlés még befejeződhet, és a jelszó még elfogadható. A hiba később érkezik, amikor a kiszolgáló védelmi kulcsokat próbál levezetni egy olyan cseréből, amely semmit nem állított elő.

Párosítsa a megkövetelt módot azokhoz a kulcsokhoz, amelyeket elő tud állítani

Az MPPE-kulcsok nem a PPP általános tulajdonságai. A Microsoft CHAP család esetében a levezetést az RFC 3079 határozza meg, és bemenetként az MS-CHAP-csere kimenetét veszi, nem közös titkot. Az EAP-módok más úton jutnak ugyanoda, a hitelesítési kiszolgáló pedig MS-MPPE-Recv-Key és MS-MPPE-Send-Key attribútumként adja vissza a kulcsokat. A sima CHAP egyik úton sem jelenik meg, és ez az egész oka annak, hogy az eltérés létezik.

Az a konfiguráció, amely MPPE-t követel meg, miközben minden kulcsot adni képes módot elutasít, belsőleg ellentmondásos. A pppd ezt az ellentmondást a kapcsolat elutasításával oldja fel, nem kulcsok kitalálásával, így a látható eredmény egy munkamenet, amely hitelesít, majd a hálózati fázisban megszűnik. Az ügyfél újrapróbálkozása nem változtat ezen, amíg a kiszolgáló elutasítja az egyetlen módokat, amelyek bármit levezetnek.

A ebből következő szabály rövid: ha a profil MPPE-t követel meg, a módnak MS-CHAP-változatnak vagy olyan EAP-módnak kell lennie, amelynek kulcsait a kiszolgáló visszaadja. Csak az MS-CHAPv2 elutasítása ezt nem kényszeríti ki, mert az MS-CHAPv1 is levezet kulcsokat, és elérhető marad, hacsak külön nem utasítják el; mindkettő elutasítása sima CHAP-ot és PAP-ot hagy, amelyek semmit nem vezetnek le, és teljesíthetetlenné teszik a követelményt. Nevezze meg kifejezetten az elfogadott módot ahelyett, hogy a nem kedvelteket sorolná fel. A titkosítási követelmény elengedése azért, hogy egy ügyfél csatlakozzon, visszalépés, nem javítás.

Olvassa el a kiszolgáló beállításait, mielőtt szerkesztene egy ügyfelet

Ezek az eltérések többsége a kiszolgálón két fájlban látható, és elolvasásuk kevesebbe kerül, mint egy ügyfél újjáépítése. Egy Linux PPTP-végponton a vonatkozó beállítások abban a pppd-beállításfájlban élnek, amelyet a pptpd továbbít. A kiszolgálón futtassa, ne egy ügyfél állapotképernyőjéről. Kezdje azokkal a sorokkal, amelyek védelmi módot követelnek meg, utasítanak el vagy neveznek meg:

sudo grep -nE 'require-|refuse-|mppe|mschap' /etc/ppp/options.pptpd

A kimenetet szerződésként olvassa, ne kapcsolók listájaként. Azt a sort, amely MPPE-t követel meg, miközben az MS-CHAP mindkét változatát elutasítja, egyetlen ügyfél sem tudja teljesíteni, és az MS-CHAP-módra vonatkozó hiányzó követelmény nyitva hagyja az ajtót a kulcsot nem adó cserék előtt. Ezután ellenőrizze, ki hitelesíthet egyáltalán, amiről a titkok fájlja dönt:

sudo sed -n '1,20p' /etc/ppp/chap-secrets
sudo pppd --version

Három értéket írjon fel, mielőtt bármit megváltoztat: a külső protokollt, a kiszolgáló által megkövetelt hitelesítési módot, és azt, hogy a védelem kötelező-e vagy választható. Ez a három határoz meg minden későbbi döntést, és ezeket egy ügyfélpárbeszédből kitalálni az az út, amelyen egy profil félig konfiguráltan végzi. Tartsa nyitva a fájlt munka közben, mert a következő szakasznak ugyanerre a három értékre van szüksége.

Helyezze el a hibát a PPP-fázis szerint

A PPP fázisokban jelenti a hibákat, és a fázis megmondja, melyik szerződéses kikötés tört meg. Az a kapcsolat, amely soha nem hagyja el a kapcsolatvezérlést, csomagolási vagy tárgyalási problémával küzd, míg amelyik hitelesít, majd meghal, általában szabályzat- vagy kulcsproblémával. Az a kapcsolat, amely fennmarad és semmit nem szállít, továbblépett az útválasztásra, ami más vizsgálat.

A napló megtartja a fázissorokat, és azok hasznosabbak, mint egy magasabb hibakeresési szint. Kérje le a PPP-folyamatokat és a védelmi üzeneteket, majd a hitelesítés eredményét olvassa el minden más előtt. Az utolsó sorok általában megnevezik az elutasító kikötést:

sudo journalctl -b --no-pager | grep -iE 'pppd|pptpd|mppe|chap' | tail -40

Ebben a kimenetben először a hitelesítés eredményét keresse, majd azt a panaszt, hogy a védelmet megkövetelték, de nem tárgyalták meg. A második üzenet a fenti ellentmondás aláírása, és semmilyen mennyiségű újrapróbálkozás nem törli, amíg a kiszolgáló elutasítja az egyetlen kulcsot előállítani képes módot. Két csapdát érdemes megnevezni: a hibakeresési szint emelése a fázissorok olvasása nélkül zajt termel, a kihívásanyag vagy a jelszavak rögzítése pedig konfigurációs feladatot hitelesítőadat-szivárgássá változtat. Jegyezze fel azt a fázist, mielőtt bármely beállítást megváltoztat.

Tervezze meg a kilépést, mielőtt a régi végpontot kikapcsolják

Az MPPE történelmi kapcsolatvédelmi mechanizmus, és jelenléte nem teszi a PPTP-t ésszerű választássá egy új telepítéshez. A Microsoft jelenlegi útmutatása már ellenzi a PPTP-t és az előre megosztott kulcsú L2TP/IPsec-et az új távoli hozzáférési telepítéseknél. Egy régi végpont életben tartása egy meglévő szolgáltatásról szóló döntés, nem sablon a következőhöz.

Amikor a végpontnak maradnia kell, írja le a szerződést: külső protokoll, megkövetelt hitelesítési mód, kötelező védelem és az az ügyfélverzió, amely erről tárgyal. Amikor mehet, válassza ki a csere átjáróazonosságát, ügyfél-hitelesítését és azt, hogy hol élnek majd a hitelesítő adatok, mielőtt hozzányúlna a régi profilhoz. Ezután tervezze meg az útvonalakat, a DNS-t és azokat az erőforrásokat, amelyekhez minden felhasználó jogosult. A szándékolt ügyfelet a tulajdonos követelményeihez mérje, ne egy működő kapcsolathoz.

A szándékos elutasításnak elutasításnak kell maradnia, mert a védelem nélküli módra való visszaesés egy teszt átengedéséért szabályzati hibát tesz ki a veszélynek. A kész állapot egy támogatott, dokumentált szerződés, nem a legkisebb változás, amely egy régi kapcsolatot sikeressé tesz. Hagyja a régi profilt a helyén, használatlanul és dokumentáltan, amíg a csere át nem megy ugyanazokon az ellenőrzéseken.