Plentunela OpenVPN: aldonu interretan eliron ĉe la servila flanko

Kliento aŭtentikiĝas, ricevas adreson el la baseno kaj atingas servojn sur la VPN-gastiganto, tamen ĉiu publika celo tempofinas. Tiel aspektas tunelo sen eliro, kaj tiel restas ĝis kvar apartaj aferoj veras. La kliento devas akcepti defaŭltan itineron, la servilo devas plusendi, la fajroŝirmilo devas permesi la trairon, kaj la respondoj bezonas vojon reen al la baseno. Ĉiuj kvar fiaskoj kunhavas unu simptomon, do ŝanĝu unu eron po provo kaj notu la rezulton.

Puŝu la defaŭltan itineron kaj konfirmu, kion la kliento instalis

La linio ĉe la servila flanko estas mallonga, kaj ĝi efikas nur al klientoj, kiuj akceptas puŝitajn opciojn. La formo def1 instalas du duondefaŭltajn itinerojn anstataŭ forigi la ekzistantan defaŭlton, kio tenas la nunan konekton viva dum ĝi ankoraŭ kaptas ĉiun celon.

push "redirect-gateway def1"

Post rekonekto, legu la enkursigan tabelon de la kliento anstataŭ fidi la profilon. En Linux la du /1-enskribaĵoj aperas apud la origina defaŭlto, kaj Windows montras la saman paron kiel 0.0.0.0/1 kaj 128.0.0.0/1. Kliento, kiu ignoras puŝitajn opciojn, aŭ tiu agordita rifuzi ilin, konservas sian malnovan defaŭlton kaj neniam sendas interretan trafikon en la tunelon. Solvu tiun demandon antaŭ ol ŝanĝi ion ajn sur la servilo, ĉar neniu regulo ĉe la servila flanko povas kompensi.

Plusendo estas servila agordo, ne VPN-agordo

Legu la plusendan flagon antaŭ ol tuŝi enkursigadon. Nulo tie signifas, ke la kerno ricevas la paketon de la kliento kaj rifuzas plusendi ĝin, kio aspektas precize kiel fajroŝirmila blokado de la fora flanko. Agordu la valoron tra la agorda dosierujo de la sistemo, por ke ĝi postvivu restarton.

sysctl net.ipv4.ip_forward
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-vpn-forward.conf
sudo sysctl --system

Poste konfirmu, ke la gastiganto mem havas funkciantan itineron al la interreta eliro. Peto el la ŝelo de la servilo pruvas, ke la supra vojo estas uzebla, kaj tute ne diras ion pri plusendo de paketo de kliento, do traktu ilin kiel du apartajn testojn. Se la servilo ne povas atingi la celon, neniom da plusenda agordo helpos.

Permesu ĝuste la trairon, kiun vi celas, kaj nenion alian

Plusenditaj paketoj trapasas la vojon forward; trafiko adresita al la VPN-gastiganto mem trapasas input. Tiuj estas apartaj decidoj, kaj malfermi la vojon input ne permesas trairon tra la maŝino. Konfuzi ilin estas la plej ofta kaŭzo, kial fajroŝirmilo ŝajnas permesi ĉion dum klientoj ankoraŭ tempofinas.

Minimuma politiko akceptas novajn konektojn el la baseno al la elira interfaco kaj akceptas respondojn, kiuj apartenas al establitaj fluoj. Metu ĝin en tiun regul-aran posedanton, kiun uzas via distribuo, anstataŭ aldoni duobligitan regulon ĉe ĉiu praŝargo; duobligitaj reguloj amasiĝas kaj la nombriloj ĉesas signifi ion.

sudo iptables -A FORWARD -i tun0 -o eth0 -s 10.90.0.0/24 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Ŝalti ĉiun ĉenon al akcepto igas la teston sukcesi kaj forigas la kialon, pro kiu la fajroŝirmilo ekzistas. Tenu la amplekson al la baseno kaj la elira interfaco, kaj lasu nerilatan plusendon trankvila.

Donu al la respondoj lokon, kien iri

La adresoj de la baseno estas privataj, do publika servilo ne povas liveri respondon rekte al ili. Aŭ la VPN-gastiganto tradukas la fontadreson sur la elira vojo, aŭ aparato supre tenas itineron reen al la baseno.

sudo iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o eth0 -j MASQUERADE

Aldonu ĝuste unu tradukan tavolon. Dua NAT pli supre kaŝas la unuan kaj faras ambaŭ protokolojn preskaŭ senutilaj, kiam io poste rompiĝas. Se enkursigilo supre jam enkursigas la basenon reen, aldoni tradukon sur la gastiganto estas superflua, kaj la revena vojo tiam dependas de la agordo de tiu enkursigilo anstataŭ de la via.

Nubaj instancoj aldonas ankoraŭ unu pordon, ĉar kelkaj platformoj forĵetas paketojn, kies fontadreso ne estas la propra de la instanco, se tiu kontrolo ne malstreĉiĝas. Tiu agordo staras ekster la gasto kaj facile forgesiĝas, kiam loka testa maŝino funkcias.

Pruvu ĝin el la kliento, ne el la ŝelo de la servilo

Komencu per numera peto IPv4, poste nomserĉo, poste la aplikaĵo. ping pruvas plusendon kaj tradukon;ĝi pruvas nenion pri nomresolvo, ĉar DNS-opcioj efikas nur kiam la klienta integriĝo instalas ilin.

curl -4 -m 5 http://198.51.100.10/
dig +short example.com

Notu la ŝanĝojn kaj la malfaran paŝon dum vi iras, por ke la elira politiko povu esti malfarita per unu ago, kiam testo malsukcesas. Ĉi tiu recepto kovras nur IPv4; inventaru IPv6 aparte antaŭ ol aserti, ke la deplojo portas la tutan trafikon.