کبرنیٹس کے ساتھ زندگی سے: کس طرح HTTP سرور نے ہسپانویوں کی حمایت نہیں کی۔

ہمارے کلائنٹ کے ایک نمائندے، جس کی ایپلیکیشن اسٹیک مائیکروسافٹ (Azure) سے کلاؤڈ میں رہتی ہے، نے ایک مسئلے کو حل کیا: حال ہی میں، یورپ سے کچھ کلائنٹس کی کچھ درخواستیں غلطی 400 کے ساتھ ختم ہونا شروع ہوئیں۔غلط فرمائش)۔ تمام ایپلیکیشنز .NET میں لکھی گئی ہیں، Kubernetes میں تعینات ہیں...

ایپلی کیشنز میں سے ایک API ہے، جس کے ذریعے تمام ٹریفک بالآخر آتی ہے۔ اس ٹریفک کو HTTP سرور کے ذریعہ سنا جاتا ہے۔ کیسٹریل.NET کلائنٹ کے ذریعہ ترتیب دیا گیا اور پوڈ میں میزبانی کی گئی۔ ڈیبگنگ کے ساتھ، ہم اس لحاظ سے خوش قسمت تھے کہ ایک مخصوص صارف تھا جس نے مستقل طور پر مسئلہ کو دوبارہ پیش کیا۔ تاہم، ٹریفک سلسلہ کی وجہ سے سب کچھ پیچیدہ تھا:

Ingress میں غلطی اس طرح نظر آئی:

{
   "number_fields":{
      "status":400,
      "request_time":0.001,
      "bytes_sent":465,
      "upstream_response_time":0,
      "upstream_retries":0,
      "bytes_received":2328
   },
   "stream":"stdout",
   "string_fields":{
      "ingress":"app",
      "protocol":"HTTP/1.1",
      "request_id":"f9ab8540407208a119463975afda90bc",
      "path":"/api/sign-in",
      "nginx_upstream_status":"400",
      "service":"app",
      "namespace":"production",
      "location":"/front",
      "scheme":"https",
      "method":"POST",
      "nginx_upstream_response_time":"0.000",
      "nginx_upstream_bytes_received":"120",
      "vhost":"api.app.example.com",
      "host":"api.app.example.com",
      "user":"",
      "address":"83.41.81.250",
      "nginx_upstream_addr":"10.240.0.110:80",
      "referrer":"https://api.app.example.com/auth/login?long_encrypted_header",
      "service_port":"http",
      "user_agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36",
      "time":"2019-03-06T18:29:16+00:00",
      "content_kind":"cache-headers-not-present",
      "request_query":""
   },
   "timestamp":"2019-03-06 18:29:16",
   "labels":{
      "app":"nginx",
      "pod-template-generation":"6",
      "controller-revision-hash":"1682636041"
   },
   "namespace":"kube-nginx-ingress",
   "nsec":6726612,
   "source":"kubernetes",
   "host":"k8s-node-55555-0",
   "pod_name":"nginx-v2hcb",
   "container_name":"nginx",
   "boolean_fields":{}
}

اسی وقت، Kestrel نے دیا:

HTTP/1.1 400 Bad Request
Connection: close
Date: Wed, 06 Mar 2019 12:34:20 GMT
Server: Kestrel
Content-Length: 0

یہاں تک کہ زیادہ سے زیادہ فعل کے ساتھ، Kestrel کی غلطی انتہائی موجود ہے۔ تھوڑی مفید معلومات:

{
   "number_fields":{"ThreadId":76},
   "stream":"stdout",
   "string_fields":{
      "EventId":"{"Id"=>17, "Name"=>"ConnectionBadRequest"}",
      "SourceContext":"Microsoft.AspNetCore.Server.Kestrel",
      "ConnectionId":"0HLL2VJSST5KV",
      "@mt":"Connection id "{ConnectionId}" bad request data: "{message}"",
      "@t":"2019-03-07T13:06:48.1449083Z",
      "@x":"Microsoft.AspNetCore.Server.Kestrel.Core.BadHttpRequestException: Malformed request: invalid headers.n   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.Http1Connection.TryParseRequest(ReadResult result, Boolean& endConnection)n   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.<ProcessRequestsAsync>d__185`1.MoveNext()",
      "message":"Malformed request: invalid headers."
   },
   "timestamp":"2019-03-07 13:06:48",
   "labels":{
      "pod-template-hash":"2368795483",
      "service":"app"
   },
   "namespace":"production",
   "nsec":145341848,
   "source":"kubernetes",
   "host":"k8s-node-55555-1",
   "pod_name":"app-67bdcf98d7-mhktx",
   "container_name":"app",
   "boolean_fields":{}
}

ایسا لگتا ہے کہ صرف tcpdump اس مسئلے کو حل کرنے میں مدد کرے گا ... لیکن میں ٹریفک چین کے بارے میں دہراؤں گا:

تفتیش

ظاہر ہے، ٹریفک کو سننا بہتر ہے۔ اس مخصوص نوڈ پر، جہاں Kubernetes نے ایک پوڈ تعینات کیا ہے: ڈمپ کا حجم ایسا ہو گا کہ کم از کم کچھ بہت جلد تلاش کرنا ممکن ہو گا۔ اور درحقیقت، اس کی جانچ کرتے وقت، مندرجہ ذیل فریم کو دیکھا گیا تھا:

