ब्लॉग को फिर से बनाना और स्टारलिंक से ConoHa VPS तक केवल TCP संचार न पहुँच पाने की समस्या का समाधान
नमस्ते, मैं मुनौ (Munou) हूँ।
काफी समय बाद अपडेट कर रहा हूँ। असल में, 2025 के उत्तरार्ध के कुछ लेख गायब हो गए थे, और अब मैं यहाँ हूँ।
Codex
हाल ही में मैंने Codex का उपयोग करना शुरू किया है और विकास का अनुभव इतना अच्छा है कि मैं पूरी तरह से इसमें डूब गया हूँ।
इसलिए, मैंने Lume CMS, जिससे मैं लंबे समय से असंतुष्ट था, से हटकर Codex का उपयोग करके अपने ब्लॉग को री-आर्किटेक्ट किया है।
SSG के Markdown में लिखना अच्छा है, लेकिन चूंकि मैं ज्यादातर ब्राउज़र से अपडेट कर रहा था, मुझे एहसास हुआ कि अपने सामान्य एडिटर, vim में लिखने का कोई मतलब नहीं है।
खासकर इमेज के साथ समस्या थी, जिससे ब्लॉग को आसानी से अपडेट करने का मन नहीं करता था...
कोड यहाँ उपलब्ध है, लेकिन वर्तमान में यह बग्स से भरा है।
GitHub - haturatu/alleycat: cms
ऐसा लग रहा था कि इसका रखरखाव (maintenance) फिर से शुरू किया जा सकता है, इसलिए मैंने इसे फिर से शुरू किया। हैरानी की बात यह है कि जब मैंने Reddit पर किसी ऐसे व्यक्ति को जवाब दिया जो फोर्क की तलाश में था, तो वह वही व्यक्ति निकला जिसने मेरे रिपॉजिटरी पर issue खोला था।
दुनिया वाकई छोटी है।
ConoHa VPS पर नेटवर्क पहुंच योग्य नहीं रहा
और फिर, अचानक एक समस्या आ गई।
ऐसा लगता है कि Path MTU Black hole की समस्या हो रही थी। यह वास्तव में अजीब था; जबकि WireGuard जैसे UDP संचार की आवश्यकता वाली चीजें और DNS सर्वर तक पहुंच काम कर रही थी, TCP की आवश्यकता वाले SSH और HTTP संचार पूरी तरह से विफल हो रहे थे।
चूंकि ConoHa VPS खुद FreeBSD पर होस्ट किया गया है, मैंने इसकी जांच की और पाया कि पैकेट फ़िल्टर ( pf ) की scrub सुविधा का उपयोग करके पैकेट को सामान्य (normalize) करके समस्या को हल किया जा सकता है, इसलिए मैंने इसे निम्नानुसार कॉन्फ़िगर किया:
set skip on lo
set block-policy drop
exsrv1 = dummy
insrv1 = dummy
insrv2 = dummy
wireguard_clients="{ dummy, dummy, dummy }"
wanint="vtnet0"
wg_ports="{51820}"
scrub in on $wanint all random-id max-mss 1360
scrub out on $wanint all random-id max-mss 1360
~~~इससे इनकमिंग और आउटगोइंग दोनों सामान्य हो जाते हैं और पैकेट सेगमेंट का आकार 1360 हो जाता है।
अजीब बात
इसके पीछे का कारण Starlink का CGNAT हो सकता है, ऐसी अटकलें हैं।
$ mtr -T -P 443 -n -r -c 2 163.44.113.145
Start: 2026-02-24T00:13:53+0900
HOST: thepassenger Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.1.1 0.0% 2 1.4 1.5 1.4 1.6 0.1
2.|-- 100.64.0.1 0.0% 2 19.3 19.4 19.3 19.4 0.1
3.|-- 172.16.251.26 0.0% 2 20.1 23.4 20.1 26.8 4.8
4.|-- ??? 100.0 2 0.0 0.0 0.0 0.0 0.0
5.|-- 206.224.70.186 0.0% 2 25.9 22.3 18.8 25.9 5.0
206.224.70.182
6.|-- 210.171.225.229 0.0% 2 23.0 22.7 22.4 23.0 0.4
7.|-- ??? 100.0 2 0.0 0.0 0.0 0.0 0.0
8.|-- 172.71.208.15 0.0% 2 24.9 23.1 21.3 24.9 2.5
162.159.109.42
9.|-- 172.71.4.38 0.0% 2 21.9 23.3 21.9 24.8 2.1
172.64.212.62
10.|-- 172.71.4.35 0.0% 2 63.3 43.8 24.2 63.3 27.7
172.70.221.227
11.|-- ??? 100.0 2 0.0 0.0 0.0 0.0 0.0
12.|-- 172.70.165.3 0.0% 2 44.7 39.8 35.0 44.7 6.9
13.|-- 150.95.7.204 0.0% 2 33.4 34.0 33.4 34.6 0.8
14.|-- 150.95.7.139 0.0% 2 39.2 50.3 39.2 61.4 15.7
15.|-- 150.95.7.147 0.0% 2 36.6 37.2 36.6 37.9 0.9
16.|-- 163.44.113.145 0.0% 2 34.2 35.8 34.2 37.5 2.3$ tracepath -n -m 30 163.44.113.145
1?: [LOCALHOST] pmtu 1500
1: 192.168.1.1 1.347 ms
1: 192.168.1.1 1.293 ms
2: 100.64.0.1 53.580 ms asymm 3
3: 172.16.251.26 37.025 ms
4: 206.224.70.208 34.552 ms (अपूर्ण राउटर ने दूषित डेटा लौटाया) asymm 7
5: 206.224.70.184 37.307 ms
6: 210.171.225.229 34.518 ms
7: कोई प्रतिक्रिया नहींवैसे तो मुझे लगा था कि स्टारलिंक और मेरे नेटवर्क वातावरण के लिए डिफ़ॉल्ट पैकेट आकार 1500 होने पर भी TCP संचार इसे ठीक से संभाल लेगा, लेकिन मुझे समझ नहीं आया कि इस महीने अचानक ConoHa VPS <-> Starlink के बीच ऐसा क्यों हुआ।
अगर मूल स्टारलिंक CGNAT में कोई समस्या होती, तो मुझे लगता है कि यह समस्या बहुत पहले ही आ जानी चाहिए थी, लेकिन यह इतनी अजीब घटना है कि मैं अभी भी उलझन में हूँ।