ปิดพอร์ตด้วยตนเองจาก commandline

112

ฉันต้องการปิดพอร์ตที่เปิดอยู่ซึ่งอยู่ในโหมดฟังระหว่างไคลเอนต์และแอปพลิเคชันเซิร์ฟเวอร์ของฉัน

มีตัวเลือกบรรทัดคำสั่งด้วยตนเองใน Linux เพื่อปิดพอร์ตหรือไม่

หมายเหตุ: ฉันรู้มาว่า "เฉพาะแอปพลิเคชั่นที่เป็นเจ้าของซ็อกเก็ตที่เชื่อมต่อเท่านั้นควรปิดซึ่งจะเกิดขึ้นเมื่อแอปพลิเคชั่นหยุดทำงาน"

ฉันไม่เข้าใจว่าเพราะเหตุใดจึงเป็นไปได้โดยแอปพลิเคชันที่เปิดขึ้นมา ... แต่ฉันก็ยังอยากรู้ว่าจะมีวิธีอื่นอีกหรือไม่

linux port sockets

— กลอร์ฟินเดล
แหล่งที่มา

5

ไม่พอร์ตที่เปิดอยู่เป็นของกระบวนการที่เปิดขึ้นมาจะไม่มีการควบคุมจากภายนอก ซึ่งเป็นสิ่งที่ดีหรือแอปพลิเคชันทั้งหมดจะต้องคาดหวังว่าพอร์ตที่เปิด (และไฟล์) ของพวกเขาจะถูกทำให้ยุ่งเหยิง อย่างไรก็ตามคุณสามารถบล็อกทราฟฟิกไปยังพอร์ตโดยไฟร์วอลล์ (iptables) แต่จะไม่ปิดและยอมแพ้พอร์ตสำหรับการใช้งานอื่น

— Jürgen Strobel

10

ผู้ตอบแบบสอบถามจำนวนมากพลาดจุดคำถามนี้ มันไร้สาระที่จะประกาศว่ามีเพียงแอปพลิเคชันที่เป็นเจ้าของพอร์ตเท่านั้นที่สามารถยกเลิกการเชื่อมต่อได้ ฉันสามารถตัดการเชื่อมต่อโดยการเดินไปที่กล่องและดึงสายอีเธอร์เน็ตออกจากซ็อกเก็ตหรือโดยการฆ่าแอปพลิเคชันที่ปลายอีกด้านของการเชื่อมต่อ! ต้องเขียนแอปพลิเคชันเพื่อจัดการสิ่งนี้ ดังนั้น --- คุณจะทดสอบอย่างไรเพื่อให้แน่ใจว่าแอปพลิเคชันนั้นเขียนอย่างถูกต้องโดยไม่ต้องมีการแทรกแซงทางกายภาพและ / หรือการควบคุมคอมพิวเตอร์เครื่องอื่น ๆ ?

— Dale Wilson

"... ไม่มีการควบคุมจากภายนอก" นั่นเป็นคำพูดที่สำคัญที่นำฉันไปยังคำถามต่อไปฉันจะเป็นส่วนหนึ่งของกระบวนการจากภายนอกได้อย่างไร GDB

— DankóDávid

@ JürgenStrobelมีการควบคุมที่เป็นไปได้จากภายนอก - ทั้ง tcpkill และ ss สามารถทำสิ่งที่ขอได้อย่างแน่นอน เนื่องจากพอร์ตที่เปิดไม่ได้เป็นของกระบวนการอย่างแท้จริง เป็นทรัพยากรเคอร์เนลโดยมีสิทธิ์บางอย่างที่กำหนดให้กับกระบวนการ แต่ยังคงมีอยู่ตามความพอใจของเคอร์เนลเท่านั้น

— Tom Anderson

@ tom-anderson DaleW: tcpkill เป็นเครื่องมือไฟร์วอลล์และฉันก็พูดถึงตัวเลือกนี้ คุณสามารถป้องกันการรับส่งข้อมูลไปยังพอร์ตซึ่งแตกต่างจากการปิดพอร์ต (ซ็อกเก็ต)