GET /back/user HTTP/1.1
Host: api.app.example.com
X-Request-ID: 27ceb14972da8c21a8f92904b3eff1e5
X-Real-IP: 83.41.81.250
X-Forwarded-For: 83.41.81.250
X-Forwarded-Host: api.app.example.com
X-Forwarded-Port: 443
X-Forwarded-Proto: https
X-Original-URI: /front/back/user
X-Scheme: https
X-Original-Forwarded-For: 83.41.81.250
X-Nginx-Geo-Client-Country: Spain
X-Nginx-Geo-Client-City: M.laga
Accept-Encoding: gzip
CF-IPCountry: ES
CF-RAY: 4b345cfd1c4ac691-MAD
CF-Visitor: {"scheme":"https"}
pragma: no-cache
cache-control: no-cache
accept: application/json, text/plain, */*
origin: https://app.example.com
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.119 Safari/537.36
referer: https://app.example.com/auth/login
accept-language: en-US,en;q=0.9,en-GB;q=0.8,pl;q=0.7
cookie: many_encrypted_cookies; .AspNetCore.Identity.Application=something_encrypted; 
CF-Connecting-IP: 83.41.81.250
True-Client-IP: 83.41.81.250
CDN-Loop: cloudflare

HTTP/1.1 400 Bad Request
Connection: close
Date: Wed, 06 Mar 2019 12:34:20 GMT
Server: Kestrel
Content-Length: 0

ڈمپ کا قریب سے معائنہ کرنے پر یہ لفظ نظر آیا M.laga. یہ اندازہ لگانا آسان ہے کہ سپین میں M.laga شہر نہیں ہے (لیکن وہاں ہے۔ Malaga)۔ اس خیال پر قابو پاتے ہوئے، ہم نے Ingress کنفیگرز کو دیکھا، جہاں ہم نے ایک مہینہ پہلے داخل کی گئی (کلائنٹ کی درخواست پر) کو دیکھا۔ "بے ضرر" ٹکڑا:

    ingress.kubernetes.io/configuration-snippet: |
      proxy_set_header X-Nginx-Geo-Client-Country $geoip_country_name;
      proxy_set_header X-Nginx-Geo-Client-City $geoip_city;

ان ہیڈرز کے فارورڈنگ کو غیر فعال کرنے کے بعد، سب کچھ ٹھیک ہو گیا! (یہ جلد ہی واضح ہو گیا کہ ایپلی کیشن کو اب ان ہیڈرز کی ضرورت نہیں ہے۔)

اب آئیے مسئلہ کو دیکھتے ہیں۔ زیادہ عام طور پر. ٹیل نیٹ سے درخواست کرکے اسے آسانی سے ایپلی کیشن کے اندر دوبارہ تیار کیا جاسکتا ہے۔ localhost:80:

GET /back/user HTTP/1.1
Host: api.app.example.com
cache-control: no-cache
accept: application/json, text/plain, */*
origin: https://app.example.com
Cookie: test=Desiree

... واپسی 401 Unauthorized، توقع کے مطابق. کیا ہوتا ہے اگر ہم کریں:

GET /back/user HTTP/1.1
Host: api.app.example.com
cache-control: no-cache
accept: application/json, text/plain, */*
origin: https://app.example.com
Cookie: test=Désirée

?

لوٹے گا 400 Bad request - ایپلیکیشن لاگ میں ہمیں ایک ایسی غلطی موصول ہوگی جو ہمارے لیے پہلے سے واقف ہے:

{
   "@t":"2019-03-31T12:59:54.3746446Z",
   "@mt":"Connection id "{ConnectionId}" bad request data: "{message}"",
   "@x":"Microsoft.AspNetCore.Server.Kestrel.Core.BadHttpRequestException: Malformed request: invalid headers.n   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.Http1Connection.TryParseRequest(ReadResult result, Boolean& endConnection)n   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.<ProcessRequestsAsync>d__185`1.MoveNext()",
   "ConnectionId":"0HLLLR1J974L9",
   "message":"Malformed request: invalid headers.",
   "EventId":{
      "Id":17,
      "Name":"ConnectionBadRequest"
   },
   "SourceContext":"Microsoft.AspNetCore.Server.Kestrel",
   "ThreadId":71
}

کے نتائج

خاص طور پر Kestrel نہیں کر سکتا UTF-8 میں صحیح حروف کے ساتھ HTTP ہیڈر کو درست طریقے سے پروسیس کریں، جو کہ کافی بڑی تعداد میں شہروں کے ناموں میں موجود ہیں۔

ہمارے معاملے میں ایک اضافی عنصر یہ ہے کہ کلائنٹ فی الحال درخواست میں Kestrel کے نفاذ کو تبدیل کرنے کا ارادہ نہیں رکھتا ہے۔ تاہم، AspNetCore میں ہی مسائل (4318 №, 7707 №) وہ کہتے ہیں کہ اس سے کوئی فائدہ نہیں ہوگا...

خلاصہ کرنے کے لیے: نوٹ اب Kestrel یا UTF-8 (2019 میں؟!) کے مخصوص مسائل کے بارے میں نہیں ہے، بلکہ اس حقیقت کے بارے میں ہے کہ ذہن سازی اور مستقل مطالعہ مسائل کی تلاش کے دوران آپ جو بھی قدم اٹھاتے ہیں وہ جلد یا بدیر پھل لائے گا۔ اچھی قسمت!

PS

ہمارے بلاگ پر بھی پڑھیں:

• «Kubernetes کے آپریشن میں 6 تفریحی سسٹم کیڑے [اور ان کا حل]؛ "
• «Kubernetes ٹپس اینڈ ٹرکس: NGINX Ingress میں اپنی مرضی کے ایرر پیجز؛ "
• «Kubernetes کے لیے Ingress کنٹرولرز کا جائزہ اور موازنہ؛ "
• «Kubernetes نوڈس کے درمیان پنگ کی نگرانی کرنا - ہماری ترکیب؛ "
• «لینکس نیٹ ورک سب سسٹم کے بارے میں 3 غیر معمولی معاملات'.

ماخذ: www.habr.com