L2TP, GRE ali IPsec: katera plast naj nosi sejo?

Dve vprašanji se zapleteta vsakič, ko se L2TP, GRE in IPsec znajdejo v isti načrtovalni beležki: katero sejo nosim in katera plast jo ščiti? Če je prvo napačno, vse spodaj ostane notranje dosledno, a rešuje napačen problem — usmerjeni prekrivni sloj, zgrajen tam, kjer so se morali uporabniki prijaviti, ali koncentrator prijave, ki stoji namesto prehoda med lokacijama. Delovni list spodaj vsili to razlikovanje, preden se kdo prijavi v napravo. Izpolnite ga po vrsti in vsaka vrstica postane nekaj, kar lahko preizkusite sami.

Začnite s sejo, ne s seznamom protokolov

Oddaljeni uporabnik s sejo PPP in usmerjeni prekrivni sloj med dvema prehodoma sta različna omrežna razmerja, tudi ko sta oba na koncu zavita v IPsec. Prvi zaključi povezavo za vsakega uporabnika in potrebuje dodeljevanje naslovov, preverjanje identitete osebe ali naprave in pravilnik, ki navaja, do katerih notranjih omrežij lahko ta uporabnik dostopa. Drugi posreduje pakete med lokacijami, v katere se nihče ne prijavlja.

Napišite en stavek, ki poimenuje, katero od dveh gradite, nato ga preberite, kot da ste oseba, ki ga mora upravljati. Če stavek potrebuje besedo »in«, gradite oba, delovni list pa potrebuje dva stolpca namesto enega kompromisnega stolpca, ki vsakemu služi na pol. Če poimenuje uporabnika, a ne nabora naslovov, ali predpono, a ne pravilnika posredovanja, je stavek še vedno nepopoln. Besedilo zveni birokratsko, a to je najcenejše mesto, da ujamete načrt, ki bi se sicer razkril šele s prijavo pri podpori.

Vsaki plasti dajte natanko eno nalogo

L2TPv2 nosi seje PPP med svojima dvema končnima točkama. PPP vodi pogajanja o povezavi in, ko so dogovorjena, preverjanje uporabnika; L2TP ne doda nobene kriptografije, zato goli L2TP demon ne izvaja nobenega dela varnostnega razmerja IPsec in sodi le v povezavo, ki ji že zaupate.

GRE je ovijanje med dvema naslovoma. Nosi pakete omrežne plasti čez logični prekrivni sloj in sam po sebi ne ponuja ne zaupnosti ne overjene identitete partnerja. To ni napaka: glava je bila zasnovana preprosto, da ostane poceni za obdelavo v strojni opremi za posredovanje. Posledica je, da GRE odgovarja le na vprašanje, kako premakniti ta paket med dvema naslovoma, in na nič drugega, to pa je natanko vprašanje, ki bi se ga morali vprašati.

Ostane IPsec kot plast, ki izbira promet, overja partnerje in šifrira tisto, kar mu je bilo naročeno ščititi. Kateri promet ščiti, je odločitev konfiguracije, ki se mora ujemati z ovijanjem, ki ga končne točke dejansko ustvarjajo, ker se pravilnik, napisan za zunanji naslov GRE, obnaša drugače kot tisti, napisan za notranje predpone. Specifikacija GRE ohranja tovor, glavo GRE in zunanji protokol dostave vidno ločene, vaš pravilnik pa potrebuje enako ločevanje.

Napišite pot paketa pred konfiguracijo

Vzemite en paket in naštejte vsako glavo, ki se doda, v vrstnem redu dodajanja, in poimenujte napravo, ki jo doda. Za uporabnika, ki se prijavlja, je to običajno PPP znotraj L2TP znotraj IPsec; za prekrivni sloj lokacije je to notranji paket IP znotraj GRE znotraj IPsec. Če dve napravi dodata isto glavo, imate zanko ali podvojen tunel in nobeno urejanje pravilnika tega ne bo popravilo.

Isti seznam določi MTU, ker je uporabna notranja velikost izmerjeni MTU poti minus pravkar naštete glave in nič drugega. Ne kopirajte številke iz forumske objave: seštejte stroške zunanjih IP, UDP in ESP, nato GRE ali L2TP, nato PPP, kjer velja, in odštejte od MTU poti, ki ste ga dejansko izmerili. Simptomi, ki se pojavijo le pri velikih prenosih, ali seje, ki se vzpostavijo in nato umrejo ob prvem velikem odgovoru, običajno vodijo nazaj k temu, da je bilo to seštevanje opravljeno po občutku.

Vsako plast preverite posebej, od zunaj navznoter

Zaženite preverjanja po vrsti in ustavite pri prvem, ki ne uspe. Vsaka vrstica odgovarja na drugo vprašanje, zato napaka kaže na en stolpec delovnega lista, namesto da bi vam povedala, da je tunel pokvarjen.

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?

Na škatli Cisco je ustreznik odvisen od vloge, natančna sintaksa pa od platforme in izdaje: show crypto session za partnerje IPsec, števci vmesnika za vmesnik GRE ali tunela in preverjanje VPDN ali PPP za vlogo prijave. Nabor ukazov, ki zaključi PPP, ne dokazuje ničesar o podpori GRE, delujoč vmesnik GRE pa ne dokazuje ničesar o storitvi PPP, zato preverite vlogo, ki ste jo dejansko konfigurirali, in ne tiste z diagrama.

Zapišite vsak izhod ob vrstico delovnega lista, ki ji pripada. Zapiski, narejeni med aktivno napako, so vredni več kot topologija, pozneje prerisana po spominu.

Uredite vrstni red razdora in nato znova preverite

Razdor poteka v obratnem vrstnem redu z razlogom: vzemite zaščiteni promet iz pravilnika IPsec, preden odstranite ovijanje, za katero je bil napisan, sicer pravilnik še naprej kaže na vmesnik, ki ne obstaja več, in naslednje nalaganje konfiguracije spodleti nekje, kar je videti nepovezano. Na Linuxu to pomeni brisanje vnosov stanja in pravilnika pred vmesnikom tunela; na usmerjevalniku odstranitev kriptografske karte ali vnosa profila pred tunelom.

Po ponovni gradnji ponovite štiri opazovanja sprejema eno za drugim: zunanja dosegljivost, vzpostavljena povezava IPsec, vzpostavljena seja PPP tam, kjer jo načrt vključuje, in notranje posredovanje na pravi ciljni naslov. Ena zelena lučka ni dokaz za ostale tri, in prav ta vrzel je napaka, ki v proizvodnji preživi najdlje — tunel, ki je pokonci, šifriran in ne posreduje ničesar, ker notranja pot ni bila nikoli dodana.

Izpisan delovni list hranite ob konfiguraciji naprave. Vsak stolpec, ki ga ne morete izpolniti, je plast brez dodeljene naloge, plast brez naloge pa je običajno plast, ki je v skladu ne bi smelo biti.