UPDATE SSL CERTIFICATE & PRIVATE KEY BY OPTIMUS

 

การขโมย Password ในปัจจุบันนี้กลายเป็นภัยร้ายแรงไปซะแล้ว Private key เป็นกุญแจสำคัญของการเข้ารหัสข้อมูลด้วยใบรับรองอิเล็กทรอนิคส์ (SSL certificate) การเข้ารหัสด้วย Private key ทำให้เราสามารถส่งข้อมูลที่เป็นความลับข้ามเน็ตเวิร์คเปิดโล่งอย่างอินเตอร์เน็ตได้อย่างปลอดภัย

อย่างไรก็ดี Private key แปลตรงตัวว่า “กุญแจส่วนตัว” ก็พึงจะเก็บรักษาเอาไว้กับส่วนตัวเท่านั้น ใครที่ได้ข้อมูลที่เข้ารหัสไป ย่อมเปิดดูข้อมูลไม่ได้ เพราะไม่มี Private key เอาไว้ถอดรหัส ความเข้าใจนี้แปลได้ทันทีว่า Private key ไม่ควรจะถูกเปิดเผยต่อสาธารณะ และธุรกิจหนึ่งก็ไม่ควรจะไปล่วงรู้ Private key ของอีกธุรกิจหนึ่งด้วย

ในอดีตที่การโจรกรรมทางอิเล็กทรอนิกส์ไม่รุนแรง ที่ออพติมุส เรามี Private key ให้ใช้ร่วมกันเพื่อทำให้ User authentication บน Firebox เกิดความสะดวก แต่สถานการณ์ในปัจจุบันเปลี่ยนไปแล้ว การโจรกรรมทางอิเล็กทรอนิกส์แพร่ไปบนทุกประเภทอุปกรณ์ ซึ่งอุปกรณ์เหล่านั้นทำงานในหลายระบบ ของทุก ๆ ธุรกิจ การจ้องขโมยรหัสผ่านกลายเป็นการโจรกรรมที่แพร่หลาย การรักษาความปลอดภัยจำเป็นจะต้องยกระดับตามภัยที่ลุกลาม ในที่สุดแล้ว เราจึงตัดสินใจที่จะยกเลิกการแชร์ Private key และเริ่มแต่วันนี้เป็นต้นไป Private key จะส่งมอบให้พร้อมกับ Certificate ที่ออกให้กับ Firebox เฉพาะกับองค์กรเท่านั้น

เรายังคงทำงานหนัก เพื่อให้แน่ใจว่า รูรั่วในระบบของคุณจะถูกปิด และธุรกิจของคุณจะปลอดภัยจากภัยคุกคาม

หาก Firebox ของคุณทำงานอยู่โดยที่คุณไม่แน่ใจว่า มี Certificate ที่ถูกต้องหรือไม่ หรือไม่เคยมี Certificate มาก่อน เราพร้อมช่วยจัดการให้ Firebox ของคุณมีและใช้ Certificate ที่ถูกต้องได้ ให้หน้า User login หรือ User authentication web page แสดงกุญแจสีเขียวบน Address bar แทนการแสดงคำเตือนที่หน้ากลัวบน Browser ของผู้ใช้ ติดต่อเราและทำให้ Firebox ของคุณปลอดภัยตั้งแต่วันนี้

หากลูกค้าต้องการความช่วยเหลือ สามารถติดต่อ OPT-Care ได้ที่แผนก Support  : act.optimus.co.th

02-2479898 ต่อ 87

[email protected]

 

 

คุณต้องรู้อะไรถึงจะก้ปัญหา Network ได้เก่ง ๆ


เก่งในที่นี้แปลว่า
 
แก้ได้เร็ว.. แก้แล้วจบ.. แก้เสร็จแล้ว.. สามารถทำกลับให้มีปัญหาเหมือนเดิมได้… และแก้ซ้ำอีกทีก็ได้ จนลูกค้าเลิกพูดว่า “เดี๋ยวคุณกลับไป มันก็จะเป็นอีก”
 
