VMware ไม่สามารถ ssh ให้แขก แต่ไม่สามารถ telnet

0

ฉันใช้งาน VMware Workstation 9.0.2 บน Windows 7 Professional ด้วยแขก CentOS 6.4 โดยใช้เครือข่ายเชื่อมต่อ LAN ที่โฮสต์ทำงานอยู่คือ 192.168.123. * โฮสต์เป็น IP แบบคงที่ 192.168.123.2 และแขกมี IP แบบคงที่ 192.168.123.70

ฉันสามารถ ปิง และ SSH จากโฮสต์ไปยังแขก CentOS แต่ Telnet และ http ทั้งสองล้มเหลวในการเชื่อมต่อ ฉันสามารถ telnet และ http จากแขกไปยังแขกโดยใช้ที่อยู่ 192.168.123.70 ดังนั้นพอร์ตของแขกจะเปิดแน่นอนและฟังอยู่

ไฟร์วอลล์ปิดใช้งานกับผู้เยี่ยมชมและไม่มีข้อความในบันทึกเมื่อ telnet ล้มเหลว (ไฟร์วอลล์ Windows ไม่ จำกัด การเชื่อมต่อขาออก)

ฉันไม่สามารถคิดอะไรที่สามารถอนุญาต ssh แต่ไม่อนุญาต telnet (ฉันสามารถเชื่อมต่อจากโฮสต์กับแขกเมื่อฉันใช้ telnet 192.168.123.70 22แต่ telnet 192.168.123.70 23 ไม่เชื่อมต่อ)

ข้อมูลอื่น ๆ :

นี่คือผลลัพธ์จาก /sbin/ifconfig -a จากแขก: 