— Jürgen Strobel

134

ฉันมีปัญหาเดียวกันกระบวนการจะต้องมีชีวิตอยู่ แต่ซ็อกเก็ตจะต้องปิด การปิดซ็อกเก็ตในกระบวนการทำงานนั้นเป็นไปไม่ได้ แต่ยาก:

ค้นหากระบวนการ:
```
netstat -np
```
คุณได้รับsource/destination ip:port portstate pid/processnameแผนที่
ค้นหาไฟล์ descriptor ของซ็อกเก็ตในกระบวนการ
```
lsof -np $pid
```
คุณจะได้รับรายการ: ชื่อกระบวนการ, pid, ผู้ใช้, fileDescriptor, ... สตริงการเชื่อมต่อ

ค้นหาหมายเลข fileDescriptor ที่ตรงกันสำหรับการเชื่อมต่อ มันจะเป็นอะไรบางอย่างเช่น "97u" ซึ่งหมายถึง "97"
ตอนนี้เชื่อมต่อกระบวนการ:
```
gdb -p $pid
```
ตอนนี้ปิดซ็อกเก็ต:
```
call close($fileDescriptor) //does not need ; at end.
```
ตัวอย่าง:
```
call close(97)
```
จากนั้นแยก gdb:
```
quit
```
และซ็อกเก็ตถูกปิด

— DankóDávid
แหล่งที่มา

1

sudo lsof -np $pidให้ฉันประมาณ 200 บรรทัดและฉันสับสนเกี่ยวกับวิธีหา FD ที่ต้องการ ในกรณีของฉันคือแท็บ Chrome และฉันกำลังพยายามปิด websockets ที่เปิดอยู่ ...

— SET

2

แถวมักจะมีลักษณะดังนี้: Firefox 14812 szupervigyor 97u IPv4 32,814,564 0t0 TCP 192.168.2.4:40385->173.194.39.65:https (ถาวร) เช่นการใช้ pid process_name fd [opened_for] อุปกรณ์โปรโตคอล inode protocol_data_toString

— Danko Dávid

2

* แถวมักจะมีลักษณะเช่น: firefox 14812 szupervigyor 97u IPv4 32814564 0t0 TCP 192.168.2.4:40385-> 173.194.39.65:https (ESTABLISHED) เป็นอุปกรณ์ที่โปรโตคอลผู้ใช้ pd fd [open_for] โปรโตคอลอุปกรณ์ในโปรโตคอล ที่อยู่และค้นหาในคอลัมน์สุดท้าย ในตัวอย่างของฉัน 97 คือ FileDescriptor การค้นหายากถ้าคุณเปิดการเชื่อมต่อหลายรายการกับโฮสต์เป้าหมาย

— DankóDávid

7

นี่เป็นทางออกที่ยอดเยี่ยม

— marcorossi

8

หากคุณต้องการจำลองซ็อกเก็ตถูกปิดโดยสิ้นสุดระยะไกล (เช่นเพียร์ออก) มันจะดีกว่าที่จะใช้:shutdown call shutdown($fileDescriptor, 0)

— ecatmur

75

คุณกำลังถามคำถามผิดที่นี่ เป็นไปไม่ได้ที่จะ "ปิดพอร์ต" จากภายนอกแอปพลิเคชันที่เปิดซ็อกเก็ตกำลังฟังอยู่ วิธีเดียวที่จะทำเช่นนี้คือการฆ่ากระบวนการที่เป็นเจ้าของพอร์ตอย่างสมบูรณ์ จากนั้นประมาณหนึ่งหรือสองนาทีพอร์ตจะพร้อมใช้งานอีกครั้ง นี่คือสิ่งที่เกิดขึ้น (หากคุณไม่สนใจให้ข้ามไปยังจุดสิ้นสุดที่ฉันแสดงให้คุณเห็นวิธีฆ่ากระบวนการที่เป็นเจ้าของพอร์ตเฉพาะ):

