Ping caur VPN: kāpēc atbalss atbildes noteikumi netrāpa atgriešanās ceļā
Atbalss atbilde maina ICMP tipu, nevis pakalpojuma portu. Izsekojiet iekšējo paketi caur pāradresāciju, NAT un stāvokļa filtru, pirms atverat portus.
Sūtiet ping uz resursdatoru caur VPN, un pieprasījums iziet ar vienu ICMP tipu un atgriežas ar citu, un ar to pietiek, lai sajauktu jebkuru noteikumu, kas rakstīts portu izteiksmē. Atbalss apmaiņā nav galamērķa pakalpojuma porta, ko pārkopēt atgriešanās noteikumā, un filtrs, kas gaida simetriju, izmetīs atbildi, kamēr pieprasījums pārvietojas bez šķēršļiem. Labojums sākas ar paketes lasīšanu tādu, kāda tā patiešām ir, un pēc tam ar lēmumu, kura ceļa robeža pieņem lēmumu. Parasti strādā divi slāņi, bet trešais klusi izmet atbildi. Turpmākās sadaļas tos atdala tādā secībā, kādā pakete tos satiek.
Pakete maina tipu, nevis portu
Atbalss pieprasījums ir ICMP 8 tips, 0 kods, un tas nes identifikatoru un kārtas numuru. Atbilde ir 0 tips, 0 kods, ar to pašu identifikatoru un kārtu, un IP gali ir samainīti. Šos laukus definē RFC 792, un tieši identifikators ļauj sūtītājam saskaņot atbildes ar saviem pieprasījumiem.
Tas, kā trūkst, ir tikpat svarīgi: nav TCP vai UDP galvenes, tāpēc nav porta, ko atļaut. Noteikums, kas atbalss atbildei nosauc portu, apraksta paketi, kāda nekad nepastāvēs. Šī ir visbiežākā kļūda VPN ping biļetēs. Noteikums izskatās konkrēts, neattiecas uz neko un atstāj kļūmi tieši tur, kur tā bija.
Paketi izšķir trīs konteksti
Ja ping mērķē uz resursdatoru tālajā LAN, pieprasījums jāpārsūta vārtejai. Ja tas mērķē uz adresi, kas pieder pašai vārtejai, tas beidzas vietējā ievades ceļā. Ja ping uzsāk pati vārteja, pakete sākas tās pašas izvades ceļā un nemaz nešķērso pāradresācijas lēmumu.
Šiem trim kontekstiem ir atšķirīgas noteikumu ķēdes un atšķirīgi skaitītāji, un tieši to uzskatīšana par vienu ir iemesls, kāpēc „ugunsmūris atļauj ICMP“ tomēr var dot neveiksmīgu ping. Ārējais tunelis ir ceturtais konteksts: VPN klausītāja atļaušana automātiski neatļauj atkapsulēto iekšējo pieprasījumu, un iekšēja atļauja neko nepasaka par to, vai ārējais tunelis darbojas.
Stāvokļa un bezstāvokļa filtri apstrādā atbildi atšķirīgi
Stāvokļa ugunsmūris, kas redzēja pieprasījumu izejam, var saistīt atbildi ar šo plūsmu un ielaist to bez otra noteikuma. Bezstāvokļa filtram šādas atmiņas nav, tāpēc atgriešanās virzienam vajag savu skaidru atļauju, ar samainītu avotu un galamērķi.
Pirms kaut ko rakstīt, pārbaudiet, kuru modeli produkts patiešām īsteno. Atbalss pieprasījuma noteikums ne vienmēr aptver atbalss atbildi, un produkts, kas izseko ICMP vaicājumus, tomēr var piemērot citu politiku atbildēm, kas pienāk citā saskarnē.
Ierobežojiet to, ko atļaujat. Atļaut katru atbalss atbildi no jebkurienes nav tas pats, kas pabeigt stāvokļa saistījumu, un tipa numurs neautentificē sūtītāju.
Tulkošana maina arī identifikatoru
Ja avota tulkošana ir tīša, tālā gala kortežs neatbilst tam, ko nosūtīja klients. NAT var iztulkot ICMP vaicājuma identifikatoru kopā ar adresēm, tāpēc uzstāšana, ka abās pusēs jāparādās tam pašam numuram, rada viltus neatbilstību.
Tā vietā saistiet ar kartējumu, ko ziņo tulkotājs. Tulkotājs, kas pārraksta identifikatoru, nesaglabās numuru, ko ierakstīja jūsu klients, tāpēc par identitāti uzskatiet kartējumu, nevis numuru. Pēc tam izsekojiet vienu atpazīstamu pieprasījumu pa ceļu: apstipriniet, ka tas sasniedz galamērķi ar gaidīto avotu, apstipriniet, ka galamērķis izsūtīja atbildi, izsekojiet šīs atbildes maršrutu atpakaļ, un apstipriniet, ka klients to saņēma, nevis vienkārši vērojāt, kā aug vārtejas skaitītājs.
Nesapludiniet ICMP kļūdas atbalss politikā
Ziņojums „nepieciešama sadalīšana“, ko izmanto ceļa MTU atklāšana, nav atbalss atbilde, un tā lietderīgā slodze citē paketi, kas to izraisīja. Atļauja tikai atbalsij, kas klusi izmet šīs kļūdas, pārvērš izmēra problēmu iekārtā savienojumā, un tas ir pretējs lietderībai.
Tāda pati piesardzība attiecas uz adrešu saimēm. ICMPv6 izmanto citus ziņojumu tipus un nes būtiskas funkcijas, kuru IPv4 nav, tāpēc šo numuru kopēšana IPv6 noteikumā ir vienkārši kļūda.
Kad atbalss apmaiņa darbojas, pārbaudiet īsto lietojumprogrammu atsevišķi. Veiksmīgs ping pierāda viena protokola ceļu šurp un atpakaļ vienā izmērā uz vienu galamērķi, un tā nav licence pieņemt, ka HTTPS, SMB vai jebkura cita plūsma ir atļauta.