OpenWrt-beleidsroetering: die ketting wat plaaslike DNS vang

Kliënte op die LAN los op deur die tonnel, en die roeter se eie navrae doen dit stilweg nie. Pakketopdaterings, tydsinchronisering en dinamiese DNS verlaat almal die gewone oplyn, terwyl elke deurgestuurde navraag die VPN neem, en niks in die koppelvlak dui aan dat twee verskillende paaie bestaan nie. Die verklaring is nie ’n fout in die beleid nie, maar ’n kwessie van watter haak die pakket sien. Twee vloei, een oplosseradres, en net een van hulle steek die roeter oor. Om hulle uitmekaar te sorteer is die hele oplossing.

Twee vloei, een oplosseradres

Die eerste vloei is die een wat mense hulle voorstel. ’n Kliënt vra die roeter se oplosser, die oplosser stuur opstroom aan, en daardie deurgestuurde pakket gaan op pad uit deur die roeter. Daardie pakket is sigbaar vir enigiets wat deurgestuurde verkeer dophou.

Die tweede vloei kom nooit van enige plek aan nie. Die roeter skep dit, dus is daar geen inkomende pakket en geen deurstuurstap om te pas nie.

Albei kan dieselfde oplosseradres teiken, en juis daarom is die verskil maklik om te mis. Dieselfde bestemming, verskillende oorsprong, verskillende ketting. Sodra jy die oorsprong sien, volg die res van die diagnose.

Deurgestuurde en plaaslik geskepte pakkette kom anders in

Deurgestuurde verkeer word geëvalueer wanneer dit van ’n ander koppelvlak af kom. Beleidsroetering-pakkette stel dit bloot as ’n prerouting-ketting, en ’n reël wat daar geplaas word, sien elke pakket wat die roeter oorsteek. Dit is waarom kliëntnavrae presies optree soos die beleid beskryf, en waarom die roeter dit ignoreer. Die reël is nie verkeerd nie; dit is bloot aan ’n haak geheg wat die roeter nooit bereik nie. Skuif dit, en dieselfde passing begin werk.

Plaaslik geskepte verkeer word deur ’n proses op die roeter geskep en betree eerder die uitvoerpad. Dit word deur die roeter se eie besluit gerouteer en ontmoet net beleid as die beleid daardie ketting dek. Daar is geen inkomende koppelvlak om te pas nie en geen deurstuurbesluit om waar te neem nie.

Dit is ’n eienskap van waar pakkette gebore word, eerder as van enige spesifieke programmatuurpakket. ’n Reël wat vir een ketting geskryf is, het eenvoudig geen mening oor die ander nie. Geen hoeveelheid reëlverstelling verander dit nie.

Kies die uitvoerketting en vernou dan die passing

Die oplossing is om dieselfde bedoeling ook aan die uitvoerketting te heg, of om die reël daarheen te skuif wanneer die roeter se eie navrae is wat jou aangaan. In ’n OpenWrt-opstelling wat op ’n beleidsroetering-pakket gebou is, beteken dit om output eerder as prerouting in die reël se kettinginstelling te kies. Hou albei reëls as albei populasies dekking nodig het.

Vernou dan wat die reël pas. Bestemming-oplosseradresse op die poort wat die oplosser werklik gebruik, is ’n veel kleiner besluit as om alles wat die roeter skep in die tonnel te stuur.

Hou die twee reëls eksplisiet eerder as om een te probeer skryf wat albei kettings dek. Aparte reëls is makliker om te lees, en hulle laat jou die roeter se pad deaktiveer sonder om kliëntverkeer te steur wanneer jy ontfout. Hulle maak ook die tellers een op ’n slag betekenisvol.

Hou die tonnel se eie vervoer uit die reël

Die tonnel se buitenste verbinding word ook deur die roeter geskep. ’n Reël wat alle plaaslik geskepte verkeer in die tonnel stuur, sal die tonnel deur homself routeer, en dit sal glad nie opkom nie.

Bestuurstoegang is die tweede slagoffer. Administratiewe sessies wat van die roeter af ontstaan, of antwoorde daarop, kan deur ’n te breë plaaslike reël in die tonnel ingetrek word en van die LAN af onbereikbaar word.

Sluit die tonnel se eindpunt uit die passing, en hou die reël beperk tot die oplosseradresse. Dit is genoeg vir die DNS-vereiste en klein genoeg om oor te redeneer.

Toets albei populasies, nie een nie

Kyk hoe die roeter sy eie navraag maak en let op watter koppelvlak dit gedra het. Herhaal die opsoek vanaf ’n LAN-gasheer en let op watter pad daardie een gevolg het. Tellers op die beleidsreëls maak albei antwoorde sigbaar sonder om te raai.

Behandel die resultate as twee bevindings. ’n Kliënt wat deur die tonnel oplos, sê niks oor die roeter nie, en ’n roeter wat korrek oplos, sê niks oor ’n kliënt op ’n ander luisteraar nie. Skryf hulle as aparte reëls in die veranderingsverslag.

Kyk ook na die poort: ’n reël wat bestemmingspoort 53 pas, mis ’n oplosser wat oor DNS over TLS op 853 of ’n HTTPS-eindpunt bereik word. Pas die vervoer wat die gekonfigureerde opstroom werklik gebruik, en die lek sluit om die regte rede.