● เก่ง ยังแปลว่า เราจะอ้างว่าปัญหามันเกิดเพราะอะไร เราก็โชว์หลักฐานให้เห็นได้ ไม่ใช่พูดขึ้นมาลอย ๆ ว่า Firewall มัน RAM ไม่พอ 
● เก่ง แปลว่า เมื่อแก้ตามที่เราบอกว่าให้แก้แบบนี้ ปัญหามันจะต้องจบได้จริง ๆ
● เก่ง ยังสามารถบอกได้ว่า เดี๋ยวพอแก้แล้ว อะไรจะเกิด บอกก่อนจะลงมือ และพอลงมือแล้ว ก็เปิด Log ให้สามารถติดตามผล ชี้ชัดได้ว่า สิ่งที่ได้กล่าวเอาไว้นั้น ได้เกิดขึ้นจริง

#เก่ง ไม่ได้แปลว่า แก้ได้หมดทุกปัญหา แต่ปัญหาที่แก้ไม่ได้ สามารถอธิบายได้ว่า ทำไมถึงแก้ไม่ได้
 
เช่น แก้ไปจนถึงจุดที่แสดงได้ว่าเป็นปัญหาของเฟิร์มแวร์ โดยไม่ใข่แค่อ้างขึ้นมาลอย ๆ ให้พ้น ๆ ตัวเองไป แต่เป็นคำอ้างที่มีคำยืนยันเป็น Support case เปิดไปที่ Vendor และเขายอมรับว่า เฟิร์มแวร์มีปัญหาจริง  ซึ่ง Vendor รับเคสนั้นไว้เป็น Bug report 
 
และทั้งหมดของความเก่งนี้ สามารถเขียนเป็นรายงาน เป็นหลักฐานมอบให้ลูกค้า เผื่อว่าลูกค้ามีข้อสงสัย ก็ยังสามารถเอารายงานนั้นไปให้มืออาชีพคนอื่น ๆ ได้ดู ให้คนอื่นสามารถแสดงความคิดเห็นในลักษณะ Second opinion ได้ 
 
หลายครั้งที่ผมมักได้รับคำถามว่า “พี่เคยเจอเคสแบบนี้หรือเปล่า” หรือ “สรุปว่าเคสนี้แก้อย่างไร” ผมมักมีความวิตกที่จะให้คำตอบ ผมคิดว่าน่าจะเป็นความรู้สึกเดียวกันถ้าเราไปถามหมอว่า “หมอครับ สรุปว่าถ้าผมปวดท้อง ก็คือยาตัวนี้ใช่มั้ย จะได้จดเอาไว้ไปซื้อกินเอง” ผมรับรองว่า ไม่มีหมอคนไหนจะตอบว่าใช่ หรือไม่ใช่ หมอคงจะตอบว่า “ปวดท้องครั้งหน้า มาหาหมอดีกว่านะครับ”
 
เพราะประสบการณ์ ไม่ใช่ส่วนสำคัญของการแก้ปัญหา Network ได้เก่ง ๆ ครับ จริง ๆ แล้วมันเป็นส่วนเล็กมาก ๆ เอาซะ 10% ก็พอแล้ว แล้วอะไรคือ 90% ของสิ่งที่จำเป็นในการแก้ปัญหา Network
 
ผมว่า การบอกได้ว่า สิ่งที่ถูกต้องนั้น “ขั้นตอนอย่างละเอียด” นั้นเป็นอย่างไร เป็นเรื่องสำคัญมาก จะยกให้สูงถึง 80% ยังได้เลย 
 
มาดูกันง่าย ๆ เอาแค่ ping นะครับ ผมเคยตั้งคำถามสนุก ๆ ถามคนที่ทำงาน Network ด้วยกันว่า IP-A ping IP-B มันเกิดอะไรขึ้นบ้าง
 
คำตอบที่ได้ก็คือ เครื่อง IP-A มันก็จะส่งไปบอกเครื่อง IP-B ให้ตอบ ping กลับมา ซึ่งผมก็ถามต่อไปว่า “บอกยังไง” บางคน (ส่วนน้อย) สามารถไปต่อได้โดยการตอบกลับมาว่า “ใช้ ping packet” ผมก็ยังดันจะถามต่อไปอีกว่า “ping packet หน้าตาเป็นอย่างไร แสดงให้ดูหน่อย” น้อยคนที่จะไปต่อได้ถึง 3 คำถาม ซึ่งผมสามารถจะลากต่อไปได้ถึง 15 คำถาม โดยทุก ๆ คำถาม ก็วนอยู่ในแค่ ping เรื่องเดียวนี่แหละครับ
 
