L2TP, GRE или IPsec: који слој треба да носи сесију?

Два питања се запетљају кад год L2TP, GRE и IPsec дођу у исту пројектну белешку: коју сесију носим и који слој је штити? Ако прво буде погрешно, све низводно остаје интерно доследно док се решава погрешан проблем — рутирани overlay се гради тамо где је требало да се корисници убацују, или концентратор за убацивање стоји уместо мрежног пролаза између локација. Радни лист испод намеће ту разлику пре него што се било ко пријави на уређај. Испуните га редом и сваки ред постаје нешто што можете засебно да испробате.

Почните од сесије, а не од списка протокола

Удаљени корисник са PPP сесијом и рутирани overlay између два мрежна пролаза различити су мрежни односи, чак и кад обоје на крају буде умотано у IPsec. Први завршава везу по кориснику и тражи доделу адреса, аутентификацију особе или уређаја и правило које именује које унутрашње мреже тај корисник сме да достигне. Други прослеђује пакете између локација у које се нико не убацује.

Напишите једну реченицу која именује шта од то двоје градите, па је прочитајте као да сте особа која то мора да води. Ако реченици треба реч „и“, градите обоје, а радни лист треба два ступца уместо једног компромисног који свакоме служи напола. Ако именује корисника али нема скупа адреса, или префикс али нема правила прослеђивања, реченица је још непотпуна. Формулација звучи бирократски, али то је најјефтиније место да ухватите нацрт који би иначе открио захтев према подршци.

Доделите сваком слоју тачно један задатак

L2TPv2 носи PPP сесије између своје две крајње тачке. PPP води преговарање везе и, кад се оно преговара, аутентификацију корисника; L2TP не додаје никакву криптографију, па голи L2TP демон не имплементира ниједан део IPsec безбедносног односа и припада само унутар везе којој већ верујете.

GRE је инкапсулација између две адресе. Носи пакете мрежног слоја преко логичког overlaya и сам по себи не нуди ни поверљивост ни аутентификовани идентитет друге стране. То није недостатак: заглавље је намерно једноставно како би обрада на склоповима за прослеђивање остала јефтина. Последица је да GRE одговара на „како преместити овај пакет између две адресе“ и ни на шта друго — управо на питање које му треба поставити.

Тиме IPsec остаје слој који бира саобраћај, аутентификује друге стране и шифрује оно што му је речено да штити. Који саобраћај штити конфигурацијска је одлука која мора да се подудара са инкапсулацијом коју крајње тачке стварно стварају, јер се правило написано за спољну адресу GRE-а понаша другачије од оног написаног за унутрашње префиксе. Спецификација GRE видљиво држи одвојенима корисни терет, GRE заглавље и спољни протокол доставе, а ваше правило треба исто раздвајање.

Напишите пут пакета пре конфигурације

Узмите један пакет и наведите свако додато заглавље редом којим се додаје, именујући уређај који га додаје. За корисника који се убацује то је обично PPP унутар L2TP-а унутар IPsec-а; за overlay локација, унутрашњи IP пакет унутар GRE-а унутар IPsec-а. Ако два уређаја додају исто заглавље, имате петљу или удвостручен тунел, и никакво уређивање правила то не поправља.

Исти списак решава MTU, јер је употребљива унутрашња величина измерени MTU пута минус заглавља која сте управо навели и ништа друго. Не преписујте број са форумске објаве: саберите трошак спољног IP-а, UDP-а и ESP-а, затим GRE-а или L2TP-а, затим PPP-а где се примењује, и одузмите од MTU-а пута који сте стварно измерили. Симптоми који се јављају само при великим преносима, или сесије које се успоставе и затим умру на првом великом одговору, обично воде назад до тога да је тај збир направљен нагађањем.

Проверите сваки слој засебно, споља према унутра

Провере изводите редом и зауставите се на првој која не успе. Сваки ред одговара на друго питање, па кварење упућује на један стубац радног листа уместо да каже да је тунел покварен.

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 уређају еквивалент зависи од улоге, а тачна синтакса зависи од платформе и издања: show crypto session за IPsec друге стране, бројачи интерфејса за GRE или тунелски интерфејс, и провера VPDN или PPP за улогу убацивања. Скуп наредби који прекида PPP не доказује ништа о подршци за GRE, а исправан GRE интерфејс не доказује ништа о PPP услузи, па проверите улогу коју сте стварно конфигурисали, а не ону са дијаграма.

Забележите сваки излаз уз ред радног листа коме припада. Белешке настале док је квар активан вреде више од топологије касније поново нацртане по сећању.

Уредите растављање, затим поново проверите

Растављање иде обрнутим редом с разлогом: извадите заштићени саобраћај из IPsec правила пре него што уклоните инкапсулацију за коју је написано, иначе правило и даље показује на интерфејс којег више нема и следеће учитавање конфигурације падне негде што изгледа неповезано. На Linux-у то значи брисање ставки стања и правила пре тунелског интерфејса; на рутеру уклањање crypto map или profile ставке пре тунела.

Након поновне изградње поновите четири опажања прихвата једно по једно: спољна доступност, успостављена IPsec асоцијација, успостављена PPP сесија где је нацрт укључује, и унутрашње прослеђивање на стварну одредишну адресу. Једно зелено светло није доказ за остала три, а та празнина је квар који најдуже преживи у продукцији — тунел који је подигнут, шифрован и ништа не прослеђује јер унутрашња рута никада није додата.

Држите испуњени радни лист уз конфигурацију уређаја. Сваки стубац који не можете испунити слој је без додељеног задатка, а слој без додељеног задатка обично је слој којем није место у стеку.