พอร์ตคือทรัพยากรที่จัดสรรโดยระบบปฏิบัติการไปยังกระบวนการต่าง ๆ คล้ายกับการถามตัวชี้ไฟล์ อย่างไรก็ตามไม่เหมือนกับพอยน์เตอร์ของไฟล์กระบวนการเดียวเท่านั้นในแต่ละครั้งอาจเป็นเจ้าของพอร์ต ผ่านส่วนต่อซ็อกเก็ต BSD กระบวนการสามารถทำการร้องขอให้รับฟังพอร์ตซึ่งระบบปฏิบัติการจะให้อนุญาต ระบบปฏิบัติการจะตรวจสอบให้แน่ใจว่าไม่มีกระบวนการอื่นที่ได้รับพอร์ตเดียวกัน ณ จุดใด ๆ กระบวนการสามารถปล่อยพอร์ตโดยการปิดซ็อกเก็ต ระบบปฏิบัติการจะเรียกคืนพอร์ต อีกทางเลือกหนึ่งหากกระบวนการสิ้นสุดลงโดยไม่ปล่อยพอร์ตในที่สุดระบบปฏิบัติการจะเรียกคืนพอร์ตในที่สุด (แม้ว่าจะไม่เกิดขึ้นทันที: จะใช้เวลาสองสามนาที)

ตอนนี้สิ่งที่คุณต้องการ (เพียงปิดพอร์ตจากบรรทัดคำสั่ง) เป็นไปไม่ได้ด้วยเหตุผลสองประการ ขั้นแรกหากเป็นไปได้ก็หมายความว่ากระบวนการหนึ่งสามารถขโมยทรัพยากรของกระบวนการอื่น (พอร์ต) ได้ นี่จะเป็นนโยบายที่ไม่ดีเว้นแต่จะ จำกัด เฉพาะกระบวนการที่ได้รับการยกเว้น เหตุผลที่สองคือมันไม่ชัดเจนว่าจะเกิดอะไรขึ้นกับกระบวนการที่เป็นเจ้าของพอร์ตถ้าเราปล่อยให้มันทำงานต่อไป รหัสของกระบวนการเขียนโดยสมมติว่ามันเป็นเจ้าของทรัพยากรนี้ ถ้าเราเอามันออกไปมันจะจบลงด้วยตัวของมันเองดังนั้นระบบปฏิบัติการจะไม่ยอมให้คุณทำเช่นนี้แม้ว่าคุณจะเป็นกระบวนการที่มีสิทธิพิเศษก็ตาม คุณต้องฆ่าพวกมันแทน

อย่างไรก็ตามนี่คือวิธีฆ่ากระบวนการที่เป็นเจ้าของพอร์ตเฉพาะ:

sudo netstat -ap | grep :<port_number>

ที่จะส่งออกสายที่สอดคล้องกับพอร์ตการถือครองกระบวนการตัวอย่างเช่น:

tcp  0  0 *:8000   *:* LISTEN  4683/procHoldingPort

ในกรณีนี้procHoldingPortเป็นชื่อของกระบวนการที่เปิดพอร์ต4683เป็น pid และ8000 (โปรดทราบว่ามันคือ TCP) คือหมายเลขพอร์ตที่เก็บไว้

จากนั้นดูในคอลัมน์สุดท้ายคุณจะเห็น / จากนั้นดำเนินการนี้:

kill  <pid>

หากไม่ได้ผล (คุณสามารถตรวจสอบได้โดยเรียกใช้คำสั่ง netstat อีกครั้ง) ทำเช่นนี้:

kill -9 <pid>

โดยทั่วไปควรหลีกเลี่ยงการส่ง SIGKILL ถ้าทำได้ นี่คือเหตุผลที่ผมบอกให้คุณลองก่อนkill kill -9เพียงแค่ใช้killส่งอ่อนโยนกว่า SIGTERM

อย่างที่ฉันบอกไปมันจะใช้เวลาสักครู่ก่อนที่พอร์ตจะเปิดใหม่หากคุณทำเช่นนี้ ฉันไม่รู้วิธีที่จะเร่งความเร็วนี้ หากมีคนอื่นทำฉันชอบที่จะได้ยินมัน

