Два VPN скока заредом: ко заправо види ваш саобраћај?

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

Почните од клијента и именујте оба краја

Почните тамо где корисник почиње, у профилу везе. Он садржи једну удаљену адресу, један метод аутентификације и, када дизајн то подржава, листу рута. Означите тај спољни тунел од клијента до пролаза A и дајте му пример адресе: адреса тунела клијента 10.77.0.2, адреса A 10.77.0.1 и јавна крајња тачка A 198.51.100.10, узете из документационог опсега TEST-NET-2 да ништа у примеру не би могло да се сукоби са стварним домаћином.

Ништа у том профилу не помиње пролаз B, и то није дефект. Други скок припада A, а једина обавеза клијента је да достави саобраћај до A и прихвати оно што се врати. Да ли A завршава тунел, прослеђује га или отвара нови, питање је на које одговара остатак овог прегледа, и оно одређује шта A може да чита.

Серијски: A дешифрује, затим поново шифрује

У серијском дизајну A завршава саобраћај двапут. Уклања заштиту са клијента, добија IP пакет апликације и затим тај пакет шаље кроз други тунел који A успоставља према B. Између те две операције пакет стоји на путу прослеђивања A као обичан IP пакет адресиран на приватно одредиште.

То даје две последице које вреди рећи отворено. A може да примени политику на унутрашњи пакет, у облику рута, филтер правила и евидентирања извора и одредишта, и A мора да држи два скупа акредитива: један као сервер за клијента и један као клијент B. Заштита постоји у сваком тренутку, али заштићени објекат мења идентитет код A.

Из тога не следи да A чита отворени текст апликације. Када клијент и услуга користе TLS и проверавају сертификате један другом, A види ток TLS записа, а не читљив захтев. Потврда где та заштита престаје захтева поглед на ланац сертификата услуге, а не на шему тунела.

Угнежђено: A уклања само спољни слој

У угнежђеном дизајну клијент прво гради унутрашњи тунел према B, а затим тај тунел носи унутар спољног до A. A скида спољни заглавље, проналази унутрашњи тунел и прослеђује га без држања његових кључева, па се унутрашња заштита и даље завршава код B.

Тада узлазна веза клијента носи два слоја, док пут између A и B носи један. A види спољне адресе унутрашњег тунела, што је довољно да се зна да саобраћај постоји и отприлике куда иде, а није довољно да се прочита терет. То је цела разлика од серијског случаја, и ниједан бројач скокова је не показује. Оно што A још може јесте да одбије да проследи оно што не може да прочита, а то је оператеру тог пролаза увек доступно.

Угнежђивање плаћа ту особину. Сваки слој додаје трошак заглавља, па планирање MTU и MSS постаје обавезно, а не само уредно, и пут који ради са једним слојем може тихо да изгуби велике пакете са два. Сваки слој захтева и сопствено понашање при поновном повезивању и одржавању везе, а квар у једном слоју изгледа као делимичан прекид кроз други.

Нацртајте посматраче, не само тунеле

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

Два реда се стално мешају: оператер A и добављач клијентовог тунела. Они могу бити један субјект, а одвојена имена пролаза не чине их независним. Независно власништво захтева одвојену административну контролу, одвојене акредитиве и одвојено евидентирање.

Метаподаци преживљавају оба дизајна. Време, величине пакета и број веза остају видљиви на сваком скоку, па два скока подижу цену корелације уместо да уклоне сигнал. Дизајн који обећава невидљивост треба проверити према тој листи пре него што се неко на њега ослони.

Прођите путеве отказа пре него што изаберете

Ломите ствари намерно са клијента, редом којим би их корисник срео. Почните од интерфејса и његовог MTU, јер угнежђивање пада на величини пакета много пре него на аутентификацији.

ip -4 addr show dev tun0
ip link show dev tun0 | grep mtu
ping -M do -s 1380 -c 2 10.77.1.1

Затим потврдите крајње тачке заштите уместо да их претпостављате. Затражите од услуге њен сертификат изнутра било ког активног тунела и упоредите ланац који клијент види са ланцем који услуга заиста представља. Пролаз који поново потписује или пресреће мења тај сертификат, и провера постаје видљива једном командом.

openssl s_client -connect intranet.example.com:443 -brief < /dev/null

Завршите матрицом поновног повезивања: тунел клијента пада, тунел B пада, пут између A и B се мења. Забележите шта се враћа, а шта не, и да ли унутрашња веза икада пада на руту изван свог предвиђеног носиоца. Запишите адресе које је сваки тест користио, јер понављање на другој приступној мрежи одговара на друго питање. Поновите и проверу MTU после сваког поновног повезивања, јер измењен пут може да снизи употребљиву величину без да се помери иједан ред конфигурације.

Изаберите серијски када A мора да примени политику на унутрашњи пакет, или када клијент не може да покрене два наслагана тунела. Изаберите угнежђивање када унутрашњи терет мора да остане нечитљив код A. Запишите избор са његовим посматрачима и његовим бројевима MTU, и следећа особа неће морати поново да црта целу слику да би одговорила на једно питање.