რატომ VPN-ზე BGP არ აკონტროლებს თქვენს ქვედა დონის გზას
BGP VPN-ზე ცვლის ხელმისაწვდომობას და იყენებს მარშრუტის პოლიტიკას, მაგრამ ქვედა დონე მაინც ირჩევს გარე გზას. რას აკონტროლებს სესია სინამდვილეში.
ორი საიტი BGP-ს აკავშირებს IPsec გვირაბის გავლით, სწავლობს ერთმანეთის პრეფიქსებს, და დიაგრამა ხელახლა ეტიკეტდება როგორც გზის კონტროლი. სწორედ ეს ეტიკეტია არეულობის დასაწყისი. სესია ნამდვილად ცვლის ხელმისაწვდომობას და ნამდვილად იყენებს პოლიტიკას, მაგრამ მას არ აქვს სიტყვა იმაზე, რომელი მომწოდებელი, კაბელი თუ მარშრუტიზატორი ატარებს დაშიფრულ პაკეტებს. მე მინახავს გუნდი, რომელიც მუშა გვირაბს ხელახლა აშენებდა, რადგან ელოდა, რომ BGP მარშრუტის ცვლილება ტრაფიკს გადაიტანდა სხვა ბოჭკოვან გზაზე, რომელზეც სესია ვერასოდეს მოახდენდა გავლენას.
რას ფიქრობენ ადამიანები, რომ სესია ყიდულობს
მოლოდინის უმეტესი ნაწილი მოდის იქიდან, თუ როგორ გამოიყურება მარშრუტის ცვლილება ლაბორატორიაში. თქვენ აცხადებთ პრეფიქსს გვირაბის გავლით, შორეული მხარე აყენებს მას და ტრაფიკი მოძრაობს. იგივე თანმიმდევრობა ხდება მარშრუტიზატორზე, რომელსაც ნამდვილად აქვს ტრაფიკის ინჟინერიის ბერკეტები, ამიტომ ორივე ერევა ერთმანეთს. ლაბორატორიაში ორივე საიტი ჩვეულებრივ ერთ შესვლის ხაზს იზიარებს, და სწორედ ამიტომ არ ჩანს იქ განსხვავება არასოდეს.
BGP ხელმისაწვდომობის პროტოკოლია. ის ეუბნება პარტნიორს, რომ შეგიძლიათ პრეფიქსისთვის პაკეტები მიაწოდოთ, და აძლევს თითოეულ მხარეს მიღებული შეთავაზებების დალაგების საშუალებას. ეს ნამდვილად სასარგებლოა გვირაბის გავლით: პრეფიქსები ჩნდება და ქრება საიტების მოსვლა-წასვლასთან ერთად, და შეგიძლიათ დიაპაზონი უარყოთ ყოველ კიდურ მოწყობილობაზე სტატიკური მარშრუტის დაწერის გარეშე. რასაც ის არ აკეთებს, ეს არის მომწოდებლის მარშრუტიზატორების თქვენს კონტროლქვეშ მოქცევა.
ქვედა დონე ატარებს გარე სათაურს. თქვენი გვირაბის ბოლო წერტილი დაშიფრულ პაკეტებს უგზავნის პარტნიორის მისამართს, და ამ ორ მისამართს შორის არსებული ქსელი გადასცემს მათ იმ მარშრუტებით, რომლებიც მისმა ოპერატორებმა დააყენეს. BGP სესიაში არაფერი ცვლის ამ გადაწყვეტილებას, თუ იგივე მომწოდებელი არ შესთავაზებს მხარდაჭერილ სერვისს, რომელიც ამას აკეთებს.
რას ატარებს სესია სინამდვილეში
BGP მოსაუბრე ხსნის TCP კავშირს თავისი პარტნიორის 179 პორტზე, RFC 4271-ში განსაზღვრული შეტყობინების ფორმატებისა და გზის ატრიბუტების გამოყენებით. როდესაც პარტნიორის მისამართი გვირაბის შიგნითაა, გვირაბი აწეული უნდა იყოს და ეს მისამართი ხელმისაწვდომი, სანამ სესია საერთოდ დაიწყება. დასრულებული IKE გაცვლა BGP მეზობელი არ არის. მარშრუტზე დაფუძნებული IPsec იმპლემენტაციები ტრაფიკს გადის მხოლოდ მაშინ, როცა შესაბამისი გვირაბის მარშრუტი არსებობს, ხოლო პოლიტიკაზე დაფუძნებულს პარტნიორის მისამართი დაცული სელექტორის შიგნით სჭირდება. ამის პირიქით გაკეთება ქმნის კლასიკურ მდგომარეობას, როცა გვირაბი მწვანეა და სესია უსაქმოდ ზის.
როგორც კი სესია აწეულია, პოლიტიკა წყვეტს, რა გადის მასში. პრეფიქსების სიები, AS-გზის ფილტრები, მაქსიმალური პრეფიქსების ზედა ზღვარი და ნაგულისხმევ მარშრუტებზე ცალსახა გადაწყვეტილება მინიმუმია, და ისინი ორივე მიმართულებით მოქმედებს. პარტნიორი, რომელიც იღებს ყველაფერს, რასაც იღებს, შეიძლება მოგცეთ ნაგულისხმევი მარშრუტი, რომელიც ჩუმად ცვლის ლოკალურ ინტერნეტ წვდომას. ორ მიმართულებას ცალკე სიები სჭირდება, რადგან რასაც პარტნიორისგან იღებთ და რასაც მას აცხადებთ, ორი განსხვავებული გადაწყვეტილებაა.
router bgp 65010
neighbor 10.255.0.2 remote-as 65020
address-family ipv4 unicast
neighbor 10.255.0.2 prefix-list SITE-B-IN in
neighbor 10.255.0.2 prefix-list SITE-B-OUT out
neighbor 10.255.0.2 maximum-prefix 50
შემდეგ კბენს MTU. ინკაფსულაცია ამცირებს გამოსაყენებელ დატვირთვას, ამიტომ დიდმა განახლებამ შეიძლება გააჩეროს სესია, რომელიც სრულყოფილად დამკვიდრებული ჩანს: პარტნიორი რჩება ზემოთ, პრეფიქსები არასოდეს მოდის, და ჟურნალში არაფერი თვალსაჩინო არ ხვდება. შეზღუდეთ TCP MSS გვირაბის ინტერფეისზე, ან დააყენეთ გვირაბის MTU ზედნადებისთვის ადგილით, სანამ ფილტრებს დაადანაშაულებთ.
სად მიდიან გარე პაკეტები მაინც
დაშიფრული პაკეტები ერთი საიტიდან მეორეზე გადის იმ გზით, რომელსაც ლოკალური მარშრუტიზატორი ირჩევს პარტნიორის საჯარო მისამართისთვის. თუ ორივე საიტი ტრანზიტს ერთი და იმავე მომწოდებლისგან ყიდულობს, გადის იმავე მეტრო ობიექტზე, ან ერთი მხარე ოპერატორის დონის NAT-ის უკანაა, გვირაბი მომწოდებლის უკმარისობას მხოლოდ შემთხვევით გადაურჩება. მონიტორინგის ხელსაწყოში გვირაბის ხატულების დათვლა ამაზე არაფერს გეუბნებათ.
მარშრუტის შერჩევა და გადაგზავნის დაყენება ასევე ცალკე მოვლენებია. პრეფიქსი შეიძლება BGP ცხრილში საუკეთესოდ იჯდეს და მაინც აკლდეს გადაგზავნის ცხრილს, რადგან შემდეგი ნახტომი გადაუწყვეტელია ან უფრო კონკრეტული მარშრუტი იმარჯვებს. როცა ვინმე იტყობინება, რომ BGP-მ პრეფიქსი ისწავლა, მაგრამ ტრაფიკი არ მიედინება, სასარგებლო კითხვაა, დაყენებულია თუ არა და რომელ შემდეგ ნახტომზე მიუთითებს.
დიზაინის განხილვისთვის პატიოსანი პასუხი საერთო დამოკიდებულებების სიაა: შესვლის წრე, ზედა მომწოდებელი, ობიექტი და ნებისმიერი მდგომარეობის შემნახველი მოწყობილობა დაბრუნების გზაზე. გვირაბის გავლით სესია ვერ მოხსნის დამოკიდებულებას, რომლის ზემოთაც არ ზის.
გასაყოფი სამი გადაწყვეტილება
როცა დიზაინი ამას ერევა, ყოველი უკმარისობის საუბარი წრეზე ტრიალებს. ჯერ ქაღალდზე გაყავით ისინი, შემდეგ თითოეული დაუკავშირეთ მოწყობილობას, რომელიც ნამდვილად აღასრულებს მას.
| Decision | Who controls it | Typical failure |
|---|---|---|
| Which prefixes may cross the relationship? | Both sides, through prefix and AS-path policy you configure deliberately | A default route accepted by mistake, or a vague aggregate |
| Which overlay next hop wins? | Local BGP selection plus next-hop resolution on your own routers | Prefix learned, never installed in the forwarding table |
| Where do the encrypted packets travel? | The underlay operators, unless a supported service adds real control | Path diversity that was never there |
ყოველ სტრიქონს სხვა მფლობელი ჰყავს. პირველი მოლაპარაკებაა, მეორე თქვენი მოწყობილობების კონფიგურაცია, მესამე ძირითადად სხვისი ქსელია. ცვლილების მოთხოვნა, რომელიც ასახელებს მის მიერ შეხებულ სტრიქონს, ბევრად უფრო ადვილი დასამტკიცებელია, ვიდრე ის, რომელიც ამბობს BGP პრობლემა.
დაგეგმვის ღირსი უკმარისობის რეჟიმები
პარტნიორის შემაჯამებელი მარშრუტის მიღება ყველაზე გავრცელებული თვითდატანილი ჭრილობაა. ვიღაც აცხადებს მოკლე აგრეგატს გაცვლის გასამარტივებლად, შორეული მხარე იღებს მას, და გვირაბის უკან არმყოფი დიაპაზონების ტრაფიკი მიჰყვება გვირაბს და იღუპება. გაფილტრეთ ზუსტად მოსალოდნელ პრეფიქსებზე, ან გამოიყენეთ სწორი საზღვრებით პრეფიქსების სია, და არასოდეს მიიღოთ შიშველი აგრეგატი, რადგან ის სესიას მოწესრიგებულად აჩვენებს.
გაუქმების დრო მეორეა. აღმოჩენა დამოკიდებულია დაკავების ტაიმერებზე, BFD-ზე თუ ჩართეთ, გვირაბის მკვდარი პარტნიორის აღმოჩენაზე და იმაზე, რამდენად სწრაფად წყვეტს შორეული მხარე გამოცხადებას. არსებული სესიები ცალკე პრობლემაა: ახალმა მარშრუტმა შეიძლება აღადგინოს ახალი კავშირები, მაშინ როცა დამკვიდრებული TCP სესიები კვლავ ძველ მისამართებს იყენებენ, და გზაზე არსებულმა მდგომარეობის შემნახველმა ფაირვოლებმა ან NAT-მა შეიძლება შეინახოს ჩანაწერები, რომლებიც აღარ ემთხვევა. მარშრუტის ცვლილება ყველაფერს აგვარებს-თქო ვარაუდის ნაცვლად, აპლიკაციის აღდგენა მიღების კრიტერიუმებში ჩადეთ.
მესამეა დაბრუნების გზის ასიმეტრია. ტრაფიკი შეიძლება მოვიდეს გვირაბით და დაბრუნდეს მომწოდებლის ხაზით, რომელიც არასოდეს ყოფილა განკუთვნილი მის სატარებლად, რაც ვლინდება როგორც ცალმხრივი ხმა, წარუმატებელი ხელის ჩამორთმევა ან პასუხების გადამტოვნელი ფაირვოლი. შეამოწმეთ ორივე მიმართულება ცალ-ცალკე.
რა ჩავწეროთ კონტრაქტში და როგორ შევამოწმოთ
მოითხოვეთ დაშვებული პრეფიქსები წერილობით: ვის აქვს უფლება შექმნას ყოველი დიაპაზონი, დაშვებულია თუ არა ნაგულისხმევი მარშრუტი და რომელ მისამართების ოჯახებს უჭერს მხარს გვირაბის სერვისი. RFC 8212-მა ცალსახა იმპორტისა და ექსპორტის პოლიტიკა eBGP-ის მოლოდინად აქცია იმ იმპლემენტაციებში, რომლებიც მას მიჰყვებიან, ამიტომ პარტნიორი, რომელიც ჯერ კიდევ იმპლიციტურ ყველაფრის-მიღების ქცევას ეყრდნობა, კითხვის ღირსია.
შემდეგ შეამოწმეთ მოწყობილობიდან და არა დიაგრამიდან. სასარგებლო ბრძანებები FRR ტიპის მარშრუტიზატორებზე:
show bgp summary
show bgp ipv4 unicast 10.10.0.0/16
show bgp ipv4 unicast neighbors 10.255.0.2 advertised-routes
show ip route 10.10.0.0/16
დაამატეთ ორი დაკვირვება, რომელსაც მარშრუტიზაციის ცხრილი ვერ მოგცემთ. ჩაიწერეთ გარე ინტერფეისზე, რომ დაადასტუროთ, რომელ მისამართს მართლაც მიმართავს ინკაფსულირებული პაკეტები, მაგალითად tcpdump -ni eth0 udp port 51820 WireGuard გვირაბისთვის, ან ESP ფილტრი IPsec-ისთვის. შემდეგ გაატარეთ კვალი პარტნიორის საჯარო მისამართისკენ და შეადარეთ ნახტომები გვირაბის შიგნით გაკეთებულ კვალს; თუ ორივე ერთი და იმავე მომწოდებლის ჯაჭვს მიჰყვება, თქვენი სიჭარბე მარშრუტის პოლიტიკაში ცხოვრობს და არა ქსელში.
დაბოლოს, განზრახ გამოსცადეთ გაუქმება. ჩამოწიეთ გვირაბი ტექნიკური მომსახურების ფანჯარაში, ჩაწერეთ რამდენ ხანს რჩება პრეფიქსი დაყენებული, რა ხდება არსებულ სესიებთან და უბრუნდება თუ არა შორეული მხარე მარშრუტს, რომელსაც ნამდვილად მიიღებდით. ეს ვარჯიში დიზაინზე მეტს ამბობს, ვიდრე ნებისმიერი დიაგრამა.
მარშრუტი ნებართვა არ არის. პრეფიქსები, რომელთა გაცვლაზეც თანხმდებით, არაფერს ამბობს იმაზე, რომელი მომხმარებლები შეიძლება მივიდნენ გვირაბის უკან რომელ სერვისამდე, ამიტომ ავთენტიფიკაცია, დაშვებული სერვისები და ჰოსტის ფაირვოლები ზუსტად იქ დატოვეთ, სადაც იყო. ხელმისაწვდომი პარტნიორი ასევე არ არის შეუზღუდავი ტრანზიტის ან თვითნებური მისამართების შექმნის ნებართვა, და ასეთი უფლებამოსილება კონტრაქტში ეკუთვნის როგორც კომერციული საკითხი, და არა BGP პოლიტიკის სტრიქონს.
- დაასახელეთ პრეფიქსები, რომელთა შექმნაც თითოეულ მხარეს შეუძლია, და ისინი, რომლებიც მან არასოდეს უნდა მიიღოს.
- შეზღუდეთ MSS გვირაბზე და დაადასტურეთ, რომ დიდი განახლებები ნამდვილად მოდის.
- ჩამოთვალეთ ქვედა დონის საერთო დამოკიდებულებები, და არა გვირაბების რაოდენობა.
- გაზომეთ რეალური გაუქმება და აღნიშნეთ, რას აკეთებს აპლიკაცია.