— Guy Avraham
แหล่งที่มา

@smehmood - ขอบคุณสำหรับคำอธิบายโดยละเอียด .. มีข้อสงสัยเล็กน้อย .. เคอร์เนลเรียกคืนพอร์ตที่เปิดโดยกระบวนการที่ถูกฆ่าอย่างกระทันหันได้อย่างไร? .. วิธีแก้ปัญหาที่คุณให้ดูเหมือนจะเป็นการฆ่ากระบวนการที่ถือพอร์ต ...

3

@codingfreak เคอร์เนลรู้ว่ากระบวนการหายไป มันรู้ว่ามันสามารถเรียกคืนพอร์ต จริงๆแล้วมีกฎเกณฑ์เกี่ยวกับช่วงเวลาในการปิดพอร์ตเพื่อให้แน่ใจว่าไม่มีแพ็กเก็ตจรจัดที่ลอยอยู่บน 'สุทธิ มันรู้ได้อย่างไรว่ามีทรัพยากรเหล่านี้? นั่นคือสิ่งที่เคอร์เนลทำติดตามสิ่งต่างๆ

— Rich Homolka

จนกระทั่งคนโพสต์บางสิ่งบางอย่างที่เหมาะสมเช่นผมจะใช้unix.tools.port.close(<my port number>) init 6

— Snowcrash

นี่เป็นคำตอบที่ยอดเยี่ยมสำหรับคำถามอื่น คำถามนี้เกี่ยวกับการแนบดีบักเกอร์และการเปลี่ยนโปรแกรมที่กำลังรันอยู่เพื่อให้โปรแกรมนั้นเรียกใช้ฟังก์ชันบน file descriptor

— Arthur Ulfeldt

19

ฟิวเซอร์ยังสามารถใช้ได้

fuser -k -n *protocol portno*

นี่โปรโตคอลคือ tcp / udp และ portno คือหมายเลขที่คุณต้องการปิด เช่น

fuser -k -n tcp 37

ข้อมูลเพิ่มเติมได้ที่fuser man page

— RedBaron
แหล่งที่มา

แค่การฆ่ากระบวนการเป็นเจ้าของไม่ได้ผลสำหรับฉัน แต่ฟิวเซอร์ทำ ขอบคุณ!

— webwurst

ฉันได้ผลลัพธ์ที่หลากหลายด้วยหลังจากใช้ฟิวเซอร์ฉันได้รับ "ซ็อกเก็ตที่ใช้แล้ว" เมื่อพยายามใช้พอร์ตจากแอพที่ถูกฆ่าอีกครั้งแม้จะเป็นรูตก็ตาม ในทางกลับกันเวลาในการซ็อกเก็ตดูเหมือนจะสั้นลงก่อนหน้านี้แล้วดังนั้นขอบคุณ

— Jan Vlcinsky

@JanVlcinsky อาจจะมีกระบวนการ "ผู้พิทักษ์" ซึ่งจะรีสตาร์ทช่วงเวลาที่ถูกฆ่าหลังจากที่fuserถูกเรียกใช้?

— RedBaron

@ RedBaron: ตามความเห็นsuperuser.com/a/415236/153413ปัญหาของฉันมาในแอปพลิเคชันที่เขียนไม่ดีซึ่งไม่ได้ทำความสะอาด / ปิดซ็อกเก็ตภายใต้การยกเลิก ดังนั้นfuserค้นหากระบวนการโดยใช้พอร์ตและฆ่ามัน แต่ไม่สามารถแก้ไขความจริงที่ว่าซ็อกเก็ตไม่ได้ปิด 60 วินาทีและเคอร์เนลทำเพื่อฉัน

— Jan Vlcinsky

6

คุณสามารถใช้ iptables หรือ:

iptables -I INPUT -p tcp --dport 80 -j DROP

มันบรรลุสิ่งที่คุณต้องการ นี่จะลดทราฟฟิก TCP ทั้งหมดไปยังพอร์ต 80

— supercheetah
แหล่งที่มา

4

