UFW hendir DNS-þjóni VPN þegar göngin eru komin upp

Nöfn hætta að leysast á sömu sekúndu og VPN tengist, á meðan ping á almenningsvistfang svarar enn og eldveggsstaðan sýnir ekkert sem virðist rangt. Ekkert breyttist í stefnunni; það sem breyttist er að nýtt tengi birtist, og sjálfgefið synjun nær yfir það frá fyrstu pakkningu. UFW ákveður eftir stefnu og tengi, svo regla sem skrifuð er fyrir þráðlausa tenginguna segir ekkert um umferð sem fer út úr göngunum. Viðgerðin er handfylli af þröngum reglum sem beitt er í ákveðinni röð.

Einkennið kemur aðeins fram eftir að göngin eru komin upp

Sjálfgefin synjunarstefna gerir nákvæmlega það sem henni var sagt: öllu án samsvarandi reglu er hafnað, á hverju tengi sem er til. Göngin voru ekki til þegar reglurnar voru skrifaðar, svo engin þeirra getur náð til þeirra, og synjunin sem var alltaf þar gildir nú um nafnaupplausn. Bein umferð á bókstaflegt vistfang getur enn virkað þegar víðtækara leyfi nær yfir hana, og þess vegna gengur ping á almenna leysirinn á meðan nafnaleit mistekst. Bilið er regla fyrir tengi sem stefnan hefur aldrei séð.

Það útskýrir líka hvers vegna bilunin snýst við á hreinan hátt: taktu göngin niður og nöfn leysast aftur, því fyrirspurnin fer aftur á tengi sem hefur reglur. Stefna sem mistekst aðeins meðan göngin eru uppi er ekki DNS-vandamál, og að stilla leysirinn sjálfan eyðir mestum tíma hér. Lestu tengilistann áður en þú lest stillingar leysisins.

Þrjár stefnur, þrjú mismunandi reglusett

Ein lota snertir reglur í fleiri en einni stefnu, og göng bæta öðru tengi við næstum hverja þeirra. Að raða umferðinni eftir stefnu og tengi fyrst gerir restina vélræna, því hver röð hér fyrir neðan þarf sína eigin reglu á sínum eigin stað. Dæmin nota tun0 og laug af 10.8.0.0/24, svo skiptu nöfnum og bilum út fyrir þau úr eigin framleiðslu biðlarans.

Tvær raðir ruglast oft því báðar nefna göngin. Regla fyrir leysirinn hleypir umferð sem biðlarinn sendir inn í göngin, á meðan regla fyrir SSH hleypir umferð sem þjónninn tekur við úr þeim; þær lifa á mismunandi vélum og mistekst óháð. Röðin sem gleymist oftast er önnur, því biðlarinn getur alls ekki byggt göngin fyrr en umferð hans á almennt vistfang þjónsins er leyfð. Vinndu ofan frá og niður og hver bilun hefur eina líklega orsök.

Ýttur leysir þarf sína eigin reglu

Hvort göngin flytja DNS fer eftir því sem þjónninn sendir. Þjónn sem ýtir valkosti leysis setur einkavistfang í stillingar biðlarans, og það vistfang er aðeins hægt að beina um göngin. Ef þjónninn ýtir engu heldur biðlarinn leysinum sem hann hafði þegar og reglurnar hér fyrir neðan hafa ekkert til að leyfa. Athugaðu ýttu stöðuna og núverandi niðurstöðu fyrirspurnar áður en þú skrifar nokkuð:

dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numbered

Stöðuframleiðslan nefnir leysirinn sem er í notkun og tenginguna sem hann er bundinn við, og leiðarleitin þar fyrir aftan sýnir hvaða tengi myndi flytja fyrirspurn á það vistfang. Þegar leysirinn situr á annarri tengingu er vandamálið fyrr en eldveggurinn og engin regla mun hjálpa. Þegar báðir eru sammála um göngin þarf tvær reglur, því UDP flytur flestar fyrirspurnir og TCP tekur við þegar svar er stytt. Skráðu bæði gildin, því þau eru þau sem reglurnar munu nefna:

sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto udp comment 'pushed resolver'
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto tcp comment 'truncated answers'

Opnaðu ytri leiðina á undan þeirri innri

Biðlarinn verður að ná almenna vistfanginu á þjóninum áður en göng eru til, svo reglan fyrir það situr á líkamlegu tengingunni og verður að vera á sínum stað fyrst. Stefna sem hleypir leysinum en gleymir þjóninum lætur biðlarann vera algjörlega ófæran um að byggja göngin, og það einkenni er venjulega kennt við kill switch. Leyfðu svo þjónustunum sem þú vildir í raun um göngin, einni þröngri reglu í einu, í stað þess að opna tengið í heild. Þröngu reglurnar eru ástæðan fyrir því að synjunin getur staðið áfram.

sudo ufw allow out to 198.51.100.10 port 1194 proto udp comment 'vpn server'
sudo ufw allow out on tun0 to any port 443 proto tcp comment 'web through tunnel'

Röðin skiptir máli meðan þú prófar, því fyrsta reglan er það sem lætur göngin koma upp yfirhöfuð. Bættu henni við, tengdu og staðfestu að göngin séu uppi áður en þú bætir þjónustureglunni við, því að gera bæði í einu þýðir að bilun segir þér ekkert um hvora hálfina er röng. Skiptu skjölunarvistfanginu hér að ofan út fyrir endapunktinn sem biðlarinn er stilltur fyrir.

Kláraðu biðlarahliðina með því að aftengja viljandi. Synjunin ætti enn að hafna umferðinni sem þú útilokaðir viljandi, því leysir sem svarar meðan göngin eru uppi nær aðeins yfir helming stefnu sem hafnar ef efast er.

Biðlari sem tengist er ekki enn tekinn inn

Þjónninn hefur sína eigin stefnu að hafa í huga, og biðlari sem klárar handabiðið nær samt ekki neinu sem keyrir á þjóninum fyrr en þjónninn tekur hann inn. Reglan fyrir almenna hlustandann leyfir göngunum aðeins að vera til; hún hleypir ekki umferð ganganna inn. Á þjóninum eru þetta tvær reglur auk einnar athugunar á að þjónustan hlusti í raun:

sudo ufw allow 1194/udp comment 'openvpn listener'
sudo ufw limit in on tun0 from 10.8.0.0/24 to any port 22 proto tcp comment 'admin over tunnel'
ss -ltn | grep ':22'

Laugin í reglunni verður að jafngilda bilinu sem þjónninn úthlutar, og númer gonganna verður að passa við það sem þjónninn bjó til, því regla fyrir annað tengi er ógreinanleg frá engri reglu. limit er viljandi fyrir stjórnunarport, því það takmarkar endurteknar tengingar í stað þess að taka þær við án takmarkana. Hlustandaathugunin aðgreinir lokað port frá pakkningu sem varpað var, sem líta eins út frá biðlaranum. Númeraðar reglur eru líka ekki heildarmyndin: before-reglur UFW og allar handskrifaðar nftables-línur passa fyrr og geta enn hafnað pakkningu sem listinn virðist leyfa.