Waarom die DNS-antwoord by 'n staatlose VPN-randfirewall misluk

Die tonnel is op, kliënte kan die VPN-gasheer bereik, en die gasheer kan niks oplos nie. Sy eie uitgaande navrae verlaat die koppelvlak skoon, so die fout lê op die terugpad: by 'n stroomop-rand wat inkomende verkeer filter sonder enige geheue van wat die gasheer pas gestuur het. Om die tonnelpoort toe te laat beskryf daardie uitruiling glad nie. Die antwoord op 'n DNS-navraag is 'n aparte vloei, en as die rand staatloos is, het niks dit gemagtig om terug te keer nie.

Die twee uitruilings is nie dieselfde uitruiling nie

Skryf die tuple neer en die fout word duidelik. Die navraag se bestemmingspoort word die antwoord se bronpoort, wat die teenoorgestelde is van wat meeste mense voorstel wanneer hulle 'n inkomende reël vir poort 53 byvoeg:

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

'n Inkomende reël wat bestemmingspoort 53 vereis, beskryf verkeer gerig op 'n DNS-luisteraar wat op die gasheer loop, wat 'n heeltemal ander diens is. Daardie adresse is dokumentasie-voorbeelde, en die bronpoort word per navraag deur die kliënt gekies, so dit is nie 'n waarde wat jy in 'n reël kan kopieer en kan verwag dat dit bly werk nie.

Staatlose rand teenoor staatvolle gasheer-firewall

’n Staatlose randfilter evalueer elke inkomende pakket teen sy reëllys sonder enige verbindingstabel agter hom. 'n Uitgaande navraag wat suksesvol vertrek het, skep geen toestemming vir sy inkomende antwoord nie, want die toestel het geen rekord dat 'n navraag ooit plaasgevind het nie. 'n Staatvolle gasheer-firewall is die teenoorgestelde: sy verbindingnasporing herken die terugkerende verkeer van 'n toegelate uitruiling en laat dit deur sonder 'n reël vir die antwoord. Albei grense bestaan in 'n tipiese pad, en albei moet die bedoelde pakket toelaat.

Die vergelyking maak saak omdat die twee toestelle verskillend faal. 'n Staatvolle firewall wat die antwoord weier, teken 'n drop aan; 'n staatlose rand weier dit stilweg, en daarom tyd die gasheer eenvoudig uit.

Bou die toelating rondom die protokol, nie 'n poortnommer nie

Beperk die reël tot die werklike oplosseradresse, die bestemmingsgasheer en die ontvangspoort-beleid wat die produk ondersteun. Hou ook DNS se TCP-pad in gedagte, want 'n groot antwoord of 'n afkap-terugval verskuif die uitruiling na TCP en 'n slegs-UDP-reël dek dit nie. As die rand staatvolle inspeksie vir 'n gedefinieerde vloei ondersteun, verkies dit bo 'n handgeskrewe antwoordreël, want die staatvolle pad volg outomaties die poorte wat die kliënt kies.

Bevestig dan watter produk op die pad die verkeer werklik filter. 'n Gedokumenteerde IPv4-randomvang vestig nie 'n IPv6-beleid nie, en verskaffer-interne verkeer mag glad nooit dieselfde filter kruis nie.

Waarom enige bronpoort 53 toelaat nie 'n oplossing is nie

'n Reël wat enigiets aanvaar wat bronpoort 53 beweer, is 'n reël wat aanvaar wat 'n sender ook al in 'n kopveld skryf. Die poortnommer verifieer nie die sender nie en bewys nie dat die loonvrag 'n geldige antwoord is nie, so die reël vergroot die gasheer se blootstelling sonder om die oplossing betroubaarder te maak. Hou bronbeperkings en hou die kliënt se eie antwoordkontroles, insluitend bronpoort-eisewilligheid, eerder as om hulle uit te skakel om 'n toegangslys te vereenvoudig.

As die oplosser 'n diens is wat jy beheer, is beperking tot sy adresse genoeg. As dit 'n publieke oplosser is, beperk tot die adresse wat jy goedgekeur het en noem hulle in die reël se kommentaar.

Verifieer by die regte grens, in die regte rigting

Vang by die gasheer en by die rand vir dieselfde navraag, en vergelyk die tuple eerder as die pakkettellings. 'n Navraag wat aan beide kante sigbaar is met geen antwoord aan die gasheerkant nie, dui op die inkomende filter; 'n navraag wat net aan die gasheerkant sigbaar is, dui op routing of die oplosser self. Herhaal met 'n TCP-navraag as jy 'n slegs-UDP-toelating het, want dit is die gaping wat die eerste toets nie kan sien nie.

Om dit reg te maak voltooi 'n DNS-uitruiling wat die gasheer werklik nodig het. Dit maak nie die gasheer 'n publieke oplosser nie, magtig nie geforwarde VPN-vloei nie en bewys nie dat DNS die oorsaak van een of ander onverwante tonnelprobleem was nie.