Излезниот ESP без одговор не значи дека VPN е мртов
ESP штити еден правец по асоцијација и ништо не потврдува. Усогласете го внатрешниот разговор и влезната SA пред да го наречете серверот неодговорен.
Сте фатиле сообраќај на IPsec хостот, гледавте како излегуваат ESP пакети, не видовте ништо да се враќа и заклучивте дека далечната страна е расипана. Фаќањето не ја поддржува таа заклучок. ESP штити еден правец на разговор и ништо не потврдува на IP слојот, така што отсутниот повратен ESP може исто толку лесно да значи дека апликацијата немала што да каже, како и дека тунелот е мртов. Прочитајте ја внатрешната размена и состојбата на страната што прима пред да обвините која било страна.
Мит: секој заштитен пакет добива одговор
ESP не е протокол за барање и одговор. Тој шифрира и автентицира сѐ што ќе избере политиката, а примачот го валидира, дешифрира и доставува тој внатрешен пакет без притоа да создаде пакет од себе. UDP барање што дестинацијата го игнорира, или ICMP ехо што влезната политика го отфрла, создава тишина во двата правци како точен исход. Третирањето на таа тишина како транспортна грешка ве тера да барате мрежен дефект што никогаш не постоел.
Она што навистина го докажува еднонасочното фаќање е дека стекот на испраќачот шифрирал нешто во таа точка на набљудување. Ништо за пристигнувањето и ништо за намерата да се одговори. Корисното прашање не е „зошто нема одговор“, туку „што требаше да произлезе од внатрешниот разговор“.
Две SA, два SPI, еден разговор
IPsec безбедносните асоцијации се еднонасочни, така што нормалната заштитена размена користи влезна асоцијација и излезна асоцијација со одделни идентификатори и независна состојба. Барањето на повратниот сообраќај според SPI на излезниот пакет е затоа категориска грешка, бидејќи секој одговор патува под сопствената излезна SA на партнерот со сопствен SPI. Наместо тоа, спарете ги по селектори на сообраќај и адреси на партнерот.
Промената на клучот ја комплицира сликата по неколку секунди, бидејќи старата и заменската состојба може да се преклопат. Ако симптомот започнал околу промена на клуч, соберете ги идентификаторите на асоцијациите и временските ознаки заедно, а не само името на врската.
Што мора да направи примачот пред нешто да одговори
| Stage | What to look at | Wrong conclusion if skipped |
|---|---|---|
| Sender encrypts | outbound SA packet counter | "the tunnel is up" |
| Peer receives | inbound SA counter and replay window | "the peer is down" |
| Inner delivery | target host or service logs | "routing is broken" |
| Application replies | the app's own trace | "the reply was dropped" |
| Protected return | the peer's outbound SA | "ESP only works one way" |
Секој ред откажува независно и секој дефект има различен сопственик, поради што едно фаќање не може да ги разликува. Влезниот бројач е единствениот директен доказ за пристигнување, бидејќи пакет што не ја помине автентикацијата или проверката за повторување се отфрла без никаков одговор. Затоа партнерот чиј влезен бројач не е поместен воопшто не ви испраќа информација за својата политика.
Доставата е одделен чекор од дешифрирањето. Состојбата може да е валидна, а пакетот сепак подоцна да биде отфрлен од влезна политика или маршрута што не ја вклучува внатрешната дестинација, па проверете дали целниот хост видел чист текст, наместо да претпоставувате дека чист бројач значи дека пакетот отишол каде што сакавте.
Изворниот ESP не е UDP
Изворниот ESP е IP протокол 50, кој не е ниту TCP ниту UDP и воопшто нема порти. Затоа правило на огнениот ѕид што дозволува IKE на UDP 500 не кажува ништо за патеката на податоците, а филтер напишан околу порти може да дозволи тунелот да преговара, а потоа да отфрли се што се носи внатре. Тестирајте ја патеката на податоците одделно, во режимот што навистина сте го набљудувале.
Зад NAT сликата се менува: заштитениот товар патува внатре во UDP, обично на портата 4500, како што дефинира RFC 3948. Забележете го активниот режим пред да напишете било какво правило, бидејќи уред на патеката може сосема различно да го третира изворниот ESP и ESP инкапсулираниот во UDP, а некои посредни уреди дозволуваат едното додека го отфрлаат другото.
Читајте ги бројачите што припаѓаат на овој инцидент
На strongSwan хост, swanctl --list-sas пријавува бројачи на пакети и бајти по асоцијација во двата правци, што е доволно за да се разликува „никогаш не пристигна“ од „пристигна и не беше одговорено“. На Linux, /proc/net/xfrm_stat брои збирни грешки како отсутна состојба, отсутна политика и протоколарни грешки. Тие вкупни вредности се акумулираат од подигнувањето и припаѓаат на еден мрежен именски простор, па голем број не е припишување.
Земете две читања околу прозорецот на инцидентот во точниот именски простор и споредете ги разликите, инаку ќе ги прикачите минатонеделните грешки на денешниот тикет. Ставете ги именскиот простор и двете временски ознаки во тикетот, за следниот читач да може да ја повтори споредбата наместо да и верува на вкупната вредност.
Именувајте ја фазата, а не осомничениот
Корисна заклучок кажува каде пакетот застанал: никогаш не пристигнал, пристигнал и бил отфрлен, доставен но без одговор, или одговорен и изгубен на враќање. Секој од нив упатува на различен сопственик и различна следна команда. „Нема одговор од VPN серверот“ спојува четири различни дефекти во една реченица што фаќањето никогаш не ја оправдало.
Држете ги фаќањата тесни и не ставајте сурова состојба на јадрото во тикети, бидејќи може да носи клучен материјал што не треба да го напушти хостот. Разликите во бројачите и временските ознаки се деловите што вреди да му се предадат на следниот човек.