L2TP, GRE ili IPsec: koji sloj treba nositi sesiju?

Dva se pitanja zapetljaju kad god L2TP, GRE i IPsec dođu u istu projektnu bilješku: koju sesiju nosim i koji je sloj štiti? Ako prvo bude pogrešno, sve nizvodno ostaje interno dosljedno dok se rješava pogrešan problem — usmjereni overlay gradi se tamo gdje su se korisnici trebali uvezivati, ili koncentrator za uvezivanje stoji umjesto mrežnog prolaza između lokacija. Radni list u nastavku nameće tu razliku prije nego se bilo tko prijavi na uređaj. Ispunite ga redom i svaki redak postaje nešto što možete zasebno isprobati.

Krenite od sesije, a ne od popisa protokola

Udaljeni korisnik s PPP sesijom i usmjereni overlay između dvaju mrežnih prolaza različiti su mrežni odnosi, čak i kad oboje na kraju bude umotano u IPsec. Prvi završava vezu po korisniku i traži dodjelu adresa, autentifikaciju osobe ili uređaja te pravilo koje imenuje koje unutarnje mreže taj korisnik smije dosegnuti. Drugi prosljeđuje pakete između lokacija u koje se nitko ne uvezuje.

Napišite jednu rečenicu koja imenuje što od to dvoje gradite, pa je pročitajte kao da ste osoba koja to mora voditi. Ako rečenici treba riječ „i“, gradite oboje, a radni list treba dva stupca umjesto jednog kompromisnog koji svakome služi napola. Ako imenuje korisnika ali nema skupa adresa, ili prefiks ali nema pravila prosljeđivanja, rečenica je još nepotpuna. Formulacija zvuči birokratski, ali to je najjeftinije mjesto za uhvatiti nacrt koji bi inače otkrio zahtjev prema podršci.

Dodijelite svakom sloju točno jedan zadatak

L2TPv2 nosi PPP sesije između svojih dvaju krajnjih točaka. PPP vodi pregovaranje veze i, kad se ono pregovara, autentifikaciju korisnika; L2TP ne dodaje nikakvu kriptografiju, pa goli L2TP daemon ne implementira nijedan dio IPsec sigurnosnog odnosa i pripada samo unutar veze kojoj već vjerujete.

GRE je enkapsulacija između dviju adresa. Nosi pakete mrežnog sloja preko logičkog overlaya i sam po sebi ne nudi ni povjerljivost ni autentificirani identitet druge strane. To nije nedostatak: zaglavlje je namjerno jednostavno kako bi obrada na sklopovlju za prosljeđivanje ostala jeftina. Posljedica je da GRE odgovara na „kako premjestiti ovaj paket između dviju adresa“ i ni na što drugo — upravo na pitanje koje mu treba postaviti.

Time IPsec ostaje sloj koji odabire promet, autentificira druge strane i šifrira ono što mu je rečeno štititi. Koji promet štiti konfiguracijska je odluka koja se mora podudarati s enkapsulacijom koju krajnje točke stvarno stvaraju, jer se pravilo napisano za vanjsku adresu GRE-a ponaša drukčije od onoga napisanog za unutarnje prefikse. Specifikacija GRE vidljivo drži odvojenima korisni teret, GRE zaglavlje i vanjski protokol dostave, a vaše pravilo treba isto razdvajanje.

Napišite put paketa prije konfiguracije

Uzmite jedan paket i navedite svako dodano zaglavlje redom kojim se dodaje, imenujući uređaj koji ga dodaje. Za korisnika koji se uvezuje to je obično PPP unutar L2TP-a unutar IPsec-a; za overlay lokacija, unutarnji IP paket unutar GRE-a unutar IPsec-a. Ako dva uređaja dodaju isto zaglavlje, imate petlju ili udvostručeni tunel, i nikakvo uređivanje pravila to ne popravlja.

Isti popis rješava MTU, jer je upotrebljiva unutarnja veličina izmjereni MTU puta minus zaglavlja koja ste upravo naveli i ništa drugo. Ne prepisujte broj s forumske objave: zbrojite trošak vanjskog IP-a, UDP-a i ESP-a, zatim GRE-a ili L2TP-a, zatim PPP-a gdje se primjenjuje, i oduzmite od MTU-a puta koji ste stvarno izmjerili. Simptomi koji se javljaju samo pri velikim prijenosima, ili sesije koje se uspostave i zatim umru na prvom velikom odgovoru, obično vode natrag do toga da je taj zbroj napravljen nagađanjem.

Provjerite svaki sloj zasebno, izvana prema unutra

Provjere izvodite redom i zaustavite se na prvoj koja ne uspije. Svaki redak odgovara na drugo pitanje, pa kvar upućuje na jedan stupac radnog lista umjesto da kaže da je tunel pokvaren.

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 Cisco uređaju ekvivalent ovisi o ulozi, a točna sintaksa ovisi o platformi i izdanju: show crypto session za IPsec druge strane, brojači sučelja za GRE ili tunelsko sučelje, i provjera VPDN ili PPP za ulogu uvezivanja. Skup naredbi koji prekida PPP ne dokazuje ništa o podršci za GRE, a ispravno GRE sučelje ne dokazuje ništa o PPP usluzi, pa provjerite ulogu koju ste stvarno konfigurirali, a ne onu s dijagrama.

Zabilježite svaki izlaz uz redak radnog lista kojem pripada. Bilješke nastale dok je kvar aktivan vrijede više od topologije kasnije ponovno nacrtane po sjećanju.

Uredite rastavljanje, zatim ponovno provjerite

Rastavljanje ide obrnutim redom s razlogom: izvadite zaštićeni promet iz IPsec pravila prije nego uklonite enkapsulaciju za koju je napisano, inače pravilo i dalje pokazuje na sučelje kojega više nema i sljedeće učitavanje konfiguracije padne negdje što izgleda nepovezano. Na Linuxu to znači brisanje stavki stanja i pravila prije tunelskog sučelja; na usmjerivaču uklanjanje crypto map ili profile stavke prije tunela.

Nakon ponovne izgradnje ponovite četiri opažanja prihvata jedno po jedno: vanjska dostupnost, uspostavljena IPsec asocijacija, uspostavljena PPP sesija gdje je nacrt uključuje, i unutarnje prosljeđivanje na stvarnu odredišnu adresu. Jedno zeleno svjetlo nije dokaz za ostala tri, a ta praznina je kvar koji najdulje preživi u produkciji — tunel koji je podignut, šifriran i ništa ne prosljeđuje jer unutarnja ruta nikada nije dodana.

Držite ispunjeni radni list uz konfiguraciju uređaja. Svaki stupac koji ne možete ispuniti sloj je bez dodijeljenog zadatka, a sloj bez dodijeljenog zadatka obično je sloj kojemu nije mjesto u stogu.