udptunnel
1.0.0
يحتوي هذا المستودع على تنفيذ بسيط لشبكة خاصة افتراضية من نقطة إلى نقطة عن طريق فتح جهاز TUN ونقل حركة المرور الأولية عبر UDP. تم تصميم شبكة VPN هذه لإنشاء نفق بين مضيفين:
يتم إرسال حركة مرور TUN حرفيًا بين نقطتي النهاية عبر حزم UDP غير المشفرة. وبالتالي، يجب استخدام هذا فقط في حالة تشغيل بروتوكول أكثر أمانًا (مثل SSH؛ راجع github.com/dsnet/sshtunnel) أعلى شبكة VPN هذه. من أجل منع المهاجمين من الاتصال بمآخذ توصيل أخرى مرتبطة محليًا على نقاط النهاية، تم تضمين مرشح منفذ بسيط لتقييد حركة مرور IP على المنافذ المحددة فقط. يجب على مستخدمي udptunnel أيضًا إعداد قواعد iptable كإجراء ثانوي لتقييد حركة المرور الضارة.
وهذا يدعم نظام Linux فقط.
بناء البرنامج الخفي:
go get -u github.com/dsnet/udptunnel
إنشاء ملف تكوين الخادم:
{
"TunnelAddress" : "10.0.0.1" ,
"NetworkAddress" : ":8000" ,
"AllowedPorts" : [ 22 ] ,
} يشير NetworkAddress الذي يحتوي على مضيف فارغ إلى أن البرنامج الخفي يعمل في وضع الخادم.
إنشاء ملف تكوين العميل:
{
"TunnelAddress" : "10.0.0.2" ,
"NetworkAddress" : "server.example.com:8000" ,
"AllowedPorts" : [ 22 ] ,
} من المفترض أن يتم حل المضيف server.example.com إلى عنوان ما حيث يمكن للعميل الوصول إلى الخادم.
ابدأ تشغيل البرنامج الخفي على كل من العميل والخادم (بافتراض أن $GOPATH/bin موجود في $PATH ):
[email protected] $ udptunnel /path/to/config.json
[email protected] $ udptunnel /path/to/config.json
حاول الوصول إلى نقطة النهاية الأخرى (على سبيل المثال، من العميل إلى الخادم):
[email protected] $ ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_req=1 ttl=64 time=56.7 ms
64 bytes from 10.0.0.1: icmp_req=2 ttl=64 time=58.7 ms
64 bytes from 10.0.0.1: icmp_req=3 ttl=64 time=50.1 ms
64 bytes from 10.0.0.1: icmp_req=4 ttl=64 time=51.6 ms
[email protected] $ nmap 10.0.0.1
Host is up (0.063s latency).
PORT STATE SERVICE
22/tcp open ssh
[email protected] $ ssh 10.0.0.1
Password: ...
يوضح المثال أعلاه العميل الذي يحاول الاتصال بالخادم، والذي يمكن توجيهه إلى 10.0.0.1 . يمكن تنفيذ أوامر المثال من الخادم عن طريق الاتصال بالعميل على 10.0.0.2 بدلاً من ذلك.
