Ang pagsulat ng -o tun+ ay parang tumpak na tagubilin at sa totoo lang ay isang wildcard na tumutugma sa bawat tunnel na mayroon ang kernel. Ang pangalawang VPN client, isang container bridge o isang interface na iniwan ng isang session na nag-crash ay tumutugma rito, at pinapayagan na ng host ang trapikong dapat sana ay hinadlangan ng patakaran. Ipinipit ng pamamaraan sa ibaba ang isang pangalan ng device, inaayos ang mga exception para tunay na makabuo ang tunnel, at iniiwan ka ng daan pabalik kung masama ang bagsak ng mga panuntunan. Ang bawat hakbang ay sapat na maikli para bawiin nang mag-isa.

Hakbang 1: itala ang mga panuntunang mayroon ka ngayon

Bago baguhin ang default na patakaran, i-save ang kasalukuyang estado para ang rollback ay isang utos at hindi alaala. Isinulat ng iptables-save > /root/iptables.pre ang bawat talahanayan sa file na maaari mong i-restore, at ang pangalawang terminal na may bukas na root session ay hindi paranoya kapag ang patakarang itatakda mo ay pumutol sa koneksyong nagdadala nito. Kung nagtatrabaho ka nang malayuan, mag-iskedyul din ng flush bilang emergency switch.

Pagkatapos, ilista ang mga interface, dahil ang pangalang inakala mo ay pangalang dapat sana ay binasa mo: ipinapakita ng ip -br link ang mayroon ngayon, at hindi lalabas ang tunnel hanggang sa maitaas ito. Isulat ang mga pangalan ng device habang binabasa mo.

Hakbang 2: bigyan ang tunnel ng sarili nitong pangalan

Tinatanggap ng OpenVPN ang dev tun_work sa configuration ng client, at pagkatapos ay gumagawa ang Linux ng interface na eksaktong may ganoong pangalan sa halip na maglaan ng tun0. Nananatiling matatag ang pangalan sa mga muling pagkonekta hangga't walang ibang nag-aangkin nito, at iyon ang nagbibigay-kahulugan sa panuntunang nagpangalan sa device.

Kung saan hindi makontrol ang pangalan, itugma ang address ng tunnel o isang packet mark. Gumagana ang dalawa, mas mahirap basahin ang dalawa, at mas tahimik na nabibigo ang dalawa kapag nagpalit ng numero ang tunnel. Sa anumang kaso, itugma ang isang bagay lamang at sabihin nang malinaw kung alin.

Hakbang 3: isulat ang patakaran na inuuna ang exception ng endpoint

Ang host na VPN lamang ay host na default-deny na may maikling listahan ng exception, at ang pinakamahalagang exception ay ang nagpapahintulot sa tunnel na umiral. Buuin ito sa ganitong pagkakasunod-sunod, na ang panuntunan ng endpoint ay bago ang panuntunan ng tunnel device, para may mapuntahan ang handshake:

# allow the tunnel to be built, then everything the tunnel carries
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -o tun_work -j ACCEPT
iptables -A INPUT  -i tun_work -j ACCEPT
iptables -A INPUT  -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Ang literal na address at port ng endpoint ay pag-aari ng iyong provider, hindi ng pahinang ito. Kung ang endpoint ay hostname, lutasin ito nang isang beses at ipitin ang resulta, dahil hindi makapaghanap ng pangalan ang isang panuntunan at ang umiikot na sagot ay tahimik na masisira ang patakaran pagkatapos ng susunod na pagbabago sa DNS. Suriin din ang port, dahil ang mga provider na naglilipat sa iyo sa TCP 443 ay mangangailangan kung hindi ng panuntunang walang nakasulat. Ang tunnel na gumagana lamang sa isang protocol ay karaniwang ang pagkaligta na ito at hindi sira ng firewall.

Sa isang router, ang parehong hugis ay pumapasok sa FORWARD chain para sa mga client sa likod nito, at ang sariling trapiko ng router ay nangangailangan ng sariling mga panuntunan. Ang set ng panuntunang sumasaklaw lamang sa mga ipinasang packet ay nag-iiwan sa SSH at DNS sa lumang daan, at ganoon nagiging hindi maabot ang router sa sandaling tumaas ang tunnel.

Hakbang 4: suriin ang pagkakasunod-sunod, hindi lamang ang presensya

Sinusuri ang mga panuntunan ayon sa pagkakasunod-sunod, kaya ang ACCEPT na nauna ay itinatago lamang ang REJECT na idinagdag mo mamaya. Ang pagtutugma ng established at related ang nagpapahintulot sa mga sagot sa sarili mong papalabas na kahilingan na bumalik nang hindi binubuksan ang pangkalahatang papasok na daan, at ang paglalagay nito pagkatapos ng pagtanggap ng tunnel ay nangangahulugang ang bumagsak na tunnel ay nagpaparaan pa rin ng pabalik na trapiko sa sarili nitong interface.

Panatilihing sapat na maliit ang bilang ng panuntunan para mabasa sa isang screen. Ang set ng panuntunang hindi mo ma-audit ay iyon ang tatapalan mo sa pamamagitan ng pagdaragdag ng exception sa itaas, at ganoon nakakakuha ng gilid ng default-allow ang mga patakarang default-deny sa paglipas ng panahon. Bilangin ang ACCEPT bago at pagkatapos ng pagbabago.

Hakbang 5: gawing nakakaligtas ito sa boot at sa pamilya ng address

Ang mga panuntunang inilagay sa kamay ay nawawala sa reboot, kaya i-load ang mga ito mula sa serbisyo ng firewall ng distribusyon o mula sa isang unit na tumatakbo pagkatapos na umiral ang interface ng tunnel. Ang pagsangguni sa tun_work sa isang script na tumatakbo bago magsimula ang OpenVPN ay karaniwang paraan ng paglikha ng boot loop ng itinapong trapiko.

Pagkatapos, suriin ang IPv6 nang hiwalay, dahil ang isang mahusay na patakarang default-deny para sa IPv4 ay walang sinasabi tungkol sa kabilang pamilya. Sasabihin sa iyo ng ip -6 route kung may ruta ang host na makakapagdala ng trapiko sa paligid ng tunnel na humahawak lamang ng IPv4, at ang ip6tables o nftables ay nangangailangan ng sarili nitong katumbas na panuntunan. Subukan gamit ang destinasyong IPv6-only sa halip na magtiwala sa simetriya ng set ng panuntunan.

Hakbang 6: i-verify at maging handa sa pag-restore

Itaas ang tunnel, kumpirmahin na gumagana ang inilaan na serbisyo, pagkatapos ay subukan ang isang bagay na dapat tanggihan ng patakaran. I-restore gamit ang iptables-restore < /root/iptables.pre kung magulat ka sa sagot, at pagkatapos lamang magsimulang mag-edit ng mga panuntunan. Ang pagtitiyaga at nasubok na daan ng pag-restore ang gumagawa nito na pagbabagong kaya mong gawin nang dalawang beses.

Kaugnay na mga artikulo