สถาปัตยกรรมและเทคโนโลยีของ SSH Everywhere

> บทความนี้อธิบายสถาปัตยกรรมโดยรวม โปรโตคอล และเทคโนโลยีที่ SSH Everywhere ใช้ ด้วยภาษาง่าย ๆ เหมาะกับผู้อ่านที่อยากรู้ว่า «มันทำงานอย่างไรกันแน่» ไม่จำเป็นต้องมีพื้นฐานทางเทคนิคก็อ่านเข้าใจได้

---

เข้าใจทั้งโปรเจกต์ในหนึ่งประโยค

SSH Everywhere คือแผงควบคุมปฏิบัติการระยะไกลสำหรับเซิร์ฟเวอร์/อุปกรณ์แบบครบจบในที่เดียว เทียบชั้น 1Panel / Baota ความสามารถหลักคือ: ไม่ว่าอุปกรณ์ของคุณจะอยู่มุมไหนของเครือข่าย——มี IP สาธารณะ ไม่มี IP สาธารณะ (อยู่หลัง NAT) หรือเป็นมือถือ Android——ก็จัดการมันได้จากแผงควบคุมเดียวนี้เหมือนใช้ SSH

ตัวแผงควบคุมติดตั้งอยู่บนเซิร์ฟเวอร์ที่มี IP สาธารณะเครื่องหนึ่ง (listen ที่ 0.0.0.0:5501) คุณเข้าถึงแผงควบคุมผ่านเบราว์เซอร์ แล้วแผงควบคุมจึงไปเข้าถึงอุปกรณ์เป้าหมายแต่ละเครื่องผ่าน «วิธีเชื่อมต่อ» ที่แตกต่างกัน

---

สถาปัตยกรรมโดยรวม (ดูภาพเดียวเข้าใจ)

┌─────────────────────────────────────────────────────────────┐
│  ฟรอนต์เอนด์เบราว์เซอร์ (single-page app จำลองระบบปฏิบัติการเดสก์ท็อป)  │
│  หน้าต่างเดสก์ท็อป · แถบงาน · เมนูเริ่ม · แดชบอร์ดการ์ด                │
│  · เทอร์มินัลจริง · คลังไอคอน · JS ล้วน (ไม่มีเฟรมเวิร์ก)               │
└──────────────────────────┬──────────────────────────────────┘
                           │ HTTP REST + SocketIO
┌──────────────────────────┴──────────────────────────────────┐
│  แบ็กเอนด์แผงควบคุม (Flask + Flask-SocketIO, Python)          │
│  โปรแกรมหลัก · เซิร์ฟเวอร์อุโมงค์ย้อนกลับ · เซิร์ฟเวอร์ SocketIO · ส่งไฟล์ │
│  ป้องกันการล่ม · จัดการเว็บไซต์ · สำรองข้อมูล · ฐานข้อมูล SQLite      │
└───┬───────────────┬──────────────────┬──────────────────────┘
    │ SSH           │ อุโมงค์ย้อนกลับ   │ SocketIO
    │ ตรง/ผ่านอุโมงค์ │ (0.0.0.0:4433)   │ (ผ่าน HTTP)
    ▼                ▼                  ▼
┌────────┐    ┌──────────────┐    ┌─────────────────┐
│ มี IP สาธารณะ │    │ Linux ไม่มี IP สาธารณะ │    │ มือถือ Android │
│ เซิร์ฟเวอร์    │    │ /NAS/ราสเบอร์รีพาย      │    │ (Termux)       │
└────────┘    └──────────────┘    └─────────────────┘

---

วิธีเชื่อมต่อ 4 แบบ (โปรโตคอล)

ภายใน SSH Everywhere ใช้ 4 โปรโตคอล แต่ละตัวมีหน้าที่ของตัวเอง แยกตามอุปกรณ์แต่ละประเภท:

1. SSH —— ช่องทางหลัก

การใช้งาน: จัดการฟังก์ชันหลักของ «เซิร์ฟเวอร์ Linux ทั่วไป» ทั้งหมด

