Wêrom't it DNS-antwurd mislearret by in steatleaze VPN-randfirewall

De tunnel is omheech, kliïnten kinne de VPN-host berikke, en de host kin neat oplosse. Syn eigen útgeande fragen ferlitte de ynterface skjin, dus de flater sit op 'e weromweis: by in boppeste râne dy't ynkommend ferkear filteret sûnder ûnthâld fan wat de host krekt stjoerd hat. It tastien fan 'e tunnelpoart beskriuwt dy útwikseling hielendal net. It antwurd op in DNS-fraach is in aparte stream, en as de râne steatleas is, hat neat it tastien om werom te kommen.

De twa útwikselings binne net deselde útwikseling

Skriuw de tuplen op en de flater wurdt fanselssprekkend. De bestimmingspoart fan 'e fraach wurdt de boarneport fan it antwurd, wat it tsjinstelde is fan wat de measte minsken har foarstelle as se in ynkommende regel foar poart 53 tafoegje:

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

In ynkommende regel dy't bestimmingspoart 53 easket, beskriuwt ferkear rjochte op in DNS-harker dy't op 'e host draait, en dat is in hiel oare tsjinst. Dy adressen binne dokumintaasje-foarbylden, en de boarneport wurdt troch de kliïnt foar elke fraach keazen, dus it is gjin wearde dy't jo yn in regel kopiearje kinne en ferwachtsje dat it bliuwt wurkjen.

Steatleaze râne tsjin steatfolle host-firewall

In steatleas rânefilter beoardielet elk ynkommend pakket tsjin syn regellist sûnder in ferbiningstabel dêrefter. In útgeande fraach dy't suksesfol fuortgien is, makket gjin tastimming foar syn ynkommend antwurd, om't it apparaat gjin registraasje hat dat der ea in fraach west hat. In steatfolle host-firewall is it tsjinstelde: syn ferbiningstracing werkent it weromferkear fan in tastiene útwikseling en lit it troch sûnder in regel foar it antwurd. Beide grinzen besteane yn in typysk paad, en beide moatte it bedoelde pakket tastean.

De ferliking is fan belang om't de twa apparaten oars mislearje. In steatfolle firewall dy't it antwurd wegert, logt in drop; in steatleaze râne wegert it stil, en dêrom rint de host gewoan yn in time-out.

Bou de tastimming om it protokol, net om in poartnûmer

Behein de regel ta de echte resolveradressen, de bestimmingshost en it ûntfangstpoartbelied dat it produkt stipet. Hâld ek it TCP-paad fan DNS yn 't each, want in grut antwurd of in weromfal by ôfkoarting ferpleatst de útwikseling nei TCP en in regel allinnich foar UDP sil it net dekke. As de râne steatfolle ynspeksje foar in definiearre stream stipet, ferkies dat boppe in hânskreaune antwurdregel, want it steatfolle paad folget de poarten dy't de kliïnt kiest automatysk.

Befêstigje dan hokker produkt yn it paad it ferkear echt filteret. In dokumintearre IPv4-râneberik fêstiget gjin IPv6-belied, en ferkear binnen de provider giet miskien nea troch deselde filter.

Wêrom't it tastien fan elke boarneport 53 gjin oplossing is

In regel dy't alles akseptearret dat boarneport 53 beweart, is in regel dy't akseptearret wat in ôfstjoerder yn in koptekstfjild skriuwt. It poartnûmer autentisearret de ôfstjoerder net en bewiist net dat de lading in jildich antwurd is, dus de regel ferbreedet de bleatstelling fan 'e host sûnder it oplossen betrouberder te meitsjen. Hâld boarnebeheiningen en hâld de eigen antwurdkontrôles fan 'e kliënt, ynklusyf it tafallich meitsjen fan 'e boarneport, yn stee fan se út te skeakeljen om in tagongslist te ferienfâldigjen.

As de resolver in tsjinst is dy't jo kontrolearje, is beheining ta syn adressen genôch. As it in iepenbiere resolver is, behein ta de adressen dy't jo goedkard hawwe en neam se yn 'e kommentaar fan 'e regel.

Ferifiearje op 'e juste grins, yn 'e juste rjochting

Fange by de host en by de râne foar deselde fraach, en ferlykje de tuplen yn stee fan de pakkettellingen. In fraach sichtber oan beide kanten sûnder antwurd sichtber oan 'e hostkant wiist op it ynkommende filter; in fraach allinnich sichtber oan 'e hostkant wiist op routing of de resolver sels. Werhelje mei in TCP-fraach as jo allinnich in UDP-tastimming hawwe, want dat is de leechte dy't de earste test net sjen kin.

It reparearjen hjirfan foltôget in DNS-útwikseling dy't de host echt nedich hat. It makket de host gjin iepenbiere resolver, machtiget gjin trochstjoerde VPN-streamen en bewiist net dat DNS de oarsaak wie fan in net-ferbâne tunnelprobleem.