Zakaj odgovor DNS spodleti na brezstanjskem robnem požarnem zidu VPN

Predor je vzpostavljen, odjemalci dosežejo gostitelja VPN, gostitelj pa ne more razrešiti ničesar. Njegove lastne odhodne poizvedbe čisto zapustijo vmesnik, zato je napaka na povratni poti: na nadrejenem robu, ki filtrira dohodni promet, ne da bi si zapomnil, kaj je gostitelj pravkar poslal. Dovoljenje vrat predora te izmenjave sploh ne opisuje. Odgovor na poizvedbo DNS je ločen tok, in če je rob brezstanjski, mu nič ni dalo dovoljenja za vrnitev.

Izmenjavi nista ista izmenjava

Zapišite terkice in napaka postane očitna. Ciljna vrata zahteve postanejo izvorna vrata odgovora, kar je nasprotno od tega, kar si večina predstavlja, ko doda dohodno pravilo za vrata 53:

query:  203.0.113.10:53018 -> 198.51.100.53:53
reply:  198.51.100.53:53 -> 203.0.113.10:53018

Dohodno pravilo, ki zahteva ciljna vrata 53, opisuje promet, naslovljen na poslušalca DNS, ki teče na gostitelju, in to je povsem druga storitev. Ti naslovi so dokumentacijski primeri, izvorna vrata pa odjemalec izbere za vsako poizvedbo, zato to ni vrednost, ki bi jo lahko kopirali v pravilo in pričakovali, da bo še naprej delovala.

Brezstanjski rob proti stanjskemu požarnemu zidu gostitelja

Brezstanjski robni filter ocenjuje vsak dohodni paket glede na svoj seznam pravil brez tabele povezav za seboj. Odhodna poizvedba, ki je uspešno odšla, ne ustvari nobenega dovoljenja za svoj dohodni odgovor, ker naprava nima evidence, da je do poizvedbe sploh prišlo. Stanjski požarni zid gostitelja je nasprotje: njegovo sledenje povezavam prepozna povratni promet dovoljene izmenjave in ga spusti brez pravila za odgovor. Obe meji obstajata na tipični poti, in obe morata dovoliti predvideni paket.

Primerjava je pomembna, ker obe napravi odpovedujeta različno. Stanjski požarni zid, ki odgovor zavrne, zabeleži zavrženje; brezstanjski rob ga zavrne tiho, zato gostitelj preprosto pride do časovne omejitve.

Dovoljenje gradite okoli protokola, ne številke vrat

Omejite pravilo na dejanske naslove razreševalnika, ciljnega gostitelja in politiko sprejemnih vrat, ki jo izdelek podpira. Upoštevajte tudi pot TCP za DNS, ker velik odgovor ali odmik zaradi okrajšave premakne izmenjavo na TCP in pravilo samo za UDP je ne bo pokrilo. Če rob podpira stanjski pregled za določen tok, mu dajte prednost pred ročno napisanim pravilom za odgovor, ker stanjska pot samodejno sledi vratom, ki jih izbere odjemalec.

Nato potrdite, kateri izdelek na poti promet zares filtrira. Dokumentiran obseg roba IPv4 ne vzpostavi politike IPv6, promet znotraj ponudnika pa morda nikoli ne preide istega filtra.

Zakaj dovoljenje kateregakoli izvornih vrat 53 ni popravek

Pravilo, ki sprejme vse, kar trdi, da ima izvorna vrata 53, je pravilo, ki sprejme tisto, kar pošiljatelj napiše v polje glave. Številka vrat ne overi pošiljatelja in ne dokaže, da je koristna obremenitev veljaven odgovor, zato pravilo razširi izpostavljenost gostitelja, ne da bi razreševanje naredilo zanesljivejše. Ohranite omejitve vira in ohranite lastne preverbe odgovora pri odjemalcu, vključno z naključnostjo izvornih vrat, namesto da bi jih izklopili zaradi poenostavitve seznama dostopa.

Če je razreševalnik storitev, ki jo upravljate, zadošča omejitev na njegove naslove. Če je javni razreševalnik, omejite na naslove, ki ste jih odobrili, in jih zapišite v komentar pravila.

Preverjajte na pravi meji, v pravi smeri

Zajemite na gostitelju in na robu isto poizvedbo ter primerjajte terkice, ne štetja paketov. Poizvedba, vidna na obeh straneh brez odgovora, vidnega na strani gostitelja, kaže na dohodni filter; poizvedba, vidna le na strani gostitelja, kaže na usmerjanje ali na sam razreševalnik. Ponovite s poizvedbo TCP, če imate dovoljenje le za UDP, ker to je vrzel, ki je prvi preizkus ne more videti.

Popravek tega dokonča izmenjavo DNS, ki jo gostitelj resnično potrebuje. Gostitelja ne spremeni v javni razreševalnik, ne dovoli posredovanih tokov VPN in ne dokaže, da je bil DNS vzrok kakšne nepovezane težave s predorom.