ที่น่าสนใจคือ ใคร ๆ ก็ตั้งคำถามกับตัวเองได้ทั้งนั้นครับ จะศึกษาอะไร ลองตั้งคำถามกวนความรู้ของตัวเองอย่าให้มันตกตะกอน อย่าหยุดแค่เท่าที่อ่าน อย่าหยุดเท่าที่คิดว่ามันใช่ ซึ่งถ้าคุณอ่านแบบไม่หยุดถามนะ ด้วยคำสั่ง Ping คุณจะได้เรียนรู้เรื่องต่าง ๆ เหล่านี้แถมมาด้วย
– Routing table
– IP subnet และ calculation ของ subnet
– ARP cache
– ARP table
– ขบวนการของ ARP request / reply
– ICMP protocol และวิธีการใช้ Protocol นี้เพื่อเป็น Control Message ที่นอกเหนือจาก ping
และถ้าถามไปลึกมากจริง ก็จะเลยเถิดไปอ่านเรื่องของวิธีการทำงานของสวิตช์ ก็จะได้รู้เรื่องของ Dynamic MAC memory บนสวิตช์ด้วย
 
คนอื่นอ่านเรื่อง ping แบบไม่มีการตั้งคำถาม เขาจะใช้แค่ 30 นาที แต่ถ้าคุณอ่านแบบตั้งคำถามไปเรื่อย ๆ กวนประสาทตัวเองไปเรื่อย ๆ คุณจะใช้เวลา 1 สัปดาห์ในการอ่าน ping เรื่องเดียว
 
คนที่อ่านเรื่องพวกนี้ซ้ำแล้วซ้ำอีก ก็จะรู้ว่า ping มีขั้นตอนละเอียดยิก ๆ อะไรบ้าง พอคนแบบนี้เห็นปัญหา IP-A ping IP-B ไม่ได้ เขาจะนึกไล่ไปทีละขั้นตอนที่ละเอียดมาก ว่า IP-A จะ ping IP-B ได้นั้น จะต้องทำอะไรก่อน ต่อไปทำอะไร ก็ค่อย ๆ ไปไล่ดูว่า ที่ต้องทำนั้นได้ทำหรือยัง มันไปติดที่ตรงไหน
– Routing table ของเครื่องต้นทางเป็นอย่างไร
– IP-A มีการส่ง ARP request ออกไปตามหา Default gateway หรือ Destination IP หรือเปล่า
– มีอะไรอยู่ใน ARP cache ของ IP-A
– ARP reply กลับมาจาก MAC address มากกว่า 1 หรือเปล่า (IP ซ้ำกัน) หรือไม่มี ARP reply กลับมา
– เครื่องมีการส่ง ICMP request ออกไปหรือไม่
– ปลายทางได้รับ ICMP request หรือไม่ 
– ปลายทางส่ง ICMP reply กลับมาหรือไม่
– ต้นทางได้รับ ICMP reply กลับมาหรือไม่
 
นี่เป็นคร่าว ๆ ของคำถามว่า ping ไม่ได้ จะต้องเช็คที่ไหน เมื่อเช็คเจอแล้วว่า อะไรมันผิดพลาด ไม่ทำงานตามที่ควรจะเป็น การแก้ปัญหาก็จะแม่นตรง ไม่พลาด ไม่ต้องลอง บอกได้ล่วงหน้าว่า แก้แล้วจะจบหรือไม่จบ
 
ดังนั้น นอกจากจะรู้ว่า การทำงานที่ถูกต้องเป็นอย่างไรแล้ว ยังจะต้องรู้ด้วยว่า จะ Diag อย่างไร เช่น 
– Routing table ของเครื่อง A จะใช้คำสั่งอะไรเพื่อแสดงมันออกมา
– เราจะใช้ Utility หรือ Tool ตัวไหนในการแสดงว่า เครื่องส่ง ARP request ออกไปหรือไม่
– คำสั่งอะไรใช้แสดง ARP cache
ฯลฯ
 
การเรียนรู้เครื่องมือที่ใช้ในการ Diag ถือว่าเป็นอีกแค่ 10% ของการแก้ปัญหา Network ที่ผมให้แค่ 10% เพราะมันไม่ใช่เรื่องใหญ่ อยากรู้เมื่อไหร่ก็ถามเฮียกูเอาก็ได้ และในตลาดก็มีคนใช้ Diag tools พวกนี้ได้เป็นเยอะแยะอยู่แล้ว สะกิดถามคนข้าง ๆ หรือให้คนขาย remote มาทำให้ ก็ไม่ซับซ้อนยุ่งยาก แต่คนที่จะรู้ว่าต้องใช้ Tool นั้นเมื่อไหร่ เพื่อแสดงอะไร ตีความอย่างไร คนพวกเนี้ย…มีน้อยครับ
 
