Gateway ng VPN ng VirtualBox para sa LAN: tulay, ruta, pagbabalik
Itulay ang gateway VM sa LAN, ipahayag ang LAN sa mga client at idagdag ang ruta ng pool sa router ng LAN. Isang ginawang halimbawa ng IPv4 na may tunay na landas ng pagbabalik.
Kailangang maabot ng mga malayong user ang isang printer at file server sa pisikal na LAN, at ang tanging Linux box na laging bukas ay isang VM ng VirtualBox. Ang pagtulay sa VM papunta sa LAN na iyon ang unang kalahati. Ang ikalawang kalahati ay isang ruta ng pagbabalik na talagang gagamitin ng bawat device sa LAN, at iyon ang bahaging madalas kalimutan ng mga setup. Kapag wala ito, kumokonekta ang tunnel, pini-ping ng client ang gateway, at wala nang ibang sumasagot.
Gumamit ng mga address na maaabot
Itakda ang LAN adapter ng VM sa Bridged Adapter mode na aprubado para sa network na iyon, at bigyan ito ng address sa normal na proseso ng paglalaan. Pagkatapos, lumalabas ang VM sa pisikal na LAN tulad ng anumang ibang host. Dapat patuloy na gamitin ng default route nito ang tunay na gateway, upang manatiling maabot ang naka-encrypt na transport patungo sa VPN peer. Huwag gamitin ang default NAT address ng VirtualBox bilang susunod na hop para sa LAN, dahil nasa likod iyon ng virtual NAT at hindi on-link para sa host o sa ibang makina sa LAN.
LAN router: 192.168.70.1/24
VirtualBox host: 192.168.70.5/24
VPN gateway VM: 192.168.70.10/24
Example LAN service: 192.168.70.40
VPN client pool: 10.80.0.0/24
Suriin ang overlap sa mga home network ng malalayong user bago piliin ang pool ng address. Ang overlap ay nagiging kalabuan sa routing na walang anumang configuration ng server ang makakatama.
Ipahayag ang LAN, pagkatapos ay i-forward
Para sa isang server na ang authentication at transport ay pinamamahalaan na, ganito ang mga linya ng network. Sinasabi ng push sa tumatanggap na client kung paano maabot ang LAN, at hindi nito pinipilit ang VM na mag-forward ng anuman sa sarili nito.
dev tun
topology subnet
server 10.80.0.0 255.255.255.0
push "route 192.168.70.0 255.255.255.0"
Paganahin ang IPv4 forwarding sa permanenteng network configuration ng VM, at payagan ang pool ng client na maabot ang mga nilalayong serbisyo ng LAN sa hangganan ng forwarding ng VM. Ang pahintulot na maabot ang VPN listener ay hiwalay na tuntunin, at gumagana na ito kung tumaas ang tunnel.
Ang ruta ng pagbabalik ay nasa router ng LAN
Sumasagot ang mga device sa LAN sa pamamagitan ng kanilang default gateway, na siyang router ng LAN sa 192.168.70.1. Walang ideya ang router na iyon kung nasaan ang 10.80.0.0/24 maliban kung sabihin. Idagdag ang ruta ng pool sa sinusuportahang permanenteng configuration ng router, na nakaturo sa LAN address ng VM. Ang idagdag lamang ito sa host ng VirtualBox ay nag-aayos ng mga landas na nagtatanong sa host na iyon, at hindi iyon ang bawat device sa LAN.
ip route add 10.80.0.0/24 via 192.168.70.10
Kailangan pa ring payagan ng firewall ng destinasyon ang pool ng client bilang source. Dinadala ng ruta ang packet; hindi nito ibinibigay ang serbisyo.
Kung hindi mababago ang router ng LAN, ang limitadong source translation sa VM ang alternatibo. Pinapabalik nito ang mga sagot nang walang ruta, at itinatago ang mga indibidwal na address ng client mula sa serbisyo ng LAN.
Sundan ang isang packet mula simula hanggang dulo
Ang isang client sa 10.80.0.25 ay nagpapadala sa 192.168.70.40 sa pamamagitan ng tunnel. Ini-forward ng VM ang packet sa LAN. Sumasagot ang serbisyo sa router nito, na pumipili ng VM para sa pool ng client, at ibinabalik ng VM ang packet sa pamamagitan ng OpenVPN. Ang bawat hop sa pangungusap na iyon ay isang lugar kung saan maaaring mabigo ang disenyo.
Subukan gamit ang tunay na aplikasyon mula sa malayong client, pagkatapos ay ulitin matapos i-reload ang pinamamahalaang configuration sa VM at sa router.
Kung naaabot ng client ang VM ngunit hindi ang serbisyo, suriin muna ang ruta ng router. Kung natatanggap ng serbisyo ang kahilingan at hindi kailanman nakikita ng client ang sagot, ang landas ng pagbabalik ang pinaghihinalaan.