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 тоа значи бришење на записите за состојба и политика пред тунелскиот интерфејс; на рутер, отстранување на крипто мапата или записот на профилот пред тунелот.

По повторното градење, повторете ги четирите набљудувања за прифаќање едно по едно: надворешна достапност, воспоставено IPsec здружување, воспоставена PPP сесија каде што проектот вклучува една, и внатрешно препраќање до вистинска целна адреса. Едно зелено светло не е доказ за другите три, а токму таа празнина е дефектот што најдолго опстојува во производство — тунел што е подигнат, шифриран и не препраќа ништо затоа што внатрешната рута никогаш не била додадена.

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