Ping VPN:n läpi: miksi kaikuvastauksen säännöt jäävät paluureitiltä

Pingaa isäntää VPN:n läpi, ja pyyntö lähtee yhtenä ICMP-tyyppinä ja palaa toisena, mikä riittää sekoittamaan minkä tahansa porteilla kirjoitetun säännön. Kaikuvaihdossa ei ole kohdepalveluporttia, jonka voisi kopioida paluusääntöön, ja symmetriaa odottava suodatin pudottaa vastauksen pyynnön liukuessa läpi esteettä. Korjaus alkaa lukemalla paketti sellaisena kuin se todella on ja päättämällä sitten, mikä raja reitillä tekee päätöksen. Yleensä kaksi kerrosta toimii, kun kolmas pudottaa vastauksen hiljaa. Seuraavat osiot erottavat ne siinä järjestyksessä, jossa paketti kohtaa ne.

Paketti vaihtaa tyyppiä, ei porttia

Kaikupyyntö on ICMP-tyyppi 8, koodi 0, ja se kuljettaa tunnistetta ja järjestysnumeroa. Vastaus on tyyppi 0, koodi 0, samalla tunnisteella ja järjestysnumerolla, ja IP-päätepisteet ovat vaihtuneet. RFC 792 määrittelee nämä kentät, ja juuri tunniste mahdollistaa lähettäjän vastausten sovittamisen omiin pyyntöihinsä.

Se, mikä puuttuu, on yhtä tärkeää: TCP- tai UDP-otsikkoa ei ole, joten porttia ei ole sallittavana. Sääntö, joka nimeää portin kaikuvastaukselle, kuvaa paketin, jota ei koskaan tule olemaan. Tämä on yleisin virhe VPN-ping-tiketeissä. Sääntö näyttää täsmälliseltä, ei sovellu mihinkään ja jättää vian täsmälleen sinne, missä se oli.

Kolme asiayhteyttä päättää paketista

Jos ping kohdistuu kauko-LANin isäntään, yhdyskäytävän on välitettävä pyyntö. Jos se kohdistuu osoitteeseen, joka kuuluu yhdyskäytävälle itselleen, se päättyy paikalliseen syöttöpolkuun. Jos yhdyskäytävä itse aloittaa pingin, paketti alkaa sen omasta lähtöpolusta eikä ylitä välityspäätöstä lainkaan.

Näillä kolmella asiayhteydellä on eri sääntöketjut ja eri laskurit, ja niiden pitäminen yhtenä on syy siihen, miksi „palomuuri sallii ICMP:n“ voi silti tuottaa epäonnistuneen pingin. Ulompi tunneli on neljäs asiayhteys: VPN-kuuntelijan salliminen ei automaattisesti salli purettua sisäpyyntöä, eikä sisäinen lupa kerro mitään siitä, onko ulompi tunneli pystyssä.

Tilalliset ja tilattomat suodattimet käsittelevät vastauksen eri tavoin

Tilallinen palomuuri, joka näki pyynnön lähtevän, voi liittää vastauksen siihen virtaan ja päästää sen läpi ilman toista sääntöä. Tilattomalla suodattimella ei ole sellaista muistia, joten paluusuunta tarvitsee oman nimenomaisen lupansa, lähteen ja kohteen vaihdettuina.

Tarkista, minkä mallin tuote todella toteuttaa, ennen kuin kirjoitat mitään. Kaikupyynnön sääntö ei välttämättä kata kaikuvastausta, ja ICMP-kyselyitä seuraava tuote voi silti soveltaa eri käytäntöä vastauksiin, jotka saapuvat toiselle liitännälle.

Rajaa se, minkä sallit. Kaikkien kaikuvastausten salliminen mistä tahansa ei ole sama kuin tilallisen liitoksen viimeistely, eikä tyyppinumero todista lähettäjän henkilöllisyyttä.

Käännös vaihtaa myös tunnisteen

Jos lähdekäännös on tarkoituksellinen, kauko pään monikko ei vastaa sitä, jonka asiakas lähetti. NAT voi kääntää ICMP-kyselyn tunnisteen yhdessä osoitteiden kanssa, joten vaatiminen, että sama numero näkyy molemmilla puolilla, tuottaa väärän ristiriidan.

Korreloi sen sijaan kääntäjän raportoimaa mappia. Kääntäjä, joka kirjoittaa tunnisteen uudelleen, ei säilytä numeroa, jonka asiakkaasi kirjasi, joten pidä mappia identiteettinä numeron sijaan. Seuraa sitten yhtä tunnistettavaa pyyntöä reittiä pitkin: varmista, että se saapuu kohteeseen odotetulla lähteellä, varmista, että kohde lähetti vastauksen, seuraa kyseisen vastauksen reitti takaisin, ja varmista, että asiakas vastaanotti sen sen sijaan, että vain katsoisit yhdyskäytävän laskurin nousevan.

Älä sisällytä ICMP-virheitä kaikukäytäntöön

Reitin MTU:n löydön käyttämä „pirstoutuminen tarvitaan“ -viesti ei ole kaikuvastaus, ja sen hyötykuorma lainaa paketin, joka sen laukaisi. Vain kaikua koskeva lupa, joka hiljaa hylkää nämä virheet, muuttaa kokoprobleeman roikkuvaksi yhteydeksi, mikä on hyödyllisyyden vastakohta.

Sama varovaisuus koskee osoiteperheitä. ICMPv6 käyttää eri viestityyppejä ja kuljettaa olennaisia toimintoja, joita IPv4:ssä ei ole, joten näiden numeroiden kopioiminen IPv6-sääntöön on yksinkertaisesti väärin.

Kun kaikuvaihto toimii, testaa varsinainen sovellus erikseen. Onnistunut ping todistaa yhden protokollan edestakaisen matkan yhdessä koossa yhteen kohteeseen, eikä se ole lupa olettaa, että HTTPS, SMB tai mikä tahansa muu virta on sallittu.