IKEv2 pret L2TP/IPsec: kuru profilu izmanto jūsu serveris?
Viena etiķete slēpj divas kaudzes, trīs veidu noslēpumu un citādu uzvedību, kad mainās adrese. Izšķetiniet slāņus, pirms salīdzināt izvēlnes.
Abi nosaukumi stāv blakus tajā pašā nolaižamajā izvēlnē, kas aicina izvēlēties starp vienlīdzīgiem. Tie nav vienlīdzīgi. L2TP ir tunelēšanas protokols bez savas konfidencialitātes, un L2TP/IPsec pakalpojuma aizsardzība nāk no to aptverošā IPsec slāņa. IKEv2 tieši vienojas par IPsec asociāciju, un tam nav soļa “tunelis tunelī”. Zināšana, kuru kaudzi piedāvā jūsu serveris, nosaka profilu, uzvednes un to, kas notiek, kad klēpjdators maina tīklu.
Divas kaudzes, viena etiķete klientā
L2TP pārvadā punkta-punkta sesiju pār UDP uz portu 1701 un atstāj šifrēšanu tam, kas to ietver. Savienojiet to ar IPsec, un jūs iegūstat divus slāņus: ceļu aizsargājošu IPsec asociāciju un tajā iekšā L2TP sesiju, kas pārvadā lietotāja saites slāņa kadrus un PPP autentifikāciju.
IKEv2 izveido vadības asociāciju un pēc tam vienu vai vairākas pakārtotas asociācijas, kas aizsargā datplūsmu, viss vienā apmaiņu saimē uz UDP 500 un 4500. Nav iekšēja tunelēšanas protokola un nav PPP pārrunu.
Piekļuves dati: trīs noslēpumi trīs slāņos
Šeit pazūd lielākā daļa atbalsta laika. L2TP/IPsec profils var pieprasīt iepriekš kopīgu atslēgu IPsec slānim un lietotājvārdu ar paroli iekšējai PPP sesijai, un abus pārbauda dažādas komponentes. Kopīgā atslēga pieder vārtejai kopumā, tāpēc tā nevienu neidentificē; tā tikai pierāda, ka pretējā puse zina noslēpumu.
IKEv2 parasti izmanto sertifikātus vai EAP ar lietotājvārdu un paroli, un tas var izmantot arī iepriekš kopīgu atslēgu. Šīs iespējas nav savstarpēji aizvietojamas ar L2TP pāri. Paroles atiestatīšana, kas salabo noraidītu EAP pieteikšanos, neko nedara novecojušam klienta sertifikātam, un, lai cik reižu jūs no jauna ievadītu konta paroli, nepareizu vārtejas atslēgu ar to neapmierināsiet. Kad parādās uzvedne, kuru negaidījāt, pirms minēšanas pajautājiet operatoram, kuram slānim tā pieder.
| Question | L2TP/IPsec | IKEv2 |
|---|---|---|
| What encrypts the traffic | A wrapping IPsec association | The child association |
| Ports you must permit | UDP 500/4500 and UDP 1701 inside | UDP 500 and 4500 |
| Typical secrets | Gateway PSK plus PPP credentials | Certificate, EAP, or PSK |
| Address change | Tunnel breaks, reconnect needed | Can migrate with MOBIKE |
Ko MOBIKE maina un ko ne
IKEv2 var pārvietot asociāciju uz jaunu adresi, kad abi gali atbalsta MOBIKE, kas aptver gadījumu, kad klēpjdators pamet wifi un pāriet uz tālruņa piekļuves punktu, nesabojājot drošības asociāciju.
Tas šīs pārvietošanas laikā neuztur dzīvu katru lietotni. Transporta plūsma joprojām maina adresi, pie vecās piesaistītie ligzdas joprojām lūzt, un politika, kas datplūsmu piesprauž pie saskarnes, to joprojām var nomest. Pārbaudiet pāreju, ko patiešām veicat, vai tā būtu tīkla pamešana, pamošanās no miega vai atgriešanās pēc ilgas dīkstāves, un vērojiet lietotni, nevis etiķeti Savienots.
Bojājumu formas, kas tās atšķir
L2TP/IPsec profils, kas sasniedz vārteju un pēc tam apstājas, parasti neizdodas vienā no divām uzvednēm: kopīgajā atslēgā vai PPP piekļuves datos. Nepareiza atslēga klienta žurnālā parasti neparāda neko noderīgu, savukārt nepareiza parole rada skaidru autentifikācijas noraidījumu, un šī atšķirība pasaka, kur meklēt.
IKEv2 profils neizdodas agrāk un skaļāk, ja identitāte vai sertifikāts ir nepareizi, jo vadības asociācija nekad nebeidzas. Ja asociācija beidzas un datplūsma joprojām neiet, problēma ir pārcēlusies uz pakārtoto asociāciju, datplūsmas selektoriem vai maršrutu, un nekādas piekļuves datu izmaiņas nepalīdzēs.
Kur katrs vēl iederas
L2TP/IPsec saglabājas, jo tas ir gandrīz katrā klientā un neprasa papildu programmatūru, kas ir svarīgi ārējam darbuzņēmējam ierīcē, kuru jūs nepārvaldāt. Cena ir papildu slānis, kopīgā noslēpuma modelis un atkārtota savienošana pēc katras adreses maiņas.
IKEv2 labāk piemērots pārvaldītām ierīcēm: identitāte ar sertifikātu, tīrāka mobilitāte un viena asociāciju saime, par ko domāt. Tas arī neizdodas stingrāk, ja klients ir vecs, tāpēc pirms projektēšanas ap to pārbaudiet platformas atbalstīto autentifikācijas metodi.
Saņemtā profila pārbaude
Vispirms apstipriniet režīmu servera pusē, pēc tam izvēlieties tam atbilstošo klienta profilu. Pārbaudiet ar precīzu šim profilam izsniegto resursdatora nosaukumu un piekļuves datiem, un pārbaudiet privāto resursu, nevis publisku vietni.
Ja tas savienojas un nekas neielādējas, tunelis strādā, bet maršruts, DNS vai datplūsmas selektors nestrādā. Protokola maiņa šajā punktā diagnostiku restartē, nevis virza uz priekšu.