L2TP, GRE või IPsec: milline kiht peaks seansi kandma?

Iga kord, kui L2TP, GRE ja IPsec satuvad samasse projekteerimismärkmesse, põimuvad kaks küsimust: millist seanssi ma kannan ja milline kiht seda kaitseb? Kui esimene on vale, jääb kõik allpool sisemiselt järjekindlaks, lahendades samal ajal vale probleemi — marsruuditud overlay ehitatakse sinna, kus kasutajad pidid sisse valima, või sissevalimiskontsentraator asendab saidi-saidi lüüsi. Alljärgnev tööleht sunnib selle vahetegemise tegema enne, kui keegi seadmesse sisse logib. Täida see järjekorras ja igast reast saab midagi, mida saab eraldi testida.

Alusta seansist, mitte protokollide loendist

Kaugkasutaja, kellel on PPP-seanss, ja kahe lüüsi vaheline marsruuditud overlay on erinevad võrgusuhted, isegi kui mõlemad lõpuks IPsec-i sisse mähitakse. Esimene lõpetab ühe kasutaja lingi ja vajab aadresside määramist, inimese või seadme autentimist ning poliitikat, mis nimetab, millistele sisemistele võrkudele see kasutaja pääseb. Teine edastab pakette saitide vahel, kuhu keegi sisse ei vali.

Kirjuta üks lause, mis nimetab, kumba kahest sa ehitad, ja loe see siis tagasi nii, nagu oleksid sina see inimene, kes peab seda käitama. Kui lause vajab sõna «ja», ehitad sa mõlemat ning tööleht vajab kahte veergu, mitte üht kompromissveergu, mis teenindab poolikult mõlemat. Kui see nimetab kasutajat, aga mitte aadressibasseini, või prefiksit, aga mitte edastuspoliitikat, on lause ikka veel puudulik. Sõnastus kõlab bürokraatlikult, kuid see on odavaim koht, et tabada projekti, mille avastaks muidu tugiteenuse pilet.

Anna igale kihile täpselt üks ülesanne

L2TPv2 kannab PPP-seansse oma kahe otspunkti vahel. PPP juhib lingi läbirääkimist ja, kui see toimub, kasutaja autentimist; L2TP ei lisa mingit krüptograafiat, seega paljas L2TP-deemon ei rakenda ühtki osa IPsec-i turvasuhtest ja kuulub ainult lingi sisse, mida sa juba usaldad.

GRE on kapseldus kahe aadressi vahel. See kannab võrgukihi pakette läbi loogilise overlay ja ei paku iseenesest ei konfidentsiaalsust ega autenditud partneri identiteeti. See pole viga: päis projekteeriti lihtsaks, et selle töötlemine jääks edastusriistvaras odavaks. Tagajärg on, et GRE vastab küsimusele «kuidas ma selle paki kahe aadressi vahel liigutan» ja mitte millelegi muule, ning täpselt see ongi küsimus, mida peaksid sellelt küsima.

Nii jääb IPsec kihiks, mis valib liikluse, autendib partnerid ja krüpteerib selle, mida tal kästi kaitsta. See, millist liiklust ta kaitseb, on konfiguratsiooniotsus, mis peab vastama kapseldusele, mille otspunktid tegelikult genereerivad, sest GRE välimise aadressi jaoks kirjutatud poliitika käitub teisiti kui sisemiste prefiksite jaoks kirjutatud. GRE spetsifikatsioon hoiab kasuliku koormuse, GRE-päise ja välimise edastusprotokolli nähtavalt eraldi ning sinu poliitika vajab sama eraldust.

Kirjuta paki teekond enne konfiguratsiooni

Võta üks pakk ja loetle iga lisatav päis lisamise järjekorras, nimetades seadme, mis selle lisab. Sissevalimiskasutaja puhul on see tavaliselt PPP L2TP sees, mis omakorda IPsec-i sees; saidi overlay puhul on see sisemine IP-pakk GRE sees, mis omakorda IPsec-i sees. Kui kaks seadet lisavad sama päise, on sul silmus või dubleeritud tunnel, ja ükski poliitika muutmine ei paranda seda.

Sama loend lahendab ka MTU, sest kasutatav sisemine suurus on mõõdetud tee-MTU miinus päised, mille sa just loetlesid, ja mitte midagi muud. Ära kopeeri numbrit foorumipostitusest: liida välimised IP, UDP ja ESP kulud, siis GRE või L2TP, siis PPP, kus see kehtib, ja lahuta teest, mille sa tegelikult mõõtsid. Sümptomid, mis ilmnevad ainult suurte ülekannete puhul, või seansid, mis luuakse ja surevad esimese suure vastuse peale, viivad tavaliselt tagasi selle liitmise juurde, mis tehti oletuste põhjal.

Kontrolli iga kihti eraldi, väljastpoolt sissepoole

Jooksuta kontrolle järjekorras ja peatu esimese juures, mis ebaõnnestub. Iga rida vastab erinevale küsimusele, nii et tõrge osutab töölehe ühele veerule, selle asemel et öelda, et tunnel on katki.

ip xfrm state                  # is the IPsec SA up?
ip -s link show gre1           # does the overlay interface carry packets?
ip route get 10.20.0.5         # does the inner prefix route where you think?
ss -lun | grep -E "1701|4500"  # are the L2TP and NAT-T listeners bound?

Cisco seadmes sõltub vaste rollist ja täpne süntaks platvormist ning versioonist: show crypto session IPsec-partnerite jaoks, liidese loendurid GRE või tunneliliidese jaoks ning VPDN või PPP kontroll sissevalimisrolli jaoks. Käsustik, mis lõpetab PPP, ei tõesta midagi GRE toe kohta, ja töötav GRE-liides ei tõesta midagi PPP-teenuse kohta, seega kontrolli rolli, mille sa tegelikult konfigureerisid, mitte seda, mis on diagrammil.

Kirjuta iga väljund selle töölehe rea kõrvale, kuhu see kuulub. Rikke ajal tehtud märkmed on väärt rohkem kui topoloogia, mis hiljem mälu järgi uuesti joonistatakse.

Järjesta demonteerimine ja kontrolli seejärel uuesti

Demonteerimine käib vastupidises järjekorras põhjusega: eemalda kaitstud liiklus IPsec-poliitikast enne, kui eemaldad kapselduse, mille jaoks see kirjutati, muidu osutab poliitika liidesele, mida enam ei ole, ja järgmine konfiguratsiooni laadimine ebaõnnestub kusagil, mis tundub seosetu. Linuxis tähendab see oleku- ja poliitikakirjete kustutamist enne tunneliliidest; ruuteril crypto map'i või profiilikande eemaldamist enne tunnelit.

Pärast ülesehitamist korda nelja vastuvõtuvaatlust ükshaaval: välimine kättesaadavus, loodud IPsec-assotsiatsioon, loodud PPP-seanss, kui projekt selle sisaldab, ja sisemine edastus päris sihtaadressile. Üks roheline tuli ei ole tõendiks ülejäänud kolme kohta ja just see lünk on rike, mis tootmises kõige kauem püsib — tunnel, mis on üleval, krüpteeritud ja ei edasta midagi, sest sisemist marsruuti ei lisatud kunagi.

Hoia täidetud töölehte seadme konfiguratsiooni kõrval. Iga veerg, mida sa ei suuda täita, on kiht, millel pole määratud ülesannet, ja kiht, millel pole määratud ülesannet, ei peaks tavaliselt virnas olema.