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-сесія, калі праект яе ўключае, і ўнутраная перасылка да рэальнага адраса прызначэння. Адзін зялёны агеньчык не з'яўляецца доказам для іншых трох, і менавіта гэтая прага — збой, які жыве ў вытворчасці даўжэй за ўсё: тунель падняты, зашыфраваны і нічога не перадае, бо ўнутраны маршрут так і не быў дададзены.

Трымайце запоўненую табліцу побач з канфігурацыяй прылады. Любы слупок, які вы не можаце запоўніць, — гэта ўзровень без прызначанай задачы, а ўзровень без прызначанай задачы звычайна не павінен быць у стэку.