АртемЪ, VPN на длинном участве как раз позволяет избежать задержек.
Вероятность потери пакетов на пути от VDS до РФ гораздо выше-участок длиннее с большим количеством переходом. VPN решает эти вопросы самостоятельно, имея в своей структуре контроль ошибок и готовые пакеты, которые через NAT будут отдаваться клиентам.
В вашем случае NAT будет собирать все как есть - то есть если на длинном отрезке пути от VDS до РФ будут теряться пакеты - понятно это станет только у клиента, которому VDS просто будет отдавать полученное и передавать принятое.
Александр Чернышев,
1. эти "туповатые айтишники" - как вы выразились - наверняка специалисты в своем деле, занимающиеся безопасностью ваших клиентов, которую вы игнорируете.
2. Ваше непрофессиональное наплевательское отношение к безопасности ваших клиентов может аукнуться вам их потерей и потерей репутации.
3. Я комментирую это так, как считаю нужным. Для этого здесь комментарии и сделаны. Не устраивает - три точки - Пожаловаться и вперед.
4. Помощь вам оказали в ответе - вот только поможет ли она вам.
Александр Чернышев, да я вижу противоречие, когда люди работают с клиентами не только с тем, в чем разбираются, но и всем остальным - в чем не понимают ничего.
VDS в штатах - да, NAT с VDS в РФ - не согласен.
Оптимальнее от VDS до роутера локалки, где стоит SQL - все-таки VPN.
1. С точки зрения безопасности
2. С точки зрения стабильности соединения между длинным участком - где VPN по TCP будет ее давать. Либо наоборот VPN по UDP будет давать скорость соединения.
Какой интересный подход - зарубежные клиенты есть, но "Но я таких не знаю, в линуксах не разбираюсь почти" поэтому дайте мне бесплатные советы, я что-нибудь слеплю подешевле.
Потом правда с долей вероятности будете писать вопросы дальше-когда не будет стабильно работать или не дай бог проблемы с безопасностью будут.