Virtio वर pfSense: offload बंद होईपर्यंत TCP थांबते
वर्च्युअलाइझ्ड pfSense पिंगला उत्तर देते आणि नंतर मोठ्या TCP वर थांबते। NIC बदलण्याऐवजी virtio चेकसम offload मार्ग बंद करा आणि खर्च मोजा।
एक क्लायंट सांगतो की टनेल जोडले जाते, पिंग उत्तर देते, लॉगिन पृष्ठ लोड होते आणि नंतर प्रत्येक प्रयत्नात हस्तांतरण त्याच ठिकाणी गोठते। हा नमुना आधीच खूप काही सांगतो: पोहोच कार्य करते आणि सतत थ्रूपुट करत नाही। फायरवॉल उघडण्यापूर्वी VPN या बिघाडात अजिबात सहभागी आहे का ते शोधा। त्याच गेटवेमधून मार्गात टनेल न ठेवता मोठे TCP पाठवा; तेही गोठले तर OpenVPN कधीच सहभागी नव्हते।
virtio नेटवर्क कार्ड वापरणाऱ्या pfSense गेस्टला नेमक्या त्याच स्वरूपात अपयशी होण्याचे खूप चांगले कारण आहे।
लहान पॅकेट जातात, मोठे TCP अडकते
हँडशेक, DNS उत्तरे आणि ICMP प्रतिध्वनी लहान असतात आणि सहसा जातात। सतत हस्तांतरणे गेस्टला विभाजन करण्यास भाग पाडतात आणि तिथेच खराब झालेला offload मार्ग समोर येतो। बिघाड सममितीय असणे आवश्यक नाही: बाहेर जाणारा रहदारी स्वच्छ असताना आत येणारा पडू शकतो, किंवा उलट, त्यामुळे वापरकर्ता लॉगिन करू शकतो आणि नंतर पहिल्या मोठ्या प्रतिसादावर थांबू शकतो। तोच क्लायंट दुसऱ्या गेटवेमधून कार्य करत असल्याने दोष नवीन घटकावर टाकला जातो।
म्हणून टनेलशिवाय गेटवे तपासा। काही सेकंद चालू शकेल इतकी मोठी LAN-वरून-WAN डाउनलोड पुरेशी आहे, आणि ती कोणत्याही सेटिंग बदलापूर्वी करावी लागते, म्हणजे नंतरची तुलना अर्थपूर्ण होईल।
offload प्रत्यक्षात काय वचन देते
virtio पॅराव्हर्च्युअल आहे: होस्ट आणि गेस्ट काम वाटून घेतात, होस्ट चेकसम आणि विभाजन क्षमता जाहीर करतो आणि गेस्टने सुरू केलेले पूर्ण करेल अशी अपेक्षा करतो। गेस्टचा स्टॅक तसे करत नसल्यास फ्रेम अपूर्ण चेकसमसह बाहेर पडतात किंवा होस्ट त्यांना टाकून देतो। एम्युलेटेड E1000 सोपे आणि संथ मॉडेल देते, ज्यात pfSense मध्ये एकही बदल न करता समस्या नाहीशी होते। क्षमता बोलणी प्रत्येक उपकरणासाठी स्वतंत्रपणे होते, यामुळे एक गेस्ट महिनोन्महिने चालते आणि त्याचा पुनर्निर्मित जुळा पहिल्याच दिवशी अपयशी होतो हे स्पष्ट होते।
ठरलेला संच हायपरवायझर आवृत्ती आणि निवडलेल्या NIC मॉडेलवर अवलंबून आहे, केवळ तुम्ही आयात केलेल्या कॉन्फिगरेशनवर नाही।
एक चेकबॉक्स virtio टिकवतो
pfSense इंटरफेसमध्ये, सिस्टम नंतर प्रगत नंतर नेटवर्किंगमध्ये हार्डवेअर चेकसम offload अक्षम करा नावाचा चेकबॉक्स आहे। तो निवडल्यास गेस्ट सॉफ्टवेअरमध्ये चेकसम मोजतो, जे pfSense मागील FreeBSD स्टॅक पॅराव्हर्च्युअल उपकरणाकडून अपेक्षित असलेल्याशी जुळते। त्याच पृष्ठावरील दोन संबंधित पर्याय हार्डवेअर TCP विभाजन offload आणि हार्डवेअर मोठ्या स्वीकृती offload व्यापतात। हँडशेक यशस्वी होतात पण मोठी हस्तांतरणे होत नाहीत तेव्हा त्यांच्याकडे वळा।
बदल करताना NIC virtio ठेवा। E1000 वर जाणे VM च्या संपूर्ण आयुष्यात प्रत्येक पॅकेटवर CPU जाळते आणि होस्ट वारसा म्हणून मिळणाऱ्या कोणापासूनही कॉन्फिगरेशनची समस्या लपवते, हा थोडा संथ पण अंदाजनीय डेटा मार्गापेक्षा वाईट सौदा आहे।
आत्ताच स्वीकारलेला खर्च मोजा
सॉफ्टवेअर चेकसमिंग काम गेस्टमध्ये हलवते, म्हणून काहीच खर्च नाही असे गृहीत धरण्याऐवजी नंतर थ्रूपुट मोजा। लहान VM वर दंड खरा आहे, पण तो दिसतो आणि स्थिर आहे, शांत नुकसानाच्या विरुद्ध। पूर्वी आणि नंतर इंटरफेस त्रुटी काउंटर आणि गेस्टचा कर्नल लॉग तुलना करा। ब्रिज फिल्टर करणारा हायपरवायझर वेगळ्या पुराव्यांसह स्वतंत्र बिघाड आहे आणि कोणताही offload ध्वज तो बरा करणार नाही।
प्रत्येक चाचणीत एक गोष्ट बदला आणि मेनू मार्ग, निवडलेला बॉक्स आणि मोजलेली संख्या लिहा। पुढील पुनर्निर्मित गेस्टला सामोरे जाणाऱ्याला तिन्ही लागतील।
BSD आधारित इतर फायरवॉल त्यांच्या स्वतःच्या इंटरफेस सेटिंग्जमध्ये समतुल्य नियंत्रण देतात, म्हणून मेनू मार्ग नसला तरी तर्क लागू राहतो।