eth0      Link encap:Ethernet  HWaddr 00:0C:29:1F:A5:E3  
          inet addr:192.168.123.70  Bcast:192.168.123.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:589132 errors:0 dropped:0 overruns:0 frame:0
          TX packets:292849 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:864633856 (824.5 MiB)  TX bytes:19627138 (18.7 MiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:275 errors:0 dropped:0 overruns:0 frame:0
          TX packets:275 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:121617 (118.7 KiB)  TX bytes:121617 (118.7 KiB)

นี่คือผลลัพธ์จาก netstat -l จากแขก: 

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address               Foreign Address             State      
tcp        0      0 *:8008                      *:*                         LISTEN      
tcp        0      0 *:8010                      *:*                         LISTEN      
tcp        0      0 *:8011                      *:*                         LISTEN      
tcp        0      0 *:http                      *:*                         LISTEN      
tcp        0      0 *:intu-ec-svcdisc           *:*                         LISTEN      
tcp        0      0 *:ssh                       *:*                         LISTEN      
tcp        0      0 election-t1,:ipp            *:*                         LISTEN      
tcp        0      0 *:https                     *:*                         LISTEN      
tcp        0      0 *:8030                      *:*                         LISTEN      
tcp        0      0 *:ssh                       *:*                         LISTEN      
tcp        0      0 *:telnet                    *:*                         LISTEN      
udp        0      0 *:ipp                       *:*                                     
udp        0      0 192.168.123.70:ntp          *:*                                     
udp        0      0 election-t1,:ntp            *:*                                     
udp        0      0 *:ntp                       *:*                                     
udp        0      0 *:ntp                       *:*

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

ภาคผนวก: เริ่มบริการ xinetd ใหม่บน guest และหยุด Windows Firewall บนโฮสต์ - ไม่มีผลเลย

ภาคผนวก 2: ผลลัพธ์ของ sudo iptables -L -n

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22 
REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited 

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited 

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
networking  ssh  vmware  telnet 
— Tom West
แหล่งที่มา
กรุณาโพสต์ผลลัพธ์ของ sudo iptables -L -n เมื่อดำเนินการกับแขก
— a CVn
เสร็จแล้ว ขอบคุณ ไม่แน่ใจในสิ่งที่ state NEW tcp dpt:22 หมายถึง แต่มันชี้ไปที่พฤติกรรมพิเศษโดย SSH กำลังตรวจสอบอยู่
— Tom West

คำตอบ:

1

เป็นการยากที่จะบอก (ฉันควรจะบอกว่าโพสต์ผลลัพธ์ของ sudo iptables -L -n -v ดังนั้นเราจึงเห็นตัวระบุส่วนต่อประสานแทน มันอาจจะเป็น lo ในกฎที่ดูเหมือนว่าจะยอมรับทุกอย่าง) แต่ดูเหมือนว่าไฟร์วอลล์บนผู้เยี่ยมชมกำลังบล็อกการเชื่อมต่อเนื่องจากเห็นได้ชัดว่าคุณมีความเกี่ยวข้องเท่านั้น state NEW tcp dpt:22 (อนุญาตการเชื่อมต่อ SSH ใหม่การเชื่อมต่อ TCP ที่มีอยู่ได้รับการจัดการโดยกฎข้อแรก)

ลองดำเนินการ sudo iptables -I INPUT 5 -p tcp --dport 80 -j ACCEPT และลองเชื่อมต่อจากโฮสต์อีกครั้ง ที่ควรอนุญาตให้คุณเชื่อมต่อผ่าน HTTP (ใน 5 วางไว้ตรงหน้า REJECT กฎ) หากใช้งานได้คุณจะต้องตรวจสอบวิธีการอนุญาตการเชื่อมต่อไปยังโฮสต์ใน telnet (23 / tcp), http (80 / tcp) และพอร์ต https (443 / tcp) ที่เป็นไปได้ (อาจมีวิธี CentOS แต่ฉันไม่คุ้นเคยกับ CentOS โดยเฉพาะ)

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

ฉันยังสังเกตเห็นว่าคุณมีกฎการปฏิเสธในตอนท้ายของห่วงโซ่การป้อนข้อมูลตามด้วยนโยบายการยอมรับ หากคุณไม่มีเหตุผลที่เฉพาะเจาะจงในการตั้งค่าด้วยวิธีดังกล่าววิธีปกติในการตั้งค่าการดำเนินการปฏิเสธเริ่มต้นคือเพียงแค่กำหนดนโยบายในห่วงโซ่ ( sudo iptables -P INPUT REJECT ควรทำ); ดังนั้นคุณไม่จำเป็นต้องมีกฎการปฏิเสธที่ชัดเจน

— a CVn
แหล่งที่มา
การปฏิเสธอย่างชัดเจนอยู่ที่นั่นเพื่อใช้ "การปฏิเสธด้วย icmp- โฮสต์ - ห้าม" และใช่การยอมรับทั้งหมดจะเป็นเพียงเพื่อ lo อินเตอร์เฟซ. นี่คือการตั้งค่ามาตรฐานสำหรับ iptables ใน CentOS มันจะยอมรับ SSH ขาเข้าและการเชื่อมต่อขาออกทั้งหมด
— Squeezy
@Squeezy ใช่ดังนั้น "ถ้าคุณไม่มีเหตุผลที่เฉพาะเจาะจงสำหรับการตั้งค่าแบบนั้น" หลายครั้ง (แม้ว่าจะไม่เสมอไป) นโยบายการปฏิเสธแบบง่ายก็เพียงพอแล้ว
— a CVn
เช่นนี้เป็นค่าเริ่มต้น iptables ใน CentOS ฉันสงสัยว่าเขาได้ตั้งค่าอะไร :)
— Squeezy
ขอบคุณ. แม้จะมีสิ่งที่ฉันคิดว่าถูกปิด iptables ( /etc/init.d/iptables save ติดตามโดย /etc/init.d/iptables save ) เห็นได้ชัดว่า iptables ยังคงทำงานอยู่ สำหรับการใช้ telnet นี่เป็นเซิร์ฟเวอร์ทดสอบภายในขนาดเล็กบน LAN ภายในเครื่อง การตอบโปรแกรมไม่ได้เป็นเชลล์จริงๆ แต่เป็นโปรแกรมแยกต่างหากที่เลียนแบบเซิร์ฟเวอร์เทลเน็ตสำหรับการเชื่อมต่อ แต่ไม่อนุญาตให้เข้าถึงระบบ เซิร์ฟเวอร์ที่ใช้งานภายนอกของเรานั้นเชื่อมต่ออยู่หลังไฟร์วอลล์ iptables เต็มรูปแบบที่อนุญาตให้โฮสต์ที่เฉพาะเจาะจงเชื่อมต่อด้วย ip เท่านั้น ขอบคุณมากสำหรับสิ่งนี้
— Tom West
0

หากสงสัยว่ามีการปิดกั้นไฟร์วอลล์คุณสามารถลองทดสอบ VMware บางส่วนได้ IsMyPortBlocked

คุณสามารถป้อนรายการพอร์ต TCP และ UDP ของคุณเอง

— Carl
แหล่งที่มา
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.