ESP inayotoka bila jibu haimaanishi kuwa VPN imekufa
ESP hulinda mwelekeo mmoja kwa kila muungano na haithibitishi chochote. Linganisha mazungumzo ya ndani na SA inayoingia kabla ya kuita seva kuwa isiyojibu.
Umenasa trafiki kwenye mwenyeji wa IPsec, ukaona pakiti za ESP zikitoka, hukuona chochote kikirudi, na ukahitimisha kuwa upande wa mbali umeharibika. Unasaji hauungi mkono hitimisho hilo. ESP hulinda mwelekeo mmoja wa mazungumzo na haithibitishi chochote katika tabaka la IP, kwa hiyo ESP ya kurudi inayokosekana inaweza kumaanisha kuwa programu haikuwa na chochote cha kusema kwa urahisi sawa na inavyoweza kumaanisha kuwa handaki imekufa. Soma mabadilishano ya ndani na hali ya upande unaopokea kabla ya kulaumu upande wowote.
Hadithi potofu: kila pakiti iliyolindwa hupata jibu
ESP si itifaki ya ombi na jibu. Husimba na kuthibitisha chochote kinachochaguliwa na sera, na mpokeaji huthibitisha, husimbua na kuwasilisha pakiti hiyo ya ndani bila kuzalisha pakiti yake mwenyewe. Ombi la UDP ambalo lengo hulipuuza, au mwangwi wa ICMP ambao sera ya kuingia huutupa, huzalisha ukimya katika pande zote mbili kama matokeo sahihi. Kuchukua ukimya huo kama hitilafu ya usafirishaji kunakupeleka kutafuta hitilafu ya mtandao ambayo haikuwahi kuwepo.
Kile unasaji wa mwelekeo mmoja huthibitisha kwa kweli ni kwamba staki ya mtumaji ilisimba kitu katika hatua hiyo ya uchunguzi. Hakuna kuhusu kuwasili, na hakuna kuhusu nia ya kujibu. Swali lenye manufaa si „kwa nini hakuna jibu“ bali „mazungumzo ya ndani yalipaswa kuzalisha nini“.
SA mbili, SPI mbili, mazungumzo moja
Muungano wa usalama wa IPsec ni wa mwelekeo mmoja, kwa hiyo mabadilishano ya kawaida yaliyolindwa huendesha muungano unaoingia na muungano unaotoka wenye vitambulisho tofauti na hali huru. Kutafuta trafiki ya kurudi kwa SPI ya pakiti inayotoka kwa hiyo ni kosa la kategoria, kwa sababu jibu lolote husafiri chini ya SA yenyewe inayotoka ya mwenzake na SPI yake mwenyewe. Badala yake oanisha jozi kwa vichaguzi vya trafiki na anwani za mwenzake.
Ufunguo mpya hufanya picha kuwa ngumu kwa sekunde chache, kwa kuwa hali ya zamani na ya badala inaweza kupishana. Ikiwa dalili ilianza karibu na mabadiliko ya ufunguo, kusanya vitambulisho vya muungano na alama za muda pamoja na si jina la muunganisho pekee.
Kile mpokeaji anapaswa kufanya kabla ya kitu chochote kujibu
| 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" |
Kila safu hushindwa kwa kujitegemea na kila hitilafu ina mmiliki tofauti, ndiyo sababu unasaji mmoja hauwezi kuzitofautisha. Kihesabu cha kuingia ndicho ushahidi pekee wa moja kwa moja wa kuwasili, kwa sababu pakiti inayoshindwa uthibitishaji au ukaguzi wa marudio hutupwa bila jibu lolote. Mwenzake ambaye kihesabu chake cha kuingia hakijasogea hakupi habari yoyote kuhusu sera yake.
Uwasilishaji ni hatua tofauti na usimbuaji. Hali inaweza kuwa halali na pakiti bado ikatupwa baadaye na sera ya kuingia au njia isiyojumuisha lengo la ndani, kwa hiyo angalia kama mwenyeji lengwa aliona maandishi wazi badala ya kudhani kuwa kihesabu safi kinamaanisha pakiti ilikwenda mahali ulipokuwa unataka.
ESP ya asili si UDP
ESP ya asili ni itifaki ya IP 50, ambayo si TCP wala UDP na haina bandari zozote. Kwa hiyo kanuni ya firewall inayoruhusu IKE kwenye UDP 500 haisemi chochote kuhusu njia ya data, na kichujio kilichoandikwa kuzunguka bandari kinaweza kuiruhusu handaki kujadiliana kisha kutupa kila kitu kinachobebwa ndani yake. Jaribu njia ya data peke yake, katika hali uliyoiona kwa kweli.
Nyuma ya NAT umbo hubadilika: mzigo uliolindwa husafiri ndani ya UDP, kwa kawaida kwenye bandari 4500, kama RFC 3948 inavyofafanua. Rekodi hali inayotumika kabla ya kuandika kanuni yoyote, kwa sababu kifaa kilicho njiani kinaweza kushughulikia ESP ya asili na ESP iliyofungwa ndani ya UDP kwa njia tofauti kabisa, na baadhi ya masanduku ya kati huruhusu moja huku yakitupa lingine.
Soma vihesabu vinavyohusiana na tukio hili
Kwenye mwenyeji wa strongSwan, swanctl --list-sas huripoti vihesabu vya pakiti na baiti kwa kila muungano katika pande zote mbili, jambo linalotosha kutenganisha „hakuwahi kuwasili“ na „aliwasili na hakujibiwa“. Kwenye Linux, /proc/net/xfrm_stat huhesabu hitilafu zilizojumlishwa kama hali inayokosekana, sera inayokosekana na hitilafu za itifaki. Jumla hizo hukusanywa tangu kuwasha na zinahusiana na nafasi moja ya majina ya mtandao, kwa hiyo namba kubwa si sifa.
Chukua vipimo viwili kuzunguka dirisha la tukio katika nafasi sahihi ya majina na linganisha tofauti, vinginevyo utaweka hitilafu za wiki iliyopita kwenye tiketi ya mchana huu. Weka nafasi ya majina na alama zote mbili za muda kwenye tiketi ili msomaji anayefuata aweze kurudia ulinganisho badala ya kuamini jumla.
Taja hatua, si mshukiwa
Hitimisho lenye manufaa husema pakiti ilisimama wapi: haikuwahi kupokelewa, ilipokelewa na kutupwa, iliwasilishwa lakini bila jibu, au ilijibiwa na ikapotea njiani kurudi. Kila moja ya haya huelekeza kwa mmiliki tofauti na amri inayofuata tofauti. „Hakuna jibu kutoka kwa seva ya VPN“ huunganisha hitilafu nne tofauti katika sentensi moja ambayo unasaji haukuihalalisha kamwe.
Weka unasaji nyembamba, na usiweke hali mbichi ya kerneli kwenye tiketi, kwa sababu inaweza kubeba nyenzo za ufunguo ambazo hazipaswi kuondoka kwenye mwenyeji. Tofauti za vihesabu na alama za muda ni sehemu zinazofaa kukabidhiwa kwa mtu anayefuata.