OpenWrt-beliedsrouting: de keatling dy't lokaal DNS fangt
Kliïntsiken en de eigen syk fan 'e router komme troch ferskillende haken yn. In belied rjochte op prerouting draacht elke LAN-fraach en lit de router op 'e ISP-uplink.
Kliïnten op 'e LAN lossen op fia de tunnel en de eigen syk fan 'e router docht dat stilwei net. Pakketfernijings, tiidsynkronisaasje en dynamyske DNS geane allegear oer de gewoane uplink, wylst elke trochstjoerde fraach de VPN nimt, en neat yn 'e ynterface suggerearret dat der twa ferskillende paden bestean. De ferklearring is gjin bug yn it belied mar in fraach fan hokker heak it pakket sjocht. Twa streams, ien resolveradres, en mar ien fan beide stekt de router oer. Se fan elkoar skiede is de hiele oplossing.
Twa streams, ien resolveradres
De earste stream is dejinge dy't minsken har foarstelle. In kliïnt freget de resolver fan 'e router, de resolver stjoert opstreams troch, en dat trochstjoerde pakket giet ûnderweis nei bûten troch de router. Dat pakket is sichtber foar alles wat trochstjoerd ferkear besjocht.
De twadde stream komt nea fan earne oan. De router makket him, dus der is gjin ynkommend pakket en gjin trochstjoerstap om te matsen.
Beide kinne itselde resolveradres as doel hawwe, en krekt dêrom is it ferskil maklik te missen. Itselde bestimming, oare oarsprong, oare keatling. Sadra't jo de oarsprong sjogge, folget de rest fan 'e diagnostyk.
Trochstjoerde en lokaal makke pakketten komme oars yn
Trochstjoerd ferkear wurdt beoardiele as it fan in oare ynterface komt. Beliedsroutingpakketten lizze dat bleat as in prerouting-keatling, en in regel dy't dêr pleatst wurdt sjocht elk pakket dat de router oerstekt. Dêrom gedrage kliïntsiken har krekt sa't it belied beskriuwt, en dêrom negearret de router it. De regel is net ferkeard, hy is allinnich oan in heak ferbûn dy't de router nea berikt. Ferpleats him, en deselde oerienkomst begjint te wurkjen.
Lokaal makke ferkear wurdt troch in proses op 'e router makke en giet ynstee de útpoad yn. It wurdt troch de eigen beslissing fan 'e router rûte en moetet allinnich belied as it belied dy keatling dekt. Der is gjin ynkommende ynterface om te matsen en gjin trochstjoerbeslissing om te besjen.
Dat is in eigenskip fan wêr't pakketten berne wurde, net fan in bepaald pakket. In regel skreaun foar ien keatling hat gewoan gjin miening oer de oare. Gjin hoemannichte regeleftuning feroaret dat.
Kies de útgeande keatling en ferfynje dan de oerienkomst
De oplossing is deselde bedoeling ek oan 'e útgeande keatling te ferbinen, of de regel dêrhinne te ferpleatsen as de eigen fragen fan 'e router binne wat jo oanbelanget. Yn in OpenWrt-opsetsel boud op in beliedsroutingpakket betsjut dat it kiezen fan output ynstee fan prerouting yn 'e keatlingynstelling fan 'e regel. Hâld beide regels as beide populaasjes dekking nedich hawwe.
Ferfynje dan wat de regel matst. Bestimmingsresolveradressen op 'e poarte dy't de resolver eins brûkt is in folle lytser beslút as alles wat de router makket yn 'e tunnel te stjoeren.
Hâld de twa regels eksplisyt ynstee fan te besykjen ien te skriuwen dy't beide keatlings dekt. Losse regels binne makliker te lêzen, en se litte jo it paad fan 'e router útskeakelje sûnder kliïntferkear te steuren wylst jo debugge. Se meitsje ek de tellers ien foar ien betsjuttingsfol.
Hâld it eigen ferfier fan 'e tunnel bûten de regel
De bûtenste ferbining fan 'e tunnel wurdt ek troch de router makke. In regel dy't al it lokaal makke ferkear yn 'e tunnel stjoert, sil de tunnel troch himsels rûte, en hy sil hielendal net omheech komme.
Behearstoegong is it twadde slachtoffer. Administrative sesjes dy't fan 'e router ôf komme, of antwurden dêrop, kinne troch in te brede lokale regel yn 'e tunnel lutsen wurde en fan 'e LAN ôf ûnberikber wurde.
Slút it einpunt fan 'e tunnel út fan 'e oerienkomst, en hâld de regel beheind ta de resolveradressen. Dat is genôch foar de DNS-eask en lyts genôch om oer te redenearjen.
Test beide populaasjes, net ien
Sjoch de router syn eigen fraach dwaan en notearje hokker ynterface dy droech. Werhellje it sykjen fan in LAN-host en notearje hokker paad dy naam. Tellers op 'e beliedsregels meitsje beide antwurden sichtber sûnder te rieden.
Behannelje de resultaten as twa befinings. In kliïnt dy't fia de tunnel oplost seit neat oer de router, en in router dy't korrekt oplost seit neat oer in kliïnt op in oare listener. Skriuw se as aparte rigels yn it feroaringsloch.
Kontrolearje ek de poarte: in regel dy't poarte 53 as bestimming matst, mist in resolver dy't berikt wurdt fia DNS over TLS op 853 of in HTTPS-einpunt. Matsje it ferfier dat de konfigurearre upstream eins brûkt, en it lek slút om 'e juste reden.