Miks DNS-vastus ebaõnnestub olekuta VPN-i serva tulemüüril

Tunnel on üleval, kliendid pääsevad VPN-hostini, kuid host ei suuda midagi lahendada. Selle enda väljuvad päringud lahkuvad liidesest puhtalt, seega viga on tagasiteel: ülemvooluses servas, mis filtreerib sissetulevat liiklust, mäletamata, mida host äsja saatis. Tunneli pordi lubamine ei kirjelda seda vahetust üldse. DNS-päringu vastus on eraldi voog ja kui serv on olekuta, ei ole miski andnud sellele luba naasta.

Kaks vahetust ei ole sama vahetus

Kirjutage ennikud üles ja viga muutub ilmseks. Päringu sihtport saab vastuse lähtepordiks, mis on vastupidine sellele, mida enamik inimesi ette kujutab, kui nad lisavad pordi 53 jaoks sissetuleva reegli:

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

Sissetulev reegel, mis nõuab sihtporti 53, kirjeldab liiklust, mis on adresseeritud hostil töötavale DNS-kuulajale, ja see on täiesti teine teenus. Need aadressid on dokumentatsiooni näited ja lähtepordi valib klient iga päringu jaoks, seega ei ole see väärtus, mille saaks reeglisse kopeerida ja loota, et see jätkab töötamist.

Olekuta serv versus olekuga hosti tulemüür

Olekuta servafilter hindab iga sissetulevat paketti oma reeglite loendi järgi, ilma et selle taga oleks ühenduste tabel. Edukalt väljunud päring ei loo oma sissetulevale vastusele mingit luba, sest seadmel ei ole ühtegi kirjet, et päring kunagi toimus. Olekuga hosti tulemüür on vastupidine: selle ühenduste jälgimine tunneb ära lubatud vahetuse tagasiliikluse ja laseb selle läbi ilma vastuse jaoks eraldi reeglita. Mõlemad piirid on tüüpilisel teel olemas, ja mõlemad peavad kavandatud paketi lubama.

Võrdlus on oluline, sest kaks seadet ebaõnnestuvad erinevalt. Olekuga tulemüür, mis vastuse keelab, logib mahajätmise; olekuta serv keelab selle vaikselt, mistõttu host lihtsalt aegub.

Ehitage luba protokolli, mitte pordinumbri ümber

Piirake reegel tegelike resolveri aadresside, sihthosti ja toote toetatava vastuvõtupordi poliitikaga. Pidage silmas ka DNS-i TCP-teed, sest suur vastus või kärpimise tagasilangus viib vahetuse TCP-le ja ainult UDP reegel ei kata seda. Kui serv toetab määratud voo jaoks olekuga kontrolli, eelistage seda käsitsi kirjutatud vastusereeglile, sest olekuga tee järgib automaatselt kliendi valitud porte.

Seejärel kinnitage, milline toode teel liiklust tegelikult filtreerib. Dokumenteeritud IPv4 serva ulatus ei kehtesta IPv6 poliitikat ja teenusepakkuja sisene liiklus ei pruugi kunagi samast filtrist läbi minna.

Miks mis tahes lähtepordi 53 lubamine ei ole parandus

Reegel, mis võtab vastu kõik, mis väidab endal olevat lähtepordi 53, on reegel, mis võtab vastu selle, mida saatja päiseväljale kirjutab. Pordinumber ei autenti saatjat ega tõesta, et kandevõime on kehtiv vastus, seega laiendab reegel hosti kokkupuudet ilma lahendamist usaldusväärsemaks muutmata. Säilitage allikapiirangud ja kliendi enda vastusekontrollid, sealhulgas lähtepordi juhuslikustamine, selle asemel et need ligipääsuloendi lihtsustamiseks välja lülitada.

Kui resolver on teenus, mida te kontrollite, piisab selle aadressidega piiramisest. Kui see on avalik resolver, piirake aadressidega, mille te heaks kiitsite, ja märkige need reegli kommentaari.

Kontrollige õigel piiril, õiges suunas

Jäädvustage hostis ja servas sama päring ning võrrelge ennikuid, mitte pakettide arve. Päring, mis on nähtav mõlemal pool ilma hosti poolel nähtava vastuseta, osutab sissetulevale filtrile; ainult hosti poolel nähtav päring osutab marsruutimisele või resolverile endale. Korrake TCP-päringuga, kui teil on luba ainult UDP jaoks, sest just see on tühik, mida esimene test näha ei suuda.

Selle parandamine lõpetab DNS-vahetuse, mida host tõesti vajab. See ei muuda hosti avalikuks resolveriks, ei volita edastatud VPN-i voogusid ega tõesta, et DNS oli mõne mitteseotud tunneliprobleemi põhjus.