Itinatapon ng UFW ang DNS server ng VPN sa sandaling umangat ang tunnel
Sinasakop din ng default-deny na patakaran ng UFW ang interface ng tunnel. Ayusin ang trapiko ayon sa direksyon, payagan ang itinulak na resolver sa tun0, at pagkatapos ay buksan ang panlabas na landas.
Humihinto ang pag-resolve ng mga pangalan sa sandaling kumonekta ang VPN, habang sumasagot pa rin ang ping sa pampublikong address at walang ipinapakitang mali ang status ng firewall. Walang nagbago sa patakaran; ang nagbago ay may bagong interface na lumitaw, at sinasakop ito ng default na pagtanggi mula sa unang packet. Nagpapasya ang UFW ayon sa direksyon at interface, kaya walang sinasabi ang panuntunang isinulat para sa wireless link tungkol sa trapikong lumalabas sa tunnel. Ang pag-aayos ay kakaunting makitid na panuntunan na inilalapat sa isang partikular na pagkakasunod-sunod.
Lumalabas lamang ang sintomas pagkatapos umangat ang tunnel
Ginagawa ng default-deny na patakaran ang eksaktong sinabi rito: anumang walang tugmang panuntunan ay tinatanggihan, sa bawat interface na umiiral. Wala pa ang tunnel nang isulat ang mga panuntunan, kaya wala sa mga ito ang makakahuli rito, at ang pagtangging laging naroon ay nalalapat na ngayon sa pag-resolve ng pangalan. Ang direktang trapiko sa literal na address ay maaari pa ring gumana kapag may mas malawak na permiso na sumasakop dito, at iyon ang dahilan kung bakit nagtatagumpay ang ping sa pampublikong resolver habang nabibigo ang paghahanap ng pangalan. Ang puwang ay isang panuntunan para sa interface na hindi pa nakita ng patakaran.
Ipinapaliwanag din nito kung bakit malinis na bumabalik ang pagkabigo: alisin ang tunnel at nagre-resolve muli ang mga pangalan, dahil bumabalik ang query sa interface na may mga panuntunan. Ang patakarang nabibigo lamang habang nakaangat ang tunnel ay hindi problema sa DNS, at ang pagsasaayos ng resolver mismo ang pinakamaraming nasasayang na oras dito. Basahin ang listahan ng interface bago basahin ang configuration ng resolver.
Tatlong direksyon, tatlong magkaibang set ng panuntunan
Ang isang session ay humahawak ng mga panuntunan sa mahigit isang direksyon, at nagdaragdag ang tunnel ng pangalawang interface sa halos lahat ng mga ito. Ang pag-aayos ng trapiko ayon sa direksyon at interface muna ay ginagawang mekanikal ang natitira, dahil kailangan ng bawat hilera sa ibaba ang sarili nitong panuntunan sa sarili nitong lugar. Gumagamit ang mga halimbawa ng tun0 at pool na 10.8.0.0/24, kaya palitan ang mga pangalan at saklaw ng mga mula sa sariling output ng client.
| 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 |
Madalas mapagkamalan ang dalawang hilera dahil pareho silang nagbabanggit ng tunnel. Pinapayagan ng panuntunan para sa resolver ang trapikong ipinapadala ng client papasok sa tunnel, samantalang pinapayagan ng panuntunan para sa SSH ang trapikong tinatanggap ng server mula roon; nakatira sila sa magkaibang makina at nabibigo nang hiwalay. Ang hilerang pinakamadalas kalimutan ay ang pangalawa, dahil hindi maaaring buuin ng client ang tunnel hanggang hindi pinapayagan ang trapiko nito sa pampublikong address ng server. Magtrabaho mula itaas pababa at bawat pagkabigo ay may isang posibleng dahilan.
Ang itinulak na resolver ay kailangan ang sarili nitong panuntunan
Kung nagdadala ng DNS ang tunnel ay nakadepende sa ipinapadala ng server. Ang server na nagtutulak ng opsyong resolver ay naglalagay ng pribadong address sa configuration ng client, at ang address na iyon ay maruruta lamang sa pamamagitan ng tunnel. Kung wala namang itinutulak ang server, pinapanatili ng client ang resolver na mayroon na ito at walang maipapahintulot ang mga panuntunan sa ibaba. Suriin ang itinulak na estado at ang kasalukuyang resulta ng query bago magsulat ng kahit ano:
dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numberedBinabanggit ng output ng estado ang resolver na ginagamit at ang link na nakakabit dito, at ang paghahanap ng ruta sa likod nito ay nagpapakita kung aling interface ang magdadala ng query sa address na iyon. Kapag ang resolver ay nasa ibang link, ang problema ay mas maaga pa kaysa sa firewall at walang panuntunang makakatulong. Kapag pareho silang nagkasundo tungkol sa tunnel, kailangan ang dalawang panuntunan, dahil UDP ang nagdadala ng karamihan ng query at TCP ang pumapalit kapag naputol ang sagot. Itala ang parehong halaga, dahil iyon ang babanggitin ng mga panuntunan:
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'Buksan ang panlabas na landas bago ang panloob
Kailangang maabot ng client ang pampublikong address ng server bago umiral ang tunnel, kaya ang panuntunan para dito ay nakaupo sa pisikal na link at dapat nasa lugar nito muna. Ang patakarang pumapayag sa resolver pero nakakalimot sa server ay nag-iiwan sa client na tuluyang hindi makabuo ng tunnel, at ang sintomas na iyon ay karaniwang ibinabato sa isang kill switch. Pagkatapos ay payagan ang mga serbisyong talagang gusto mo sa pamamagitan ng tunnel, isang makitid na panuntunan kada pagkakataon, sa halip na buksan ang interface nang buo. Ang makitid na panuntunan ang dahilan kung bakit nananatili sa lugar nito ang pagtanggi.
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'Mahalaga ang pagkakasunod-sunod habang nagsubok, dahil ang unang panuntunan ang nagpapahintulot sa tunnel na umangat. Idagdag ito, kumonekta, at tiyakin na nakaangat ang tunnel bago idagdag ang panuntunan ng serbisyo, dahil ang gawin ang pareho nang sabay ay nangangahulugang walang sinasabi sa iyo ang pagkabigo tungkol sa kung aling kalahati ang mali. Palitan ang address ng dokumentasyon sa itaas ng endpoint kung saan naka-configure ang client.
Tapusin ang panig ng client sa pamamagitan ng sadyang pagputol ng koneksyon. Dapat pa ring tanggihan ng pagtanggi ang trapikong sadyang ibinukod mo, dahil ang resolver na sumasagot habang nakaangat ang tunnel ay sumasakop lamang sa kalahati ng patakarang tumatanggi kapag may pag-aalinlangan.
Ang client na kumokonekta ay hindi pa tinatanggap
May sariling direksyong dapat isaalang-alang ang server, at ang client na tumatapos ng handshake ay hindi pa rin umabot sa anumang tumatakbo sa server hanggang tanggapin ito ng server. Pinapayagan lamang ng panuntunan ng pampublikong listener na umiral ang tunnel; hindi nito pinapasok ang trapiko ng tunnel. Sa server, iyon ay dalawang panuntunan dagdag ang isang pagsusuring talagang nakikinig ang serbisyo:
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'Dapat katumbas ng saklaw na inilalaan ng server ang pool sa panuntunan, at dapat tumugma ang numero ng tunnel sa ginawa ng server, dahil ang panuntunan para sa ibang interface ay hindi matukoy mula sa walang panuntunan. limit ay sadyang para sa administratibong port, dahil pinipigil nito ang paulit-ulit na koneksyon sa halip na tanggapin ang mga ito nang walang hangganan. Hinihiwalay ng pagsusuri ng listener ang saradong port mula sa itinapong packet, na magkapareho sa paningin ng client. Ang may numerong panuntunan ay hindi rin ang buong larawan: ang before na panuntunan ng UFW at anumang nftables na linyang isinulat sa kamay ay tumutugma nang mas maaga at maaari pa ring tanggihan ang packet na tila pinapayagan ng listahan.