L2TP, GRE of IPsec: watter laag moet die sessie dra?

Twee vrae raak deurmekaar wanneer L2TP, GRE en IPsec in dieselfde ontwerpnota beland: watter sessie dra ek, en watter laag beskerm dit? Kry die eerste een verkeerd en alles stroomaf bly intern konsekwent terwyl die verkeerde probleem opgelos word — ’n gerouteerde overlay wat gebou is waar gebruikers moes inbel, of ’n inbelkonsentrator wat as ’n werf-tot-werf-gateway dien. Die werkblad hieronder dwing daardie onderskeid af voordat enigiemand by ’n toestel aanmeld. Vul dit in volgorde in en elke reël word iets wat jy op sy eie kan toets.

Begin by die sessie, nie by die protokollelys nie

’n Afgeleë gebruiker met ’n PPP-sessie en ’n gerouteerde overlay tussen twee gateways is verskillende netwerkverhoudings, selfs wanneer albei uiteindelik in IPsec toegedraai word. Die eerste een beëindig ’n per-gebruiker-skakel en benodig adrestoewysing, verifikasie van ’n persoon of toestel, en ’n beleid wat noem watter interne netwerke daardie gebruiker mag bereik. Die tweede een stuur pakkette tussen persele waarby niemand inbel nie.

Skryf een sin wat noem watter van die twee jy bou, en lees dit dan terug asof jy die persoon is wat dit moet bestuur. As die sin die woord 'en' nodig het, bou jy albei, en die werkblad het twee kolomme nodig in plaas van een kompromiskolom wat elkeen half dien. As dit ’n gebruiker noem maar geen adrespoel nie, of ’n voorvoegsel maar geen aanstuurbeleid nie, is die sin nog onvolledig. Die formulering klink burokraties, maar dit is die goedkoopste plek om ’n ontwerp te vang wat anders deur ’n helpdeskkaartjie ontdek word.

Gee elke laag presies een taak

L2TPv2 dra PPP-sessies tussen sy twee eindpunte. PPP doen die skakelonderhandeling en, wanneer dit onderhandel word, die gebruikerverifikasie; L2TP voeg geen kriptografie by nie, dus ’n kaal L2TP-daemon implementeer niks van die IPsec-veiligheidsverhouding nie en hoort net binne ’n skakel wat jy reeds vertrou.

GRE is ’n inkapseling tussen twee adresse. Dit dra pakkette van die netwerklaag oor ’n logiese overlay en bied op sy eie nóg vertroulikheid nóg ’n geoutentiseerde eweknie-identiteit. Dit is nie ’n defek nie: die kop is eenvoudig ontwerp sodat dit goedkoop bly om op aanstuurhardeware te verwerk. Die gevolg is dat GRE die vraag 'hoe beweeg ek hierdie pakket tussen twee adresse' beantwoord en niks anders nie — presies die vraag wat jy dit moet vra.

Dit laat IPsec oor as die laag wat verkeer selekteer, die eweknieë verifieer en versleutel wat dit opgedra is om te beskerm. Watter verkeer dit beskerm, is ’n konfigurasiebesluit wat moet pas by die inkapseling wat die eindpunte werklik genereer, want ’n beleid wat vir die buitenste GRE-adres geskryf is, gedra hom anders as een vir die binneste voorvoegsels. Die GRE-spesifikasie hou nutslading, GRE-kop en buitenste vervoerprotokol sigbaar apart, en jou beleid het dieselfde skeiding nodig.

Skryf die pakketpad voor die konfigurasie

Neem een pakket en lys elke kop wat bygevoeg word, in die volgorde waarin dit bygevoeg word, en noem die toestel wat dit byvoeg. Vir ’n inbelgebruiker is dit gewoonlik PPP binne L2TP binne IPsec; vir ’n werf-overlay die binneste IP-pakket binne GRE binne IPsec. As twee toestelle dieselfde kop byvoeg, het jy ’n lus of ’n duplikaat-tonnel, en geen beleidwysiging maak dit reg nie.

Dieselfde lys bepaal die MTU, want die bruikbare binneste grootte is die gemete pad-MTU minus die koppe wat jy pas opgenoem het en niks anders nie. Moenie ’n getal uit ’n forumpos kopieer nie: tel die oorhoofse koste van buitenste IP, UDP en ESP bymekaar, dan GRE of L2TP, dan PPP waar dit geld, en trek dit af van die pad-MTU wat jy werklik gemeet het. Simptome wat net by groot oordragte verskyn, of sessies wat vestig en dan op die eerste groot antwoord sterf, lei gewoonlik terug na daardie optelling wat op ’n raaiskoot gedoen is.

Kontroleer elke laag afsonderlik, van buite na binne

Voer die kontroles in volgorde uit en stop by die eerste een wat misluk. Elke reël beantwoord ’n ander vraag, dus ’n mislukking wys na een kolom van die werkblad eerder as om te sê die tonnel is stukkend.

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?

Op ’n Cisco-boks is die ekwivalent rolspesifiek, en die presiese sintaksis hang af van platform en vrystelling: show crypto session vir die IPsec-eweknieë, koppelvlak-tellers vir die GRE- of tonnelkoppelvlak, en die VPDN- of PPP-verifikasie vir die inbelrol. ’n Opdragstel wat PPP beëindig, bewys niks oor GRE-ondersteuning nie, en ’n werkende GRE-koppelvlak bewys niks oor die PPP-diens nie, dus verifieer die rol wat jy werklik gekonfigureer het eerder as die een in die diagram.

Teken elke uitset langs die werkbladreël aan waarby dit hoort. Notas wat geneem word terwyl die fout lewendig is, is meer werd as ’n topologie wat daarna uit die geheue herteken word.

Orde die afbreek, en verifieer dan weer

Die afbreek loop omgekeerd vir ’n rede: haal die beskermde verkeer uit die IPsec-beleid voordat jy die inkapseling verwyder waarvoor dit geskryf is, anders bly die beleid na ’n koppelvlak wys wat nie meer bestaan nie en misluk die volgende konfigurasielaaiing op ’n plek wat onverwant lyk. Op Linux beteken dit die state- en policy-inskrywings voor die tonnelkoppelvlak te verwyder; op ’n roeteerder die crypto-map- of profile-inskrywing voor die tonnel te verwyder.

Herhaal ná die herbou die vier aanvaardingwaarnemings een vir een: buitenste bereikbaarheid, ’n gevestigde IPsec-assosiasie, ’n gevestigde PPP-sessie waar die ontwerp een insluit, en binneste aanstuur na ’n werklike bestemmingsadres. Een groen lig is nie bewys vir die ander drie nie, en daardie gaping is die fout wat die langs in produksie oorleef — ’n tonnel wat op is, versleutel is en niks aanstuur nie omdat die binneste roete nooit bygevoeg is nie.

Hou die ingevulde werkblad langs die toestelkonfigurasie. Enige kolom wat jy nie kan invul nie, is ’n laag met geen toegewysde taak nie, en ’n laag met geen toegewysde taak is gewoonlik ’n laag wat nie in die stapel hoort nie.