จะแก้ปัญหา Network ได้เก่งนะครับ อ่านเยอะ ๆ ตั้งคำถามแยะ ๆ โดยเฉพาะ Protocol ทั้งหลาย แล้วก็มาเรียนรู้วิธีการ Diag ของอุปกรณ์นั้น ๆ หรือ OS นั้น ๆ ส่วนใหญ่มักจะเป็นการเปิด Debug Log หรือ Diag screen หรือแสดง Status แล้วก็อ่านสิ่งที่แสดงนั้น ตามขบวนการของ Protocol ตรงนี้ใช้ประสบการณ์นิดหน่อยมาช่วยให้เราจับสิ่งที่ผิดปกติใน Log ได้เร็วขึ้น 
 
ส่วนใหญ่คนมักไม่ทนกับการอ่าน ทำให้รู้ Protocol ไม่ลึก แต่มักยินดีใช้เวลาเยอะกับการลงมือ คนส่วนใหญ่จึงมีความเชี่ยวชาญในการใช้ Diag tools เช่นการเปิดหน้าจอหรือพิมพ์ command line ได้อย่างคล่องแคล่ว ผลก็คือการจะแก้ปัญหา ก็มักจะลงมือซะมากกว่าจะใช้เวลาวางแผน และมักไปลงเอยด้วยการแก้ได้จากการใช้ประสบการณ์มากกว่าทฤษฎี ซึ่งก็โชคดีที่ความผิดพลาดใน Network นั้นมักเป็นปัญหาที่ซ้ำ ๆ กัน การลองทำในสิ่งที่เคยทำแล้วแก้ได้ จึงมักได้ผล แต่คนแก้ได้กลับอธิบายเป็นขั้นเป็นตอนไม่ได้ว่า ที่ได้ลงมือไปนั้น แก้ปัญหาได้อย่างไร 
 
รู้ต้นทางคือลงมือ รู้ปลายทางคือปัญหาจบ แต่ตรงกลางเกิดอะไรขึ้น หาจุดเชื่อมโยงไม่ได้ อธิบายไม่ค่อยเหมือนกันซักคนและไม่ค่อยเหมือนทฤษฎีของ Protocol นั้น ๆ ยิ่งถ้าให้หาอ้างอิงด้วยแล้ว เช่น Log หรือ Indicator อื่น ๆ มาประกอบการอธิบาย Development ของปัญหา น้อยคนที่จะหยิบหลักฐานมาประกอบเรื่องเล่าได้อย่างหนักแน่น 
 
ถ้าเคสนั้นแก้ไม่ได้ด้วยความคุ้นเคยหรือประสบการณ์ ก็มักจบท้ายด้วยการ Reboot ตามด้วยการเซ็ตใหม่หมด อาจต่อด้วยการเปลี่ยนอุปกรณ์ บางทีลองผิดลองถูกไปไม่รอด เลยเถิดไปโทษว่าอุปกรณ์ยี่ห้อนี้ไม่ดีเอาซะเลย แบบนี้ก็มีให้เห็นพอควร โดยเฉพาะถ้ามีกรอบเวลาเข้ามาเป็นแรงกดดัน ก็จะยิ่งได้เห็นทางออกที่แปลกประหลาดหลากหลายวิธี ยกเว้นวิธีที่จะใช้ทฤษฎีเข้ามาตั้งต้นขบวนการแก้ปัญหา
 
การแก้ได้เพราะประสบการณ์ เป็นสิ่งที่มีให้เห็นได้บ่อยครั้ง ทำให้คนหลงเชื่อไปว่า ประสบการณ์เป็นเรื่องสำคัญกว่าการทำความเข้าใจหลักการทำงานของ Protocol และ Process ผมเห็นหลายคนเน้นการลงมือลองเล่นอุปกรณ์ก่อนการอ่านทำความเข้าใจ ก็เข้าใจได้ว่ากำลังมุ่งจะเอาประสบการณ์จากอุปกรณ์ตัวนั้น อยากจะเซ็ตเป็น ว่ากันง่าย ๆ แต่ผลสุดท้ายเพราะไม่มีทฤษฎีกำกับ จึงเกิดการ “สร้างความเข้าใจขึ้นมาเอง” ว่าสิ่งที่เห็นจากการลองทำนั้น มันเป็นเพราะอุปกรณ์ทำงานแบบนี้ ผลิตความเข้าใจแบบที่ไปขัดแย้งกับหลักการทำงานจริงของ Protocol เรียกสั้น ๆ ว่า “มโน” 
 
