Miksi DNS-vastaus epäonnistuu tilattomalla VPN-reunan palomuurilla

Tunneli on pystyssä, asiakkaat tavoittavat VPN-isännän, eikä isäntä pysty selvittämään mitään. Sen omat lähtevät kyselyt jättävät rajapinnan puhtaasti, joten vika on paluutiellä: ylemmässä reunassa, joka suodattaa saapuvaa liikennettä muistamatta lainkaan, mitä isäntä juuri lähetti. Tunnelin portin salliminen ei kuvaa tuota vaihtoa ollenkaan. DNS-kyselyn vastaus on erillinen virtaus, ja jos reuna on tilaton, mikään ei ole antanut sille lupaa palata.

Kaksi vaihtoa eivät ole sama vaihto

Kirjoita monikot ylös, niin virhe käy ilmeiseksi. Kyselyn kohdeportista tulee vastauksen lähdeportti, mikä on päinvastoin kuin useimmat kuvittelevat lisätessään saapuvan säännön portille 53:

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

Saapuva sääntö, joka vaatii kohdeportin 53, kuvaa liikennettä, joka on osoitettu isännällä toimivalle DNS-kuuntelijalle, ja se on täysin eri palvelu. Ne osoitteet ovat dokumentaation esimerkkejä, ja lähdeportin valitsee asiakas kyselykohtaisesti, joten se ei ole arvo, jonka voi kopioida sääntöön ja odottaa sen jatkavan toimintaansa.

Tilaton reuna vastaan tilallinen isännän palomuuri

Tilaton reunasuodatin arvioi jokaisen saapuvan paketin sääntöluetteloaan vasten ilman yhteyksien taulukkoa takanaan. Lähtevä kysely, joka onnistui lähtemään, ei luo mitään lupaa saapuvalle vastaukselleen, koska laitteella ei ole merkintää siitä, että kysely olisi koskaan tapahtunut. Tilallinen isännän palomuuri on päinvastainen: sen yhteyksien seuranta tunnistaa sallitun vaihdon paluuliikenteen ja päästää sen läpi ilman vastauksen omaa sääntöä. Molemmat rajat ovat olemassa tyypillisellä polulla, ja molempien on sallittava aiottu paketti.

Vertailu on tärkeää, koska kaksi laitetta epäonnistuu eri tavoin. Tilallinen palomuuri, joka hylkää vastauksen, kirjaa pudotuksen; tilaton reuna hylkää sen äänettömästi, minkä vuoksi isäntä yksinkertaisesti aikakatkaisee.

Rakenna lupa protokollan ympärille, älä porttinumeron

Rajaa sääntö todellisiin resolverin osoitteisiin, kohdeisäntään ja tuotteen tukemaan vastaanottoportin käytäntöön. Pidä mielessä myös DNS:n TCP-polku, sillä suuri vastaus tai katkaisun varapolku siirtää vaihdon TCP:lle, eikä vain UDP:tä koskeva sääntö kata sitä. Jos reuna tukee tilallista tarkastusta määritetylle virtaukselle, suosi sitä käsin kirjoitettuun vastaussääntöön verrattuna, sillä tilallinen polku seuraa automaattisesti asiakkaan valitsemia portteja.

Vahvista sitten, mikä polun tuote todella suodattaa liikennettä. Dokumentoitu IPv4-reunan laajuus ei vahvista IPv6-käytäntöä, eikä palveluntarjoajan sisäinen liikenne ehkä koskaan kulje saman suodattimen läpi.

Miksi minkä tahansa lähdeportin 53 salliminen ei ole korjaus

Sääntö, joka hyväksyy kaiken, mikä väittää olevansa lähdeportti 53, on sääntö, joka hyväksyy sen, mitä lähettäjä kirjoittaa otsikkokenttään. Porttinumero ei todista lähettäjän henkilöllisyyttä eikä todista, että hyötykuorma on kelvollinen vastaus, joten sääntö laajentaa isännän altistusta tekemättä selvityksestä luotettavampaa. Säilytä lähderajoitukset ja asiakkaan omat vastaustarkistukset, mukaan lukien lähdeportin satunnaistaminen, sen sijaan että kytkisit ne pois pääsyluettelon yksinkertaistamiseksi.

Jos resolver on palvelu, jota hallitset, rajoittaminen sen osoitteisiin riittää. Jos se on julkinen resolver, rajaa osoitteisiin, jotka olet hyväksynyt, ja kirjaa ne säännön kommenttiin.

Tarkista oikealla rajalla, oikeaan suuntaan

Kaappaa isännällä ja reunassa sama kysely ja vertaa monikkoja pakettimäärien sijaan. Kysely, joka näkyy molemmilla puolilla ilman isännän puolella näkyvää vastausta, viittaa saapuvaan suodattimeen; vain isännän puolella näkyvä kysely viittaa reititykseen tai itse resolveriin. Toista TCP-kyselyllä, jos sinulla on lupa vain UDP:lle, sillä juuri se on aukko, jota ensimmäinen testi ei näe.

Tämän korjaaminen täydentää DNS-vaihdon, jota isäntä todella tarvitsee. Se ei tee isännästä julkista resolveria, ei valtuuta edelleenlähetettyjä VPN-virtauksia eikä todista, että DNS oli jonkin asiattoman tunneliongelman syy.