IKEv2 käyttää UDP-portteja 500 ja 4500: kumpi kuljettaa tiedot?
Ensimmäinen vaihto ja tiedot kuljettava polku eivät ole sama virtaus. Tarkista molemmat portit ja muista, että natiivi ESP on protokollanumero, ei portti.
UDP 500:n avaaminen palomuurissa saa tunnelin neuvottelemaan, ja sen jälkeen yhteys lakkaa välittämästä liikennettä. Porttiluettelo oli puutteellinen, ei väärä. IKEv2 alkaa yhdestä socketista ja jatkuu monissa todellisissa käyttöönotoissa toisessa, kun taas hyötykuorma ei välttämättä ole portti lainkaan. Vaiheiden lukeminen järjestyksessä selittää, mikä sääntö puuttuu.
Kaksi porttia, kaksi tehtävää
IKEv2 alkaa avainten vaihdolla UDP 500:ssa, jossa osapuolet todentavat itsensä ja muodostavat tunnelille tietoturvayhteyden. Seuraava datapolku on eri asia: se voi olla natiivi ESP, joka on IP-protokollanumero eikä portti, tai UDP:hen kapseloitu liikenne portissa 4500. Näiden erottaminen palomuurikatselmuksessa on ero neuvottelevan ja toimivan tunnelin välillä. Yksi socket kuljettaa ohjausta ja toinen hyötykuormaa.
Siksi sääntö, joka sallii vain portin 500, tuottaa koko protokollaperheen hämmentävimmän oireen: neuvottelu onnistuu, eikä mitään hyödyllistä seuraa. Tila näyttää vastapuolen, loki näyttää muodostetun IKE SA:n, ja sovellus silti aikakatkaistaan. Puuttuva lupa kuuluu eri virtaukseen kuin se, joka juuri onnistui.
Miksi 4500 ylipäätään on olemassa
Monet NAT-laitteet eivät voi välittää muuta protokollaa kuin TCP tai UDP, ja jotkin kirjoittavat osoitteita uudelleen tavalla, joka rikkoo ESP:n eheystarkistuksen. ESP:n kapselointi UDP:hen ratkaisee molemmat ongelmat, mutta vaatii ylimääräisen otsikon ja toisen sallittavan portin. Juuri tämä kapselointi on syy siihen, miksi toinen portti on ylipäätään olemassa.
Kun NAT havaitaan, myös IKE siirtyy porttiin 4500, jotta kaikki liikenne jakaa yhden polun kääntäjän läpi. Neljän tavun merkki, joka ei ole ESP, erottaa ohjausviestit datasta kyseisessä socketissa. Siirtymä on protokollan päätös, ei ylläpitäjän mieltymys.
Missä lähdeportti muuttuu
Kääntäjä voi kirjoittaa asiakkaan lähdeportin uudelleen, joten palvelimella näkyvä monikko ei vastaa asiakkaan monikkoa. Katso jokaisen NAT-hypyn molemmat puolet ennen kuin päättelet, että sääntöä jätetään noudattamatta. Pelkästään asiakkaassa tehty vianetsintä voi tuottaa säännön, joka näyttää oikealta ja silti epäonnistuu.
MOBIKE-yhteensopivat toteutukset voivat siirtyä porttiin 4500 myös ilman havaittua NAT:ia, ja jotkin käyttöönotot pakottavat tämän polun tarkoituksella. Siksi 4500:n näkeminen on todiste päätöksestä, ei todiste kotireitittimestä.
Tarkista molemmat virtaukset joka rajalla
Käy läpi kolme rajaa: asiakasverkko, mahdollinen välipalomuuri ja palvelin. Jokainen tarvitsee ne virtaukset, jotka käyttöönotto dokumentoi, ei toista tapausta käsittelevän artikkelin virtauksia.
sudo swanctl --list-sas
sudo tcpdump -ni any 'udp port 500 or udp port 4500'
sudo iptables -S | grep -E '500|4500|esp'
ip xfrm state
Palomuuriluettelon ESP-rivi on protokollavastaavuus, joten porttisääntö ei koskaan kata sitä. Jos ylläpitäjä käyttää mukautettua porttia, noudata dokumentoitua kokoonpanoa molemmissa päissä, koska asiakas ei voi luoda kuuntelijaa palvelimelle valitsemalla tutun numeron.
Kirjaa, mihin neuvottelu pysähtyi ja asennettiinko alitietoturvayhteys, koska tämä pari erottaa estetyn polun todennus- tai käytäntövirheestä. Toista sitten testi palvelimen varmennus käytössä, koska tavoitettavuus ei ole todennusta. Tämä viimeinen vaihe erottaa sallitun portin luotetusta vastapuolesta.