Vai ISP bloķē UDP, vai vaina ir lietotnē tunelī?

Kāds ziņo, ka VPN „bloķē UDP“, un šī frāze slēpj divus pilnīgi atšķirīgus apgalvojumus. Viens ir par transportu, ko redz piekļuves tīkls, otrs — par lietotnes paketēm pēc tam, kad tās tunelī ir atšifrētas. Šifrētu tuneli var filtrēt no ārpuses bez jebkādas atslēgas, un iekšēja UDP lietotne var neizdoties tādu iemeslu dēļ, kuriem ar filtrēšanu nav nekāda sakara. Pirms pierādījumu vākšanas izlemiet, kuru apgalvojumu pārbaudāt.

Divas galvenes, viens vārds

IPsec izvietojumā ar NAT-traversal ārējā pakete ir UDP, adresēta starp diviem VPN galapunktiem, parasti uz porta 4500. Tās iekšienē šifrētā lietderīgā slodze nes visu, ko tunelis pārsūta, un tas pats par sevi var būt TCP vai UDP. Tāpēc vārds UDP parādās divreiz, ar atšķirīgu nozīmi un atšķirīgu redzamību.

Starptīkls redz ārējo galveni un neko no iekšējās. Tas var atļaut, formēt vai nomest ārējo plūsmu, un tam nav nekas jāatšifrē. Tieši šī asimetrija ir viss iemesls, kāpēc abi apgalvojumi tiek sajaukti: viens un tas pats vārds apraksta gan to, ko filtrē tīkls, gan to, ko sūta lietotne. Kad vien fiksējat atradumu, blakus vārdam pierakstiet slāni, un apjukums gandrīz pazūd.

Iekšējā galvene kļūst redzama tikai uztverošajā galapunktā, pēc atšifrēšanas. No šī brīža pakete tiek pārsūtīta kā jebkura cita, ievērojot maršrutus, politiku un paša galapunkta filtrēšanu. Tie ir atsevišķi lēmumi, ko pieņem dažādas ierīces.

Ko tīkls vēl joprojām var redzēt

Šifrēšana slēpj lietderīgo slodzi un iekšējo transporta galveni, nevis faktu, ka plūsma pastāv. Galapunktu adreses, porti, pakešu izmēri un laiks paliek redzami, un ar to pietiek, lai heiristiski klasificētu satiksmi vai bloķētu konkrētu galamērķi.

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

Pirmais ieraksts rāda ārējo plūsmu fiziskajā saskarnē, bet otrais — iekšējo plūsmu tuneļa saskarnē. Abu palaišana vienlaikus tieši atbild uz jautājumu: ja ārējā plūsma pastāv, bet iekšējā ne, lietotne tunelī neko nav nosūtījusi. Ja pastāv abas un nekas neatgriežas, problēma ir aiz tuneļa, galamērķī vai atgriešanās ceļā.

RFC 3948 definē ārējo UDP iekapsulēšanu, un ESP specifikācija definē aizsargāto izkārtojumu tajā. Neviens no abiem dokumentiem nesola, ka piekļuves tīkls laidīs cauri ārējo plūsmu, tāpēc pirms jebkādas teorijas par iekšējo ir vērts veikt sasniedzamības pārbaudi ārējai kortežai. Bloķēta ārējā korteža rada tuneli, kas nekad neizveidojas, nevis tuneli, kas izveidojas un pēc tam zaudē vienu lietotni.

Kāpēc viena UDP lietotne neizdodas strādājošā tunelī

Tunelim, kas pārsūta tīmekļa lietotni, bet ne UDP lietotni, ir vairāki ticami skaidrojumi, un ISP veiktā iekšējā protokola filtrēšana nav pirmais. Visbiežāk tā ir pārklājums: abas lietotnes neiekļūst vienā tunelī, jo trūkst maršruta uz UDP galamērķi vai klienta sadalītā tuneļa noteikumi to izslēdz.

Otrais ir galapunkts. VPN serveris, kas atļauj protokolu sarakstu, galamērķa ugunsmūris vai pakalpojums, kas nekad neklausās paredzētajā portā, visi radīs taimautu, kas izskatās identiski tīkla bloķēšanai.

Trešais ir paketes izmērs. UDP lietotnes bieži sūta lielākas datagrammas nekā tīmekļa pieprasījums, un iekapsulēšana samazina izmantojamo MTU, tāpēc pēc veiksmīgas rokasspiediena var iestāties klusums pirmajā pilnā izmēra lietderīgajā slodzē. Šo modeli ir viegli nepareizi nolasīt kā bloķēšanu, jo mazās paketes iziet, bet lielās pazūd. Ātra MTU pārbaude to atrisina mazāk nekā minūtē, un atbilde parasti ir mazāka lietderīgā slodze vai labots MSS, nevis tīkla filtrs.

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

Pirmā komanda pārbauda, vai liela pakete pārvar ceļu ar izslēgtu fragmentēšanu, kas ātri atklāj MTU problēmu. Otrā sūta mazu, ierobežotu UDP plūsmu un ziņo par zudumiem un džiteru. Plūsma, kas sākas un pēc tam apstājas, norāda uz izmēru, nevis uz bloķēšanu.

Ziņojiet par slāni, nevis par protokolu

Pierakstiet atradumu vienā no trim formām: ārējā piegāde neizdevās, iekšējā pārsūtīšana neizdevās vai lietotne neizdevās. Katram ir cits īpašnieks, un to sajaukšana nosūta biļeti nepareizajai komandai.

Vietējā porta maiņa nevar izveidot atbilstošu klausītāju otrā galā, tāpēc klienta puses apietais risinājums, kas šķietami palīdz, parasti ir pierādījums tam, ka sākotnējais galamērķis bija nepareizs. Tāpat nodrošinātais alternatīvais profils pierāda kaut ko par sasniedzamību un neko par to, vai lietotne ir pareizi konfigurēta.

Turiet secinājumu atsevišķi no novērojuma. Satiksmes analīze var norādīt, kas ir plūsma, to neatšifrējot, un tas ir noderīgs atradums, taču tas nav tas pats apgalvojums kā iekšējās galvenes lasīšana. Norādiet, kurš no tiem jums patiešām ir.