จัดการระบบ (ภาพรวม, โปรเซส, งานตามกำหนดการ, ไฟร์วอลล์, Docker, เว็บไซต์, แหล่งอิมเมจ, ป้องกันการล่ม)
เทอร์มินัล (interactive shell)
จัดการไฟล์ (อัปโหลด/ดาวน์โหลด/แก้ไข/บีบอัด)
ตรวจสุขภาพ (CPU/หน่วยความจำ/ดิสก์/อุณหภูมิ)
รันคำสั่ง

วิธีเชื่อมต่อ:

มี IP สาธารณะ: แผงควบคุมเชื่อมตรง host:port
ไม่มี IP สาธารณะ: แผงควบคุมสร้างพอร์ตพร็อกซีโลคัลผ่านอุโมงค์ย้อนกลับก่อน แล้วจึง SSH ต่อไป

> พูดอีกอย่าง แก่นแท้ของอุโมงค์ย้อนกลับคือ «ส่ง SSH ไปยังอุปกรณ์ที่ไม่มี IP สาธารณะ» ดังนั้น SSH จึงเป็นโปรโตคอลปลายทางสุดท้ายที่ลงมือจริง

2. โปรโตคอลอุโมงค์ย้อนกลับ —— ช่องทางทะลุ

การใช้งาน: ทำให้ «อุปกรณ์ที่ไม่มี IP สาธารณะ» ถูกแผงควบคุมเข้าถึงได้ ฝั่งอุปกรณ์จะ «เชื่อมออก» มาที่แผงควบคุมเอง สร้างการเชื่อมต่อ TCP ย้อนกลับแบบยาว แผงควบคุมส่งคำสั่งและส่งต่อพอร์ตผ่านอุโมงค์นี้

คุณสมบัติ: การเชื่อมต่อ TCP แบบยาว + เข้ารหัส (AES-256-GCM) ฝั่งเซิร์ฟเวอร์ listen ที่ 0.0.0.0:4433

สถานการณ์ทั่วไป:

ปฏิบัติการทะลุ NAT ผ่าน SSH ของเซิร์ฟเวอร์ Linux ที่ไม่มี IP สาธารณะ (รัน SSH ซ้อนในอุโมงค์)
ทะลุพอร์ต: แมปพอร์ตบริการบนอุปกรณ์ (เช่น 8090) ไปยังพอร์ตสาธารณะของแผงควบคุม

> แนวคิดที่มักสับสน: ส่งต่อพอร์ต vs ทะลุพอร์ต

> | | ส่งต่อพอร์ต | ทะลุพอร์ต |

> |---|---|---|

> | อุปกรณ์ที่ใช้ | เซิร์ฟเวอร์ที่มี IP สาธารณะ | อุปกรณ์ทะลุที่ไม่มี IP สาธารณะ |

> | วิธีทำ | DNAT ไฟร์วอลล์ระบบ ทำบนเครื่องเซิร์ฟเวอร์เป้าหมายเอง | ผ่านอุโมงค์ย้อนกลับ |

> | เส้นทางข้อมูล | ผู้เข้าถึง → IP สาธารณะเป้าหมาย → พอร์ตเป้าหมาย | ผู้เข้าถึง → พอร์ตสาธารณะแผงควบคุม → อุโมงค์ย้อนกลับ → พอร์ตอุปกรณ์ |

> | ต้องให้อุปกรณ์ออนไลน์ | ไม่ต้อง | ต้อง (อุปกรณ์ต้องให้ Agent ออนไลน์อยู่) |

> ประโยคเดียว: «ส่งต่อ» ใช้กับเซิร์ฟเวอร์ที่มี IP สาธารณะ; «ทะลุ» ใช้กับอุปกรณ์ที่ไม่มี IP สาธารณะ

3. SocketIO —— ช่องทางเฉพาะมือถือ Android

