Proširenje VPN lokacije: pratite povratnu rutu iza pristupnika

Saobraćaj iz podružnice završava na pristupniku čiji LAN ne sadrži aplikaciju kojoj ste trebali pristupiti. Server se nalazi u drugom data centru, preko interne veze koju VPN nikada nije konfigurisao. Dodavanje još jednog prefiksa bližem pristupniku ne čini ništa za taj slučaj, jer udaljeni pristupnik je tačka šifriranja, a ne posljednji ruter. Put zahtijeva rutu dalje, propuštanje na udaljenoj sigurnosnoj granici i odluku o povratku u samoj mreži odredišta.

Udaljeni pristupnik je tačka šifriranja

IPsec između pristupnika štiti saobraćaj između dva sigurnosna uređaja, a unutrašnje adrese putuju tim segmentom šifrovane. Iza udaljenog pristupnika preuzima obično rutiranje, uključujući bilo koju politiku koja postoji između data centara. Zaštićeni segment stoga pokriva dio putovanja, a ne ostatak. Pretpostaviti suprotno jeste način na koji dizajn završi sa zdravim tunelom i nedostupnom aplikacijom.

Nacrtajte put u tri dijela: podružnica do bližeg pristupnika, bliži do udaljenog pristupnika, udaljeni pristupnik do aplikacije. Svaki dio ima svog vlasnika i svoj način otkaza.

Pročitajte oba smjera politike tunela

Politika tunela obično se piše iz perspektive lokalne strane i upravo iz te navike dolaze djelimične konfiguracije. Oba partnera moraju navesti izvor podružnice i odredište onako kako će se pojaviti unutar tunela, uključujući svako prevođenje koje dizajn predviđa. Ažuriranje samo bližeg kraja proizvodi nesklad druge faze koji izgleda kao otkaz rutiranja. Uporedite dva skupa politika prije nego što dirnete bilo koju rutu.

Zapišite izvor i odredište kao adrese, a ne kao nazive lokacija. Dvosmislenost se ovdje kasnije vraća kao zbunjujuća asimetrija.

Dodajte rutu dalje i potvrdite propuštanje

Udaljenom pristupniku treba ruta prema podmreži aplikacije, a svaki ruter između njih mora propustiti izvor podružnice. Provjerite šta udaljeni pristupnik zaista ima, umjesto onoga što dijagram tvrdi.

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

Prva komanda prijavljuje izlazni interfejs i sljedeći skok koje bi udaljeni pristupnik odabrao za taj izvor, a to je pitanje na koje obična tabela rutiranja ne može odgovoriti. Trag pokazuje gdje se paketi zaustavljaju, a prekid nakon udaljenog pristupnika upućuje na unutrašnji tranzit, a ne na tunel. Kada ruta postoji, a saobraćaj ipak nestaje, snimite na udaljenom pristupniku i pročitajte dolaznu izvornu adresu, jer neočekivana adresa znači da se prevođenje odvija negdje neplanirano. Sve adrese ovdje su zamjenske, pa zamijenite stvarnim podmrežama podružnice, tranzita i aplikacije.

Testirajte iz podružnice, pa ponovo testirajte stari put

Prihvatanje traži stvarni izvor, a ne probu sa udaljenog pristupnika. Pokrenite provjeru sa hosta u podružnici i zadržite ranije radna odredišta u istom testu.

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

Odgovor aplikacije dokazuje put naprijed i povratni put zajedno, dok ping na staro odredište dokazuje da promjena nije pokvarila ono što je već radilo. Zabilježite izvornu adresu koju aplikacija loguje, jer njena pravila pristupa i svaka povratna ruta moraju odgovarati toj vrijednosti. Gdje podružnica prevodi prije tunela, adresa u politici i adresa koju aplikacija vidi razlikuju se po dizajnu, pa zabilježite obje. Ponovite test nakon obnavljanja ključa ili promjene rutiranja, jer se ti putevi obično validiraju jednom i zatim zaborave.

Dodijelite vlasnika svakom od tri segmenta i povratnoj ruti unutar mreže odredišta. Put sa četiri vlasnika pada u prazninama između njih.