UFWk VPNaren DNS zerbitzaria botatzen du tunela altxatzean
UFWren ukapen lehenetsiak tunelaren interfazea ere estaltzen du. Sailkatu trafikoa norabidearen arabera, onartu bultzatutako resolverra tun0-n, eta gero ireki kanpoko bidea.
Izenak ebatzi ezintsu bihurtzen dira VPN konektatzen den unean, bitartean helbide publiko baterako ping-ak oraindik erantzuten du eta suebakiaren egoerak ez du ezer okerrik erakusten. Politikan ez da ezer aldatu; aldatu dena da interfaze berri bat agertu dela, eta ukapen lehenetsiak lehen paketetik hartzen duela. UFWk norabidearen eta interfazearen arabera erabakitzen du, beraz haririk gabeko estekak idatzitako arauak ezer ez du esaten tunela uzten duen trafikoari buruz. Konponketa ordena jakin batean aplikatutako arau estu batzuk dira.
Sintoma tunela altxatu ondoren soilik agertzen da
Ukapen lehenetsiaren politikak esan zaiona egiten du zehazki: arau parekagarririk ez duen guztia ukatzen da, existitzen den interfaze guztietan. Arauak idatzi zirenean tunela ez zegoen, beraz horietako inork ezin du harrapatu, eta betidanik zegoen ukapena orain izenen ebazpenari aplikatzen zaio. Helbide literal batera zuzenean joateak oraindik funtziona dezake baimen zabalago batek estaltzen duenean, eta horregatik resolver publiko baterako ping-ak arrakasta du izen baten bilaketak huts egiten duen bitartean. Hutsunea politikak inoiz ikusi ez duen interfaze baterako araua da.
Horrek ere azaltzen du zergatik alderantzikatzen den hutsa garbi: jaitsi tunela eta izenak berriro ebazten dira, galderak arauak dituen interfaze batera itzultzen delako. Tunela altxatuta dagoen bitartean soilik huts egiten duen politika ez da DNS arazoa, eta resolverra bera doitzeak denbora gehien galtzen du hemen. Irakurri interfazeen zerrenda resolverraren konfigurazioa irakurri aurretik.
Hiru norabide, hiru arau-multzo desberdin
Saio bakarrak arauak ukitzen ditu norabide batean baino gehiagotan, eta tunelek bigarren interfaze bat gehitzen die ia guztiei. Trafikoa lehenengo norabidearen eta interfazearen arabera sailkatzeak gainerakoa mekaniko bihurtzen du, beheko errenkada bakoitzak bere araua behar baitu bere tokian. Adibideek tun0 eta 10.8.0.0/24 igerilekua erabiltzen dituzte, beraz ordezkatu izenak eta barrutiak bezeroaren beraren irteerakoekin.
| Direction | Example packet | Rule that admits it | Written on |
|---|---|---|---|
| Client to the pushed resolver | A DNS query to 10.8.0.1 | Destination port 53 over the tunnel | The client's tun0 |
| Client to the VPN server | A handshake to the server's public address | Server address and port on the physical link | The client's physical interface |
| Server to a service | SSH from the pool to port 22 | Source pool, destination port, tunnel interface | The server's tun0 |
| Anyone to the listener | The VPN listener itself | 1194/udp on the public side | The server's public interface |
Bi errenkada nahasten dira sarritan, biek tunela aipatzen dutelako. Resolverraren arauak bezeroak tunelera bidaltzen duen trafikoa onartzen du, eta SSHren arauak, berriz, zerbitzariak hortik jasotzen duen trafikoa; makineria desberdinetan bizi dira eta modu independentean huts egiten dute. Ahazten den errenkada ohikoena bigarrena da, bezeroak ezin duelako tunela eraiki haren trafikoa zerbitzariaren helbide publikora baimenduta egon arte. Lan egin goitik behera eta hutsegite bakoitzak kausa hautagai bakarra du.
Bultzatutako resolverrak bere araua behar du
Tunelek DNS daraman ala ez zerbitzariak bidaltzen duenaren araberakoa da. Resolver aukera bat bultzatzen duen zerbitzariak helbide pribatu bat instalatzen du bezeroaren konfigurazioan, eta helbide hori tuneletik soilik da bideragarria. Zerbitzariak ezer bultzatzen ez badu, bezeroak lehenago zuen resolverra mantentzen du eta beheko arauek ez dute ezer onartzeko. Egiaztatu bultzatutako egoera eta uneko galderaren emaitza ezer idatzi aurretik:
dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numberedEgoeraren irteerak erabiltzen den resolverra eta lotuta dagoen esteka izendatzen ditu, eta atzean dagoen ibilbide bilaketak erakusten du zein interfazek eramango lukeen galdera helbide horretara. Resolverra beste esteka batean dagoenean, arazoa suebakia baino lehenagokoa da eta inolako arauk ez du lagunduko. Biek tunelean bat egiten dutenean, bi arau behar dira, UDPk galdera gehienak daramatzalako eta TCPk hartzen duelako erantzuna mozten denean. Idatzi bi balioak, arauek izendatuko dituztenak haiek baitira:
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'Ireki kanpoko bidea barnekoa baino lehen
Bezeroak zerbitzariaren helbide publikora iritsi behar du tunela existitu baino lehen, beraz horretarako araua esteka fisikoan esertzen da eta lehenik egon behar du. Resolverra onartzen duen baina zerbitzaria ahazten duen politikak bezeroa tunela eraikitzeko gai ez den egoeran uzten du, eta sintoma horri kill switch bati leporatzen zaio normalean. Gero onartu tunelaren bidez benetan nahi zenituen zerbitzuak, arau estu bat aldi bakoitzean, interfazea osorik ireki ordez. Arau estuek dira ukapenak bere tokian jarrai dezakeen arrazoia.
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'Ordenak garrantzia du probatzean, lehen araua baita tunelari altxatzen uzten diona. Gehitu, konektatu eta egiaztatu tunela altxatuta dagoela zerbitzu araua gehitu aurretik, biak batera egiteak huts egiteak zein erdi dagoen gaizki ezer esango ez dizulako. Ordezkatu goiko dokumentazio helbidea bezeroa erabiltzeko konfiguratuta dagoen amaiera puntuarekin.
Amaitu bezeroaren aldea nahita deskonektatuz. Ukapenak oraindik ukatu behar du nahita baztertu duzun trafikoa, tunela altxatuta dagoen bitartean erantzuten duen resolverrak zalantzan ukatzen duen politikaren erdia soilik estaltzen duelako.
Konektatzen den bezeroa ez da oraindik onartua
Zerbitzariak bere norabidea du kontuan hartzeko, eta eskuko keinuarekin amaitzen duen bezeroak ezin du zerbitzarian exekutatzen den ezer atzitu zerbitzariak onartzen duen arte. Entzule publikoaren arauak tunela existitzea baino ez du uzten; ez du tunelaren trafikoa sartzen uzten. Zerbitzarian bi arau dira gehi zerbitzua benetan entzuten ari dela egiaztatzen duen egiaztapen bat:
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'Arauko igerilekuak zerbitzariak esleitzen duen barrutiaren berdina izan behar du, eta tunel zenbakiak zerbitzariak sortutakoarekin bat etorri behar du, interfaze desberdin baterako araua ez baita araurik ez izatetik bereizten. limit nahita dago portu administratibo baterako, errepikatutako konexioak muga bat gabe onartu ordez mugatzen dituelako. Entzulearen egiaztapenak portu itxi bat baztertutako pakete batetik bereizten du, bezeroaren ikuspegitik berdinak diruditenak. Zenbakidun arauak ere ez dira irudi osoa: UFWren before arauak eta eskuz idatzitako nftables lerroak lehenago bat etortzen dira eta oraindik uka dezakete zerrendak onartzen duela dirudien pakete bat.