Nakarating ang OpenVPN client sa server pero hindi sa mga host ng LAN: checklist

Sinasabi ng client na konektado ito, sumasagot ang address ng tunnel sa ping, at walang sumasagot sa LAN ng opisina. Nakikita ko ito pagkatapos ng halos bawat pag-upgrade ng client, at ang unang instinct ay buksan ang firewall, na kadalasan ay maling hakbang: maayos ang tunnel, at ang putol ay nasa isa sa tatlong hop na dapat daanan ng packet. Lakarin ang ruta sa pagkakasunod-sunod na tinatahak ng packet, una ang ruta ng client, pagkatapos ang pagpapasa sa server, pagkatapos ang pagbabalik, at makikita mo ang may-ari ng depekto sa loob ng ilang minuto.

Unang hakbang: panoorin ang desisyon sa routing ng client

Bago hawakan ang server, patunayan na ipinapadala ng client ang packet sa tunnel. Itanong sa kernel kung aling interface ang gagamitin nito para sa isang partikular na host ng LAN, sa halip na basahin ang buong table:

ip route get 192.168.50.10

Kung pinangalanan ng sagot ang iyong pisikal na adapter at ang gateway ng opisina, walang pagbabago sa panig ng server ang makakatulong. Namamahagi lang ang OpenVPN ng ruta kapag itinutulak ito ng server, kaya hanapin ang push "route 192.168.50.0 255.255.255.0" sa configuration ng server, at pagkatapos ay ikonekta muli ang client. Karamihan sa mga client ay naglalapat ng mga itinulak na ruta kapag kumokonekta, hindi kapag ni-reload mo ang profile.

Sa Windows may ibang command ang parehong tanong. Ini-print ng Find-NetRoute -RemoteIPAddress 192.168.50.10 ang interface at ang susunod na hop na pipiliin ng stack, at ipinapakita ng route print -4 kung umiiral man ang itinulak na prefix.

Ikalawang hakbang: tiyakin na ipapasa ng server ang packet

Kung tama ang ruta ng client, narating ng packet ang server at dapat pumayag ang server na ipasa ito. Ang switch ng kernel ang unang gate, at dapat magbalik ng 1 ang sysctl net.ipv4.ip_forward. Gumagana ang pagtatakda nito gamit ang echo 1 > /proc/sys/net/ipv4/ip_forward hanggang sa susunod na reboot, at iyon ang dahilan kung bakit bumabalik ang parehong reklamo pagkalipas ng mga linggo.

Isulat ito sa lugar na nakakaligtas sa restart:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

Ang ikalawang gate ay ang filter table. Ang host na may naka-install na Docker ay madalas may FORWARD policy na DROP, at namamana ng desisyong iyon ang tunnel. Ipinapakita ng iptables -L FORWARD -v -n ang policy at ang mga counter ng packet; kung DROP ang policy, kailangan ng pagpapasa ng tahasang pahintulot para sa direksyon mula tunnel papuntang LAN at isa pa para sa sagot.

Ikatlong hakbang: sundan ang packet papunta sa LAN at hanapin ang sagot

Panoorin ang dalawang panig ng server nang sabay. Kunan sa tunnel at sa interface ng LAN, na-filter sa isang client at isang host para manatiling nababasa ang output:

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

Ang mga request na lumalabas sa tun0 at muli sa eth0 na may source na 10.8.0.x, na sinusundan ng katahimikan, ay nangangahulugang nakarating ang packet at pumunta sa ibang lugar ang sagot. Sinasagot ng host ng LAN ang default na gateway nito, walang ruta ang gateway na iyon para sa pool ng VPN, at namamatay ang sagot sa router ng LAN. Ang pag-ping sa host ng LAN mula sa server ay walang pinapatunay tungkol sa daang ito, dahil hindi kailanman tumatawid ang trapik na iyon sa tunnel.

Ikaapat na hakbang: pumili sa pagitan ng translation at ng isang return route

Dalawang pag-aayos ang nagsasara ng butas, at may mga kahihinatnan ang pagpili na lampas sa kung gumagana ang ping. Ginagawang maliwanag na sender ng source translation ang server:

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

Limitahan ang rule sa pool at sa interface ng LAN, pagkatapos gawin itong permanente, kung hindi ay tahimik na aalisin ng susunod na pag-reload ng firewall ang iyong fix. Ang halaga ay pagkakakilanlan: mukhang server ng VPN ang bawat client sa mga log ng LAN at sa mga access rule, at per-client policy becomes guesswork.

Ang static na ruta para sa 10.8.0.0/24 sa router ng LAN, na nakaturo sa server ng VPN, ay nagpapanatiling nakikita ang mga address ng client at ito ang mas mabuting pangmatagalang sagot kapag pag-aari mo ang router na iyon. Maraming site ang nagpapatakbo ng dalawa sa loob ng ilang panahon, NAT para sa agarang pag-aayos at ang ruta kapag naisulat na ang policy ng firewall. Kung ang server ay site-to-site peer at hindi pool, kailangan din ng panig ng server ng iroute para sa malayong subnet, kung hindi ay umiiral ang peer route pero hindi kailanman naiuugnay dito ang trapik ng client.

Ikalimang hakbang: i-verify mula sa client at itala kung ano ang nagbago

Isara ang loop mula sa client, hindi mula sa server. Kumonekta sa isang tunay na serbisyo sa host ng LAN, pagkatapos tiyakin na gumalaw ang mga counter ng translation gamit ang iptables -t nat -L POSTROUTING -v -n, dahil ang rule na walang packet ay rule na hindi kailanman tumugma. Ipinapakita ng conntrack -L -s 10.8.0.5 ang daloy at ang kalagayan nito kapag kailangan mo ng patunay na sinusubaybayan ang direksyon ng pagbabalik.

Mag-iwan ng tala sa configuration ng server: aling subnet, aling interface, aling rule, at kung may ruta pabalik ang router ng LAN. Sa susunod na burahin ng isang pag-upgrade ng client ang isang itinulak na ruta, gagawing isang linyang pag-aayos ng talang iyon ang isang sesyon ng pagpatay ng sunog.