UFW forĵetas la DNS-servilon de la VPN tuj kiam la tunelo staras

Nomoj ĉesas solviĝi en la momento, kiam la VPN konektiĝas, dum ping al publika adreso ankoraŭ respondas kaj la fajroŝirma stato montras nenion malĝustan. Nenio ŝanĝiĝis en la politiko; ŝanĝiĝis tio, ke aperis nova interfaco, kaj la defaŭlta malpermeso kovras ĝin ekde la unua pako. UFW decidas laŭ direkto kaj interfaco, do regulo skribita por la sendrata ligo diras nenion pri trafiko eliranta el la tunelo. La riparo estas manpleno da mallarĝaj reguloj aplikataj en difinita ordo.

La simptomo aperas nur post kiam la tunelo staras

Defaŭlta malpermesa politiko faras ĝuste tion, kion oni diris al ĝi: ĉio sen kongrua regulo estas rifuzata, sur ĉiu ekzistanta interfaco. La tunelo ne ekzistis kiam la reguloj estis skribitaj, do neniu el ili povas kapti ĝin, kaj la malpermeso, kiu ĉiam estis tie, nun aplikiĝas al nomsolvado. Rekta trafiko al laŭvorta adreso ankoraŭ povas funkcii kiam pli vasta permeso kovras ĝin, kaj tial ping al publika solvilo sukcesas dum serĉo de nomo malsukcesas. La manko estas regulo por interfaco, kiun la politiko neniam vidis.

Tio ankaŭ klarigas, kial la paneo renversiĝas pure: mallevu la tunelon kaj nomoj denove solviĝas, ĉar la demando revenas al interfaco, kiu ja havas regulojn. Politiko, kiu paneas nur dum la tunelo staras, ne estas DNS-problemo, kaj agordi la solvilon mem malŝparas ĉi tie la plej multe da tempo. Legu la interfacan liston antaŭ ol legi la agordon de la solvilo.

Tri direktoj, tri malsamaj regulaj aroj

Unu sesio tuŝas regulojn en pli ol unu direkto, kaj tunelo aldonas duan interfacon al preskaŭ ĉiu el ili. Ordigi la trafikon laŭ direkto kaj interfaco unue igas la ceteron mekanika, ĉar ĉiu vico sube bezonas sian propran regulon en sia propra loko. La ekzemploj uzas tun0 kaj naĝejon de 10.8.0.0/24, do anstataŭigu la nomojn kaj intervalojn per tiuj el la propra eligo de la kliento.

Du vicoj ofte konfuziĝas, ĉar ambaŭ mencias la tunelon. Regulo por la solvilo permesas trafikon, kiun la kliento sendas en la tunelon, dum regulo por SSH permesas trafikon, kiun la servilo ricevas el ĝi; ili loĝas sur malsamaj maŝinoj kaj paneas sendepende. La vico plej ofte forgesata estas la dua, ĉar la kliento tute ne povas starigi la tunelon ĝis ĝia trafiko al la publika adreso de la servilo estas permesita. Laboru de supre malsupren kaj ĉiu paneo havas unu eblan kaŭzon.

Puŝita solvilo bezonas sian propran regulon

Ĉu la tunelo portas DNS dependas de tio, kion la servilo sendas. Servilo, kiu puŝas solvilan opcion, instalas privatan adreson en la agordon de la kliento, kaj tiu adreso estas survojigebla nur tra la tunelo. Se la servilo puŝas nenion, la kliento konservas la solvilon, kiun ĝi jam havis, kaj la reguloj sube havas nenion por permesi. Kontrolu la puŝitan staton kaj la nunan demand rezulton antaŭ ol skribi ion ajn:

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

La statuta eligo nomas la uzatan solvilon kaj la ligon, al kiu ĝi estas ligita, kaj la voja serĉado malantaŭ ĝi montras, kiu interfaco portus demandon al tiu adreso. Kiam la solvilo sidas sur alia ligo, la problemo estas pli frue ol la fajroŝirmilo kaj neniu regulo helpos. Kiam ambaŭ konsentas pri la tunelo, du reguloj necesas, ĉar UDP portas la plej multajn demandojn kaj TCP transprenas kiam respondo estas tranĉita. Notu ambaŭ valorojn, ĉar ili estas tiuj, kiujn la reguloj nomos:

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'

Malfermu la eksteran vojon antaŭ la interna

La kliento devas atingi la publikan adreson de la servilo antaŭ ol tunelo ekzistas, do la regulo por ĝi sidas sur la fizika ligo kaj devas esti loke unue. Politiko, kiu permesas la solvilon sed forgesas la servilon, lasas la klienton tute nekapabla konstrui la tunelon, kaj tiu simptomo kutime estas kulpigata al kill switch. Poste permesu la servojn, kiujn vi vere volis tra la tunelo, unu mallarĝan regulon samtempe, anstataŭ malfermi la interfacon tute. La mallarĝaj reguloj estas la kialo, ke la malpermeso povas resti loke.

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'

Ordo gravas dum vi testas, ĉar la unua regulo estas tio, kio entute lasas la tunelon stariĝi. Aldonu ĝin, konektiĝu, kaj konfirmu, ke la tunelo staras antaŭ ol aldoni la servan regulon, ĉar fari ambaŭ samtempe signifas, ke paneo diras al vi nenion pri tio, kiu duono malĝustas. Anstataŭigu la dokumentan adreson supre per la finpunkto, por kiu la kliento estas agordita.

Finu la klientan flankon per intenca malkonektiĝo. La malpermeso devus ankoraŭ rifuzi la trafikon, kiun vi intence ekskludis, ĉar solvilo, kiu respondas dum la tunelo staras, kovras nur duonon de politiko, kiu rifuzas en kazo de dubo.

Kliento, kiu konektiĝas, ankoraŭ ne estas akceptita

La servilo havas sian propran direkton por konsideri, kaj kliento, kiu finas la manpremon, ankoraŭ ne atingas ion ajn funkciantan sur la servilo ĝis la servilo akceptos ĝin. La regulo de la publika aŭskultanto nur lasas la tunelon ekzisti; ĝi ne enlasas la trafikon de la tunelo. Sur la servilo tio estas du reguloj plus unu kontrolo, ke la servo vere aŭskultas:

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'

La naĝejo en la regulo devas egali la intervalon, kiun la servilo asignas, kaj la tunela numero devas kongrui kun tiu, kiun la servilo kreis, ĉar regulo por alia interfaco ne distingeblas de neniu regulo. limit estas intenca por administra pordo, ĉar ĝi limigas ripetajn konektojn anstataŭ akcepti ilin sen limo. La aŭskultanta kontrolo apartigas fermitan pordon de forĵetita pako, kiuj aspektas idente de la kliento. Numeritaj reguloj ankaŭ ne estas la tuta bildo: la before-reguloj de UFW kaj ajnaj permane skribitaj nftables-linioj kongruas pli frue kaj ankoraŭ povas rifuzi pakon, kiun la listo ŝajne permesas.