Estääkö operaattori UDP:n vai onko syy tunnelin sisäinen sovellus?

Joku raportoi, että VPN „estää UDP:n“, ja lause kätkee kaksi täysin erilaista väitettä. Toinen koskee kuljetusta, jonka liityntäverkko näkee, toinen sovelluksen paketteja sen jälkeen kun ne on purettu salauksesta tunnelin sisällä. Salattu tunneli voidaan suodattaa ulkopuolelta ilman mitään avainta, ja sisäinen UDP-sovellus voi epäonnistua syistä, joilla ei ole mitään tekemistä suodatuksen kanssa. Päätä, kumpaa väitettä testaat, ennen kuin keräät todisteita.

Kaksi otsikkoa, yksi sana

NAT-traversal-IPsec-käyttöönotossa ulompi paketti on UDP, osoitettu kahden VPN-päätepisteen välille, tyypillisesti porttiin 4500. Sen sisällä salattu hyötykuorma kuljettaa kaiken, mitä tunneli välittää, ja se voi itsessään olla TCP tai UDP. Sana UDP esiintyy siis kahdesti eri merkityksessä ja eri näkyvyydellä.

Väliverkko näkee ulomman otsikon eikä mitään sisemmästä. Se voi sallia, muotoilla tai pudottaa ulomman virtauksen, eikä sen tarvitse purkaa mitään salausta tehdäkseen niin. Tämä epäsymmetria on koko syy siihen, että kaksi väitettä sekoittuvat: sama sana kuvaa sekä sitä, mitä verkko suodattaa, että sitä, mitä sovellus lähettää. Kirjoita kerros sanan viereen aina kun kirjaat havainnon, ja sekaannus suurelta osin katoaa.

Sisempi otsikko tulee näkyväksi vasta vastaanottavassa päätepisteessä salauksen purkamisen jälkeen. Siitä pisteestä paketti välitetään kuin mikä tahansa muu, reittien, käytännön ja päätepisteen oman suodatuksen alaisena. Ne ovat erillisiä päätöksiä, jotka eri laitteet tekevät.

Mitä verkko voi silti nähdä

Salaus kätkee hyötykuorman ja sisemmän kuljetusotsikon, ei sitä tosiasiaa, että virtaus on olemassa. Päätepisteiden osoitteet, portit, pakettikoot ja ajoitus pysyvät näkyvinä, ja se riittää liikenteen heuristiseen luokitteluun tai tietyn kohteen estämiseen.

sudo tcpdump -ni eth0 'udp port 4500'
sudo tcpdump -ni tun0 'udp port 5201'

Ensimmäinen kaappaus näyttää ulomman virtauksen fyysisellä rajapinnalla ja toinen sisemmän virtauksen tunnelin rajapinnalla. Molempien ajaminen yhtä aikaa vastaa kysymykseen suoraan: jos ulompi virtaus on olemassa eikä sisempää ole, sovellus ei koskaan lähettänyt mitään tunneliin. Jos molemmat ovat olemassa eikä mitään tule takaisin, ongelma on tunnelin tuolla puolen, kohteessa tai paluureitillä.

RFC 3948 määrittelee ulomman UDP-kapseloinnin, ja ESP-määrittely määrittelee sen sisällä olevan suojatun asettelun. Kumpikaan asiakirja ei lupaa, että liityntäverkko päästää ulomman virtauksen läpi, minkä vuoksi ulompaan monikkoon kannattaa ajaa tavoitettavuustesti ennen mitään sisempää koskevaa teoriaa. Estetty ulompi monikko tuottaa tunnelin, joka ei koskaan muodostu, ei tunnelia, joka muodostuu ja menettää sitten yhden sovelluksen.

Miksi yksi UDP-sovellus epäonnistuu toimivan tunnelin sisällä

Tunnelilla, joka kuljettaa verkkosovellusta mutta ei UDP-sovellusta, on useita uskottavia selityksiä, eikä operaattorin sisemmän protokollan suodatus ole ensimmäinen. Yleisin on kattavuus: kaksi sovellusta eivät molemmat päädy samaan tunneliin, koska reitti UDP-kohteeseen puuttuu tai asiakkaan jaetun tunnelin säännöt sulkevat sen pois.

Toinen on päätepiste. VPN-palvelin, joka sallii protokollaluettelon, kohteen palomuuri tai palvelu, joka ei koskaan kuuntele odotetussa portissa, tuottavat kaikki aikakatkaisun, joka näyttää täsmälleen verkon estolta.

Kolmas on pakettikoko. UDP-sovellukset lähettävät usein suurempia datagrammoja kuin verkkopyyntö, ja kapselointi pienentää käytettävissä olevaa MTU:ta, joten onnistunutta kättelyä voi seurata hiljaisuus ensimmäisellä täysikokoisella hyötykuormalla. Tämä kuvio on helppo lukea väärin estoksi, koska pienet paketit menevät läpi ja suuret katoavat. Nopea MTU-koe ratkaisee asian alle minuutissa, ja vastaus on yleensä pienempi hyötykuorma tai korjattu MSS, ei verkkosuodatin.

ping -M do -s 1400 -c 2 10.60.0.20
iperf3 -u -c 10.60.0.20 -p 5201 -b 1M -t 5

Ensimmäinen komento testaa, selviääkö suuri paketti reitistä fragmentointi pois päältä, mikä paljastaa MTU-ongelman nopeasti. Toinen lähettää pienen, rajatun UDP-virtauksen ja raportoi häviöstä ja jitteristä. Virtaus, joka alkaa ja sitten pysähtyy, viittaa kokoon eikä estoon.

Raportoi kerros, ei protokolla

Kirjoita havainto jossakin kolmesta muodosta: ulompi toimitus epäonnistui, sisempi välitys epäonnistui tai sovellus epäonnistui. Jokaisella on eri omistaja, ja niiden sekoittaminen lähettää tiketin väärälle tiimille.

Paikallisen portin vaihtaminen ei voi luoda vastaavaa kuuntelijaa kauempaan päähän, joten asiakaspuolen kiertotie, joka näyttää auttavan, on yleensä todiste siitä, että alkuperäinen kohde oli väärä. Samoin toimitettu vaihtoehtoinen profiili todistaa jotain tavoitettavuudesta eikä mitään siitä, onko sovellus määritetty oikein.

Pidä päättely erillään havainnosta. Liikenneanalyysi voi vihjata, mikä virtaus on, purkamatta sitä, ja se on hyödyllinen havainto, mutta se ei ole sama väite kuin sisemmän otsikon lukeminen. Kerro, kumpi sinulla todella on.