มโน มันเป็น Inside-Out product ซึ่ง Outside-in process หรือความพยายามจะแกะมโนของคนนั้น มักไม่ได้ผล คนโบราณเขาเรียกว่า น้ำเต็มแก้ว แถมน้ำในแก้วยังกินไม่ได้ซะอีก เหตุนี้แหละครับ ที่ทำให้คนเก่งได้ยาก
 
● จะแก้ Network ได้เก่ง เริ่มจากสนใจ ต่อมาก็อ่านครับ อ่านแล้วถามแหย่ความรู้ของตัวเอง คุณจะพบจุดที่ไม่รู้ ก็อ่านต่อ หันมาอีกที คุณรู้ไปตั้งหลายเรื่องแล้ว เรื่องของการเซ็ตอุปกรณ์มันเรื่องเล็กมากครับ เรียนรู้ไม่กี่ชั่วโมงก็ทำได้แล้ว ยิ่งเป็นพวก Enterprise equipment จะยิ่งมี Diag tool ให้เลือกหลากหลายและมีประสิทธิภาพด้วย ยิ่งใช้เวลาเรียนรู้น้อยเข้าไปอีก
 
และก่อนจะลงมือแก้ปัญหาอะไร ให้คิดถึงขั้นตอนที่ถูกต้องของ Protocol และ Process เอาไว้ก่อน ถ้ารู้ไม่ครบ กลับไปอ่านก่อนครับ อย่าลงมือโดยไม่รู้หรือรู้ไม่ครบ เพราะมันคือต้นกำเนิดของความบรรลัยที่จะตามมา
 
#เสร็จแล้วไล่เช็คตาม Process ของ Protocol นั้นโดยไม่ใช้ประสบการณ์ สิ่งที่เราเห็นอาจไม่เหมือนสิ่งที่เราเคยทำ งัด Diag tool ขึ้นมาแสดงผลและสรุปด้วยหลักฐาน ก่อนจะก้าวไปเช็คในขั้นตอนถัดไปของ Protocol ทำไปทีละขั้นทีละตอน ฝึกแบบนี้ไปจนเป็นรูปแบบที่ถนัด ฝึกที่จะเชื่อประสบการณ์ให้น้อย ๆ และคิดไหลตาม Process ของ Protocol ให้มาก ๆ แล้วคุณจะเป็นคนที่แก้ปัญหา Network ได้เก่งครับ

เพิ่มระยะสาย LAN กับ POE EXTENDER

คุณเคยพบกับปัญหานี้หรือไม่?

 
• จุดที่ติดตั้งสายอุปกรณ์ที่ต้องใช้ POE ไกลเกิน 100เมตร
 
• ต้องจ้างผู้รับเหมา ให้เดินสายไฟเบอร์ใหม่ ก็จะเสียค่าใช้จ่ายเพิ่มขึ้นมาก
 
 

ปัญหาเหล่านี้จะหมดไป…

          

POE Extender คืออะไร

อุปกรณ์ POE Extender คือ อุปกรณ์เพื่อเพิ่มระยะสาย Lanพร้อมไฟ POE มาตรฐาน 802.3afไปกับสาย ได้ อีก 100 เมตร โดยไม่ต้องต่อปลั๊กไฟ

ทำไมต้องใช้อุปกรณ์ POE Extender?  

• ประหยัดค่าใช้จ่ายในการเดินสายไฟใหม่ในส่วนที่สาย Lanไปไม่ถึง
 
• สะดวกต่อการติดตั้ง
 
• ไม่ต้องเปลี่ยนจุดที่ทำการวางแผนที่ติดตั้งอุปกรณ์ต่างๆได้ เช่น Access Point

PoEExtender: INEO-01PEG

 
สนใจโซลูชั่นแบบนี้เรามีพันธมิตรพร้อมให้คำปรึกษา ติดต่อแผนก Marketing 

02-2479898 ต่อ 87

[email protected]

@optimusthailand