Extinderea site-ului VPN: urmați ruta de întoarcere dincolo de poartă

Traficul dintr-o sucursală se termină pe o poartă al cărei LAN nu conține aplicația la care trebuia să ajungeți. Serverul se află într-un al doilea centru de date, dincolo de o legătură internă pe care VPN-ul nu a configurat-o niciodată. Adăugarea unui alt prefix pe poarta apropiată nu face nimic pentru acel caz, pentru că poarta îndepărtată este un punct final de criptare, nu ultimul router. Calea are nevoie de o rută înainte, de o admitere la granița de securitate îndepărtată și de o decizie de întoarcere în chiar rețeaua destinației.

Poarta îndepărtată este un punct final de criptare

IPsec între porți protejează traficul dintre două dispozitive de securitate, iar adresele interne călătoresc criptat prin acel segment. Dincolo de poarta îndepărtată preia rutarea obișnuită, inclusiv orice politică existentă între centrele de date. Segmentul protejat acoperă deci o parte a călătoriei, nu restul. A presupune contrariul este modul în care un proiect ajunge cu un tunel sănătos și o aplicație inaccesibilă.

Desenați calea în trei părți: sucursală la poarta apropiată, apropiată la îndepărtată, îndepărtată la aplicație. Fiecare parte are propriul proprietar și propriul mod de eșec.

Citiți ambele direcții ale politicii tunelului

O politică de tunel este de obicei scrisă din perspectiva părții locale, iar din acest obicei provin configurațiile parțiale. Ambele părți trebuie să listeze sursa sucursalei și destinația așa cum vor apărea în interiorul tunelului, inclusiv orice traducere pe care proiectul o intenționează. Actualizarea doar a capătului apropiat produce o nepotrivire de faza a doua care arată ca o defecțiune de rutare. Comparați cele două seturi de politici înainte de a atinge orice rută.

Scrieți sursa și destinația ca adrese, nu ca nume de site. Ambiguitatea de aici reapare mai târziu ca o asimetrie derutantă.

Adăugați ruta înainte și confirmați admiterea

Poarta îndepărtată are nevoie de o rută către subrețeaua aplicației, iar fiecare router dintre ele trebuie să admită sursa sucursalei. Verificați ce are de fapt poarta îndepărtată, în loc de ce susține diagrama.

ip route get 10.30.5.10 from 10.10.1.50
traceroute -n -s 10.10.1.50 10.30.5.10

Prima comandă raportează interfața de ieșire și următorul salt pe care poarta îndepărtată le-ar alege pentru acea sursă, o întrebare la care un tabel de rutare obișnuit nu poate răspunde. Trasarea arată unde se opresc pachetele, iar o întrerupere după poarta îndepărtată indică tranzit intern, nu tunelul. Când ruta există și traficul tot dispare, capturați pe poarta îndepărtată și citiți adresa sursă care sosește, pentru că o adresă neașteptată înseamnă că traducerea are loc undeva neplanificat. Toate adresele de aici sunt substituenți, așa că înlocuiți-le cu subrețelele reale de sucursală, tranzit și aplicație.

Testați din sucursală, apoi retestați vechea cale

Acceptarea are nevoie de o sursă reală, nu de o sondă de la poarta îndepărtată. Rulați verificarea de pe un host din sucursală și păstrați destinațiile care funcționau deja în același test.

curl -sS -m 5 http://10.30.5.10:8080/health
ping -c 3 10.20.1.1

Un răspuns de la aplicație dovedește împreună calea înainte și calea de întoarcere, în timp ce ping-ul către destinația veche dovedește că schimbarea nu a stricat ce funcționa deja. Înregistrați adresa sursă pe care o notează aplicația, pentru că regulile sale de acces și orice rută de întoarcere trebuie să corespundă acelei valori. Acolo unde sucursala traduce înainte de tunel, adresa din politică și adresa pe care o vede aplicația diferă prin proiectare, așa că notați-le pe amândouă. Repetați testul după o reînnoire a cheii sau o schimbare de rutare, pentru că aceste căi sunt de obicei validate o dată și apoi uitate.

Atribuiți un proprietar fiecăruia dintre cele trei segmente și rutei de întoarcere din interiorul rețelei destinației. O cale cu patru proprietari eșuează în golurile dintre ei.