Zergatik huts egiten duen IKEv2k Androiden UDP ataka ez-estandarrean

IKEv2ren jatorrizko formularioak helbide bat hartzen du, ez ataka bat. Egiaztatu bezeroak onartzen duela, ezarri zerbitzariaren bi atakak, eta gero aztertu markaketa eta erregistroak.

Pasabideak IKEv2ri UDP 4443n erantzuten dio arrazoi batengatik, profilean Server izeneko eremu bat dago, ostalari-izena eta ataka idazten dituzu, eta telefonak salatzen du ez duela zerbitzarira iristen edo ezin duela helbidea ebazten. Ezer ez dago blokeatuta. Androiden jatorrizko formularioak ostalari bat espero du, eta berdin gertatzen da Windowsekin. Ataka pertsonalizatua bezeroaren gaitasun bat da zerbitzariaren ezarpena izan aurretik, eta bezero batzuek soilik uzten dute adierazten. Ikus itzazu hiru atalak ordenan: zer esan dezakeen bezeroak, zeri entzuten dion zerbitzariak eta bi muturrak paketeak modu berean markatzen dituzten.

Zer bidali zuen telefonak benetan

Izen baterako pentsatutako eremu batean dagoen host:port katea izen gisa ebazten da. Ebazleak ez du ezer itzultzen vpn.example.net:4443 balioarekin, eta ikusten duzun errorea izen-ebazpenaren edo irisgarritasunaren hutsegitea da, ez ataka bateko itxarote-denbora agortzea. Bereizketa horrek garrantzia du, izen laburragoarekin edo beste sare batekin berriro saiatzeak ez duelako inoiz konponduko formularioak analizatu ezin duen kate bat.

Androiden jatorrizko IKEv2 profila, Windowsen barneko VPN bezeroa bezala, IKE ataka estandarretara dago finkatuta. Bietako batek ez du ataka-eremurik erakusten, eta profileko edozein aldaketak ez du bat gehitzen. Operadorearen entzulea benetan 4443n badago, barneko bezeroa tresna okerra da, ez gaizki konfiguratutako bat.

Erabili ataka erakusten duen bezero bat

strongSwanen Android bezeroak zerbitzari-ataka konfiguragarria dokumentatzen du profileko ezarpen aurreratuetan, horregatik agertzen da diseinu honetarako ia errezeta guztietan. Laguntza hori bezero horri dagokio: beste IKEv2 aplikazio batek, edo aplikazio beraren hornitzaile-fork batek, baliteke eremu bera ez erakustea, azpiko strongSwan daemonak onartzen badu ere.

Eskatu operadoreari multzo osoa batera: pasabidearen izena, UDP ataka, autentifikazio-metodoa eta bezeroak espero behar duen zerbitzari-nortasuna. Ataka pertsonalizatua ez da ziurtagirien egiaztapena desaktibatzeko edo protokoloak aldatzeko arrazoia. Sartu ataka instalatutako bezeroak espero duen tokian, eta bezero horrek halako eremurik ez badu, erantzuna onartutako beste bezero bat da, ez asmatutako irtenbide bat.

Zerbitzariak bi ataka ditu, eta biek bat etorri behar dute

IKE UDP 500en hasten da, eta NAT bideak normalean IKE eta kapsulatutako ESP UDP 4500era eramaten ditu. strongSwanen ezarpen bereiziak dira, beraz ataka pertsonalizatu bakarrera eramandako zerbitzariak bietan balio bera ezarri behar du:

plugins {
  socket-default {
    port = 4443
    port_nat_t = 4443
  }
}

Bi eginkizunetarako ataka bakarra denean, daemonak IKE ESP-in-UDPtik bereizi behar du socket berean, eta hori IKE mezua aurretik doan lau byteko ESP ez den markatzailearen bidez egiten du. Horregatik bezeroak ezin du ataka pertsonalizatuan negoziatu eta gero isilean 4500ean jarraitu, eta horregatik “besterik gabe aldatu ataka” esaldiak markaketa-baldintza bat ezkutatzen du.

Birbidaltzea ez da entzule bat

4443 IKE entzule arrunt batera birbidaltzea ia arrakastatsua dirudien hutsegite-modua da. Lehenengo trukea iristen da, zerbitzariak erantzuten du, eta orduan konexioak eten egiten du edo gakoak berritzen ditu ezer ezertara, erantzuna beste ataka batetik irteten delako eta geroagoko trafiko kapsulatuak ez duelako inoiz bat egiten bi muturrek sortutako egoerarekin. Helburuko ataka entzulea mugitu gabe berridazten duen arauak zehazki erdi-irekita dagoen emaitza hau ematen du.

Bideak UDP ere muturretik muturrera baimendu behar du. TCP 443 hotel edo operadore sare batetik pasatzeak ez du ezer esaten UDP ataka bateko IKEv2ri buruz, zenbakia bera bada ere. TCP 443 soilik baimenduta dagoenean, UDP ataka pertsonalizatuak ez du IKEv2 HTTPS bihurtzen, eta erantzun egokia beste sarbide-bide bat izan daiteke, beste ataka-esperimentu bat gehiago izan beharrean.

Bereizi hiru faseak probatzean

Grabatu zerbitzarian bezeroa behin saiatzen den bitartean. Inoiz iristen ez den eskaera muturreko edo suebakiko kontua da; erantzunik gabe iristen den eskaera entzule edo politikaren kontua da; isiltasunak jarraitzen dion erantzuna markaketa edo nortasunaren kontua da.

tcpdump -ni eth0 -vv udp port 4443

Gero irakurri bezeroaren mezua, ez haren erakusle biribila. Proposamen-erroreak algoritmoak bat ez datozela esan nahi du, autentifikazio-hutsegiteak nortasunak edo ziurtagiriak bat ez datozela esan nahi du, eta erantzunik gabeko berbidalketa errepikatuek ataka horretan ezerk erantzuten ez duela esan nahi dute. Probatu fase bat aldi berean eta aldatu eremu bat saiakeren artean; strongSwanen NAT bideari buruzko dokumentazioak grabaketak erakusten dizkizun markatzailea eta atakaren portaera deskribatzen ditu.

Erlazionatutako artikuluak