การใช้งาน: จัดการ Termux บนมือถือ Android เครือข่ายมือถือสลับ NAT บ่อย SSH ไม่เสถียร จึงใช้ช่องทาง long polling ของ SocketIO ที่เสถียร (เป็นวิธีที่ผ่านการทดสอบกับเครื่องจริงแล้ว)

Agent ที่รันบนมือถือ ให้บริการผ่าน SocketIO:

จัดการระบบ (ภาพรวม/โปรเซส/งานตามกำหนดการ)
เทอร์มินัล (บริดจ์ PTY)
จัดการไฟล์
มอนิเตอร์สุขภาพ (รายงานทุก 30 วินาที: โหลด/หน่วยความจำ/ดิสก์/แบตเตอรี่/อุณหภูมิ)

> นี่คือช่องทางเดียวในโปรเจกต์ที่ «ไม่ผ่าน SSH»——เพราะมือถือ Android ไม่ใช้ sshd แต่ใช้การเชื่อมต่อแบบยาวของ SocketIO

4. HTTP REST —— ระหว่างฟรอนต์เอนด์กับแบ็กเอนด์

ฟรอนต์เอนด์เบราว์เซอร์เรียกแบ็กเอนด์แผงควบคุมผ่าน REST API พร้อมใช้ SocketIO ทำการสื่อสารสองทางแบบเรียลไทม์เช่นเทอร์มินัล

---

ภาพรวมเส้นทางเข้าถึงอุปกรณ์ 3 ประเภท

ประเภทอุปกรณ์	วิธีเชื่อมต่อ	โปรโตคอลปลายทาง	คำอธิบาย
เซิร์ฟเวอร์ Linux ที่มี IP สาธารณะ	แผงควบคุมเชื่อมตรง	SSH	สถานการณ์ที่ตรงที่สุด
เซิร์ฟเวอร์ Linux ที่ไม่มี IP สาธารณะ (NAS/ราสเบอร์รีพาย ฯลฯ)	อุโมงค์ย้อนกลับสร้างพร็อกซี → SSH	SSH (ขนส่งผ่านอุโมงค์)	อุโมงค์เป็น «ผู้ขนส่ง» ของ SSH
มือถือ Android (Termux)	SocketIO long polling	SocketIO (ตัวเดียวที่ไม่ใช้ SSH)	ช่องทางเสถียรเฉพาะมือถือ

---

การจัดเก็บข้อมูล

ฐานข้อมูล SQLite (data/ssheverywhere.db): การ์ดเซิร์ฟเวอร์, ส่งต่อพอร์ต, บันทึกการทะลุ, ผู้ใช้, งาน ฯลฯ
ระบบไฟล์: ไฟล์สำรองข้อมูล, คีย์อุโมงค์, ทรัพยากรสแตติก

---

รูปแบบการติดตั้ง

แผงควบคุม: บริการ systemd ssh-everywhere.service listen ที่ 0.0.0.0:5501
อุโมงค์ย้อนกลับ: listen ที่ 0.0.0.0:4433
Agent ฝั่งอุปกรณ์เป้าหมายทำงานเป็นบริการถาวร (Linux ใช้ systemd / Termux ใช้ termux-services)

---

เกี่ยวกับชื่อโปรเจกต์ «SSH Everywhere»

ชื่อโปรเจกต์คือ SSH Everywhere หมายความว่า «จัดการได้ทุกที่เหมือนใช้ SSH» SSH เป็นวิธีเชื่อมต่อหลักอย่างแท้จริงของทั้งโปรเจกต์: นอกจากกรณีมือถือ Android กรณีเดียวแล้ว ฟังก์ชันอื่นทั้งหมด (จัดการเซิร์ฟเวอร์ Linux, ปฏิบัติการทะลุ NAT, ส่งไฟล์, ตรวจสุขภาพ) ล้วนลงเอยที่ SSH และแก่นแท้ของอุโมงค์ย้อนกลับก็คือ «ส่ง SSH ไปได้ทุกที่» เช่นกัน ดังนั้นชื่อ «SSH Everywhere» จึงสื่อความสามารถหลักของโปรเจกต์ได้อย่างแม่นยำ

เอกสาร