ไม่นี่จะทำให้ซ็อกเก็ตเปิดอยู่จนกว่าจะหมดเวลาทั้งหมด (มันจะซ่อนทราฟฟิกทั้งหมดจากกระบวนการที่เป็นเจ้าของซึ่งไม่มีวิธีที่จะรู้ว่ามันควรปิด) คุณสามารถใช้-j REJECTเพื่อคืนค่าสถานะ TCP รีเซ็ตซึ่งจะเห็นกระบวนการของฉันเป็นเจ้าของ (แต่เฉพาะเมื่ออีกด้านหนึ่งพยายาม เพื่อส่งบางสิ่ง)

— Marki555

3

netstat -anp | grep 80

ควรบอกคุณถ้าคุณใช้ apache "httpd" (นี่เป็นเพียงตัวอย่างให้ใช้พอร์ตที่แอปพลิเคชันของคุณใช้แทน 80)

pkill -9 httpd

หรือ

killall -9 httpd

— เบน
แหล่งที่มา

4

ลองฆ่าธรรมดาก่อนที่จะถึง -9

— Thilo

@omfgroflmao - แต่มันจะฆ่ากระบวนการที่ได้เปิดพอร์ตหรือไม่?

@codingfreak กระบวนการที่ถือพอร์ตใช่มันจะฆ่ามัน

2

คุณอาจจะเพิ่งรู้ว่ากระบวนการใดเปิดซ็อกเก็ตที่พอร์ตนั้นเชื่อมโยงกับและฆ่ากระบวนการนั้น

แต่คุณจะต้องตระหนักว่าถ้ากระบวนการนั้นมีตัวจัดการที่ยกเลิกการเริ่มต้นทุกสิ่งที่มันใช้ (เปิดไฟล์ซ็อกเก็ตส้อมส้อมสิ่งที่สามารถอื้ออึงได้เว้นแต่จะปิดอย่างถูกต้องเมื่อมีการยกเลิก) จากนั้นคุณจะสร้าง ลากประสิทธิภาพของระบบ นอกจากนี้ซ็อกเก็ตจะยังคงเปิดอยู่จนกว่าเคอร์เนลจะรู้ว่ากระบวนการนั้นถูกฆ่า ซึ่งมักใช้เวลาประมาณหนึ่งนาที

ฉันคิดว่าคำถามที่ดีกว่าคือ: คุณต้องการหยุดพอร์ตใด (อยู่ในกระบวนการใด)

หากคุณพยายามที่จะยุติการทำงานของแบ็คดอร์หรือไวรัสที่คุณพบคุณควรเรียนรู้อย่างน้อยข้อมูลที่จะย้อนกลับไปมาก่อนที่คุณจะยุติมัน (wireshark ดีสำหรับสิ่งนี้) (และชื่อปฏิบัติการของกระบวนการเพื่อให้คุณสามารถลบและป้องกันไม่ให้กลับมารีบูตได้) หรือถ้าเป็นสิ่งที่คุณติดตั้ง (เช่น HTTPD หรือ FTPD หรือบางอย่าง) คุณควรมีสิทธิ์เข้าถึง กระบวนการเอง

โดยปกติจะมีโปรแกรมควบคุม (HTTPD stop | start หรืออย่าง) หรือถ้าเป็นเรื่องของระบบคุณก็ไม่ควรยุ่งกับมัน อย่างไรก็ตามฉันคิดว่าเนื่องจากทุกคนให้มุม "วิธีการ" กับคุณฉันควรให้คำเตือนกับคุณ

— jackenheimer
แหล่งที่มา

ความคิดเห็นที่ดีมาก ฉันมีหนึ่งโปรแกรมซึ่งภายใต้การยุติจะปิดซ็อกเก็ตสิ่งที่ส่งผลให้พฤติกรรมที่อธิบาย - ซ็อกเก็ตใช้ไม่ได้ประมาณ 60 วินาที เมื่อฉันหยุดและเริ่มกระบวนการนั้นมันบ่นประมาณหนึ่งนาทีว่ามีการใช้ที่อยู่และพอร์ตแล้ว ทางออกที่ดีที่สุดคือการแก้ไขกระบวนการทำงานที่ไม่ดีให้ปิดอย่างถูกต้อง แต่บางครั้งนี่ไม่ใช่ตัวเลือก มีวิธีขอให้ตรวจสอบเคอร์เนลที่บล็อกซ็อกเก็ตเร็วกว่าใน 60 วินาทีหรือไม่?

— Jan Vlcinsky

2

ฉันแรกมองหากระบวนการ mongo และโหนดจากนั้นทำต่อไปนี้:

ps -A | grep node

10418 pts/23   00:00:05 node

10551 pts/23   00:00:00 node

ps -A | grep mongo

10490 pts/23   00:00:00 mongod

เมื่อระบุแล้วให้ฆ่ากระบวนการด้วยคำสั่ง kill

kill -9 10418
kill -9 10490

สุดท้ายพิมพ์meteorและควรจะทำงานอีกครั้ง

— abautista
แหล่งที่มา

1

คุณสามารถเขียนสคริปต์ที่ปรับเปลี่ยน iptables และรีสตาร์ทได้ หนึ่งสคริปต์สำหรับการเพิ่มกฎปล่อยแพ็กเก็ตทั้งหมดบนพอร์ตสคริปต์อื่นสำหรับการลบกฎดังกล่าว

คำตอบอื่น ๆ ได้แสดงวิธีฆ่ากระบวนการที่ผูกไว้กับพอร์ตซึ่งอาจไม่ใช่สิ่งที่คุณต้องการ หากคุณต้องการให้เซิร์ฟเวอร์ทำงานต่อไป แต่เพื่อป้องกันการเชื่อมต่อจากไคลเอนต์คุณต้องการบล็อกพอร์ตไม่ใช่หยุดกระบวนการ

— Michael Shimmins
แหล่งที่มา

@Michael Shimmins ... hmm ฟังดูน่าสนใจเพราะเราสามารถปิดกั้นพอร์ตทางฝั่งเซิร์ฟเวอร์เพื่อที่ลูกค้าจะไม่ส่งข้อความใด ๆ

ลูกค้าสามารถส่งข้อความทั้งหมดที่พวกเขาต้องการเราเพิ่งปิดประตูเพื่อให้พวกเขาไม่สามารถเข้ามาได้

1

ปัญหาอีกอย่างหนึ่ง: บางครั้งเคอร์เนลเป็นเจ้าของพอร์ตตัวเอง ฉันรู้ว่าการกำหนดเส้นทาง NAT เก็บพอร์ตบางพอร์ตไว้สำหรับการใช้ NAT คุณไม่สามารถฆ่ากระบวนการนี้นี่เป็นเคอร์เนลและการกำหนดค่าใหม่และจำเป็นต้องรีบูต

— รวย Homolka
แหล่งที่มา

1

หากคุณต้องการพอร์ตของคุณที่จะเปิดตัวเร็วคุณจะต้องตั้งค่าต่อไปนี้:

echo 1 > /proc/sys/net/ipv4/tcp_fin_timeout

เพื่อตั้งค่าจาก 60 วินาที (ค่าเริ่มต้น) ถึง 1 วินาที

— แดเนียล
แหล่งที่มา

1

คุณสามารถใช้คำสั่งชื่อ killcx ปิดการเชื่อมต่อโดยไม่ต้องมีกระบวนการใด ๆ ถูกฆ่า

ไวยากรณ์:

killcx [dest_ip:dest_port] {interface}

  dest_ip              : remote IP
  dest_port            : remote port
  interface (optional) : network interface (eth0, lo etc).

ตัวอย่าง:

killcx 120.121.122.123:1234
killcx 120.121.122.123:1234 eth0

— shuaiming
แหล่งที่มา

//, เครื่อง Linux ส่วนใหญ่มี killcx หรือไม่? ไม่มีสิ่งใดที่ฉันพยายามให้คำสั่ง killcx นี้พร้อมใช้งานโดยไม่ต้องติดตั้งแพ็กเกจไม่สามารถใช้งานได้ด้วยการกำหนดค่าที่เก็บปัจจุบัน

— นาธาน Basanese

ไม่คุณสามารถค้นหาเครื่องมือได้ที่นี่: killcx.sourceforge.net

— shuaiming

//, ฉันรู้ว่าฉันสามารถหาเครื่องมือนี้ได้มันเป็นแค่ความเจ็บปวดที่จะติดตั้งในเซิร์ฟเวอร์หลายพันเครื่อง

— นาธาน Basanese

ใช้ Puppet @NathanBasanese :)

— SHOUBHIK BOSE

1

ฉันรู้ว่าคำตอบนี้ไม่ได้ตอบคำถามตัวเองพูดอย่างเคร่งครัด แต่การอ่านมันอาจเป็นข้อมูลที่เกี่ยวข้อง:

พฤติกรรมเริ่มต้นของการผูกซ็อกเก็ตเข้ากับพอร์ต (และที่อยู่) คือเมื่อซ็อกเก็ตถูกปิดโดยการยกเลิกกระบวนการอย่างกะทันหันซ็อกเก็ตจะยังคงอยู่ใน TIME_WAIT ชั่วขณะหนึ่ง นี่จะหมายความว่าคุณไม่สามารถผูกที่อยู่ / พอร์ตนี้อีกครั้งได้ทันที หากคุณกำลังพัฒนาระบบผ่านทางอินเตอร์เฟสซ็อกเก็ต BSD มาตรฐานคุณสามารถ (อย่างน้อยถึงบางส่วน) ควบคุมพฤติกรรมนี้ด้วยตัวเลือกซ็อกเก็ต SO_REUSEADDR สิ่งนี้จะช่วยให้คุณสามารถผูกที่อยู่ / พอร์ตเดิมอีกครั้งหากซ็อกเก็ตอยู่ในสถานะ TIME_WAIT ยังคงหนึ่งซ็อกเก็ตต่อพอร์ต!

อย่างไรก็ตามข้อมูลนี้ควรใช้เพื่อเป็นเครื่องมือช่วยในการพัฒนาเนื่องจากมีเหตุผลที่ TIME_WAIT มีอยู่ตั้งแต่แรกอธิบายไว้แล้วในคำตอบอื่น ๆ

— Tommi Tuura
แหล่งที่มา

//, ใช่ แน่นอนกระบวนการฆ่าไม่ใช่วิธีที่ดีที่สุดในการเพิ่มพอร์ต ฉันสังเกตุเห็นว่าเมื่อฉันฆ่ากระบวนการ Vagrant ถ้ามันแฮงค์ฉันจะไม่สามารถออกไปอีกซักพักหนึ่งได้ ฉันพนันได้เลยว่าสิ่ง TIME_WAIT นี้เกี่ยวข้องกับมัน

— นาธาน Basanese

0

หากคุณต้องการเข้าชมมากกว่าซ็อกเก็ต แต่ไม่ต้องการที่จะให้มีชีวิตอยู่กระบวนการ: tcpkill

tcpkill -i eth0 host xxx.xxx.xxx.xxx and port yyyy

จะเริ่ม daemon การดมกลิ่นที่ดักและทิ้งการรับส่งข้อมูลทั้งหมดบนพอร์ตนั้น มีประโยชน์มากสำหรับการทดสอบแอปพลิเคชันของคุณสำหรับการแยกเครือข่าย

— RickyA
แหล่งที่มา

0

คุณสามารถปิดซ็อกเก็ตการฟังโดยใช้เอสเอส :

sudo ss --kill state listening src :1234

ที่ 1234 คือหมายเลขพอร์ตของคุณ

ss เป็นส่วนหนึ่งของแพ็คเกจ iproute2 ดังนั้นจึงมีการเปลี่ยนแปลงอย่างมากที่ติดตั้งไว้แล้วบน Linux ที่ทันสมัย

ผมได้เรียนรู้เกี่ยวกับเรื่องนี้จากคำตอบของคำถามที่เกี่ยวข้อง

— ทอมแอนเดอร์สัน
แหล่งที่มา