L2TP, GRE или IPsec: кой слой трябва да носи сесията?

Всеки път, когато L2TP, GRE и IPsec попаднат в една проектна бележка, два въпроса се объркват: коя сесия нося и кой слой я защитава? Сгрешете ли първия, всичко надолу остава вътрешно съгласувано, докато решава грешния проблем — маршрутизиран овърлей, изграден там, където потребителите е трябвало да се включват, или концентратор за включване вместо шлюз сайт-към-сайт. Работният лист по-долу налага това разграничение, преди някой да влезе в устройство. Попълнете го по ред и всеки ред става нещо, което можете да проверите самостоятелно.

Започнете от сесията, а не от списъка с протоколи

Отдалечен потребител с PPP сесия и маршрутизиран овърлей между два шлюза са различни мрежови отношения, дори когато и двете в крайна сметка са обвити в IPsec. Първото прекратява връзка за конкретен потребител и изисква назначаване на адреси, удостоверяване на човек или устройство и политика, която посочва кои вътрешни мрежи този потребител може да достигне. Второто препраща пакети между сайтове, в които никой не се включва.

Напишете едно изречение, което посочва кое от двете изграждате, после го прочетете отново, сякаш вие сте човекът, който ще го експлоатира. Ако изречението се нуждае от думата «и», изграждате и двете и работният лист се нуждае от две колони вместо една компромисна колона, която обслужва половинчато всяка. Ако в него е посочен потребител, но не и пул от адреси, или префикс, но не и политика за препращане, изречението все още е непълно. Формулировката звучи бюрократично, но това е най-евтиното място да хванете проект, който иначе ще бъде открит чрез заявка до поддръжката.

Дайте на всеки слой точно една задача

L2TPv2 носи PPP сесии между двете си крайни точки. PPP води договарянето на връзката и, когато то се проведе, удостоверяването на потребителя; L2TP не добавя криптография, затова гол демон L2TP не реализира никоя част от отношенията за сигурност на IPsec и принадлежи само вътре във връзка, на която вече се доверявате.

GRE е инкапсулация между два адреса. Той пренася пакети от мрежовия слой през логически овърлей и сам по себе си не предлага нито поверителност, нито удостоверена идентичност на партньора. Това не е дефект: заглавката е проектирана проста, за да остане обработката ѝ евтина във форуърдинг хардуера. Следствието е, че GRE отговаря на въпроса «как да преместя този пакет между два адреса» и на нищо друго, а точно това е въпросът, който трябва да му зададете.

Така IPsec остава слоят, който избира трафика, удостоверява партньорите и криптира това, което му е наредено да защитава. Кой трафик защитава е конфигурационно решение, което трябва да съответства на инкапсулацията, която крайните точки действително генерират, защото политика, написана за външния адрес на GRE, се държи различно от такава, написана за вътрешните префикси. Спецификацията на GRE държи полезния товар, заглавката на GRE и външния протокол за доставка видимо отделени и вашата политика се нуждае от същото разделение.

Напишете пътя на пакета преди конфигурацията

Вземете един пакет и избройте всяка заглавка, която се добавя, в реда, в който се добавя, като посочите устройството, което я добавя. За потребител, който се включва, това обикновено е PPP в L2TP в IPsec; за овърлей на сайт това е вътрешният 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 или профил преди тунела.

След преизграждането повторете четирите наблюдения за приемане едно по едно: външна достигаемост, установена IPsec асоциация, установена PPP сесия, когато проектът включва такава, и вътрешно препращане към реален адрес на местоназначение. Една зелена светлина не е доказателство за другите три и точно тази пропаст е повредата, която оцелява най-дълго в продукция — тунел, който е вдигнат, криптиран и не препраща нищо, защото вътрешният маршрут така и не е добавен.

Пазете попълнения работен лист до конфигурацията на устройството. Всяка колона, която не можете да попълните, е слой без възложена задача, а слой без възложена задача обикновено е слой, който не би трябвало да е в стека.