Ping läbi VPN-i: miks kajavastuse reeglid jätavad tagasitee tabamata

Saatke ping läbi VPN-i ja päring väljub ühe ICMP-tüübiga ning naaseb teisega, millest piisab, et ajada segadusse iga portide kaudu kirjutatud reegel. Kajas vahetuses ei ole sihtkoha teenuseporti, mida tagasireeglisse kopeerida, ja sümmeetriat ootav filter viskab vastuse kõrvale, samal ajal kui päring libiseb läbi. Parandus algab paketi lugemisest sellisena, nagu see tegelikult on, ja seejärel otsusest, milline teepiir otsuse teeb. Tavaliselt töötavad kaks kihti, samal ajal kui kolmas viskab vastuse vaikselt kõrvale. Allolevad jaotised eraldavad need järjekorras, milles pakett neid kohtab.

Pakett muudab tüüpi, mitte porti

Kajapäring on ICMP tüüp 8, kood 0, ja kannab identifikaatorit ning järjekorranumbrit. Vastus on tüüp 0, kood 0, sama identifikaatori ja järjekorranumbriga ning IP-otspunktid on vahetatud. RFC 792 määratleb need väljad ja just identifikaator võimaldab saatjal vastuseid oma päringutega siduda.

Puuduv osa on sama oluline: TCP ega UDP päist ei ole, seega ei ole ka porti, mida lubada. Reegel, mis nimetab kajavastuse jaoks porti, kirjeldab paketti, mida kunagi ei teki. See on kõige tavalisem viga VPN-i pingi piletites. Reegel näib konkreetne, ei kehti millelegi ja jätab tõrke täpselt sinna, kus see oli.

Paketi üle otsustavad kolm konteksti

Kui ping on suunatud kaugema LAN-i hostile, peab lüüs päringu edastama. Kui see on suunatud aadressile, mis kuulub lüüsile endale, lõpeb see kohalikus sisendteel. Kui lüüs ise pingi algatab, algab pakett tema enda väljundteel ega läbi edastusotsust üldse.

Need kolm konteksti on erinevate reegliahelate ja erinevate lugejatega ning nende üheks pidamine on põhjus, miks „tulemüür lubab ICMP-d“ võib ikkagi anda ebaõnnestunud pingi. Välimine tunnel on neljas kontekst: VPN-i kuulaja lubamine ei luba automaatselt dekapsuleeritud sisemist päringut ja sisemine luba ei ütle midagi selle kohta, kas välimine tunnel on üleval.

Olekupõhised ja olekuta filtrid käsitlevad vastust erinevalt

Olekupõhine tulemüür, mis nägi päringut väljumas, saab vastuse selle vooga siduda ja selle teise reeglita läbi lasta. Olekuta filtril sellist mälu ei ole, seega vajab tagasisuund oma selgesõnalist luba, allikas ja sihtkoht vahetatud.

Kontrollige, millist mudelit toode tegelikult rakendab, enne kui midagi kirjutate. Kajapäringu reegel ei pruugi kajavastust katta ja ICMP-päringuid jälgiv toode võib teisele liidesele saabuvate vastuste suhtes rakendada teistsugust poliitikat.

Piirake seda, mida lubate. Kõigi kajavastuste lubamine kõikjalt ei ole sama mis olekupõhise seose lõpuleviimine ja tüübinumber ei autenti saatjat.

Tõlkimine muudab ka identifikaatorit

Kui lähtekoha tõlkimine on tahtlik, ei vasta kaugema otsa korteež sellele, mille klient saatis. NAT võib tõlkida ICMP-päringu identifikaatori koos aadressidega, seega nõudmine, et sama number esineks mõlemal pool, tekitab vale mittevastavuse.

Korreleerige hoopis tõlkija teatatud vastendust. Identifikaatorit ümber kirjutav tõlkija ei säilita numbrit, mille teie klient logis, seega käsitlege identiteedina vastendust, mitte numbrit. Seejärel jälgige üht tuvastatavat päringut mööda teed: kinnitage, et see jõuab sihtkohta oodatud allikaga, kinnitage, et sihtkoht saatis vastuse, jälgige selle vastuse marsruuti tagasi, ja kinnitage, et klient selle kätte sai, mitte ainult ei vaadanud, kuidas lüüsi lugeja kasvab.

Ärge sulandage ICMP-vigu kajapoliitikasse

Teekonna MTU avastamise kasutatav teade „vaja tükeldada“ ei ole kajavastus ja selle kasulik koormus tsiteerib paketti, mis selle esile kutsus. Ainult kaja luba, mis need vead vaikselt kõrvale heidab, muudab suurusprobleemi rippuvaks ühenduseks, mis on kasulikkuse vastand.

Sama ettevaatlikkus kehtib aadressiperekondade kohta. ICMPv6 kasutab teistsuguseid sõnumitüüpe ja kannab olulisi funktsioone, mida IPv4-l ei ole, seega nende numbrite kopeerimine IPv6 reeglisse on lihtsalt vale.

Kui kaja vahetus töötab, testige tegelikku rakendust eraldi. Õnnestunud ping tõestab ühe protokolli edasi-tagasi teekonda ühes suuruses ühte sihtkohta ja see ei ole litsents eeldada, et HTTPS, SMB või mis tahes muu voog on lubatud.