Site-to-site VPN radi samo u jednom smjeru: dvije različite greške

Lokacija A doseže B, B ne može dosegnuti A, a tunel izgleda ispravno u oba smjera. Prije nego dirnete tunel, utvrdite koju grešku zaista imate. Nova veza pokrenuta na B koja biva odbijena i odgovor na vezu pokrenutu na A koji nikad ne stigne daju slične pritužbe i potpuno različite dijagnoze. Jedno je problem politike ili rute na putu; drugo je problem povratnog puta ili stanja za saobraćaj koji je već bio dozvoljen.

Ta razlika odlučuje koje naredbe vrijedi pokretati.

Dvije greške koje izgledaju isto

U prvom slučaju B-ov host šalje SYN na A i ništa se ne vraća. U drugom A-ov host uspješno otvara sesiju i odgovor nestaje na povratnom putu. Oba korisnika kažu da je veza jednosmjerna i oba opisuju paket koji je nestao, pa sam opis ne može razdvojiti ta dva slučaja.

Pitajte koja je strana pokrenula neuspjeli pokušaj. Ta jedna činjenica uklanja pola mogućih uzroka.

Zatim provjerite da je test cijelo vrijeme koristio iste hostove i istu uslugu. Ping s jedne strane i veza na dijeljeni folder s druge ispituju dvije različite stvari, a dijagnostika s mrežnog prolaza može odabrati adresu tunela koju nikakav korisnički saobraćaj ne koristi.

Prvi slučaj: povratni put nedostaje

Udaljeni server koji odgovara preko drugog zadanog mrežnog prolaza može primiti zahtjev i usmjeriti odgovor negdje drugdje. Vatrozidi koji prate stanje tada odbacuju asimetrični odgovor jer ne odgovara uspostavljenom toku, što izgleda upravo kao smjer koji nikad nije radio. Prijevod dodaje još jednu verziju: odredište vidi prevedenu izvorišnu adresu i odgovara na nju, pa pravilo napisano za izvornu adresu nikad ne odgovara.

Provjerite adresu koju odredište zaista vidi nakon prijevoda i povratnu rutu za tu adresu, a ne za izvornu podmrežu.

Drugi slučaj: politika to nikad nije dopuštala

Suprotan slučaj jednostavniji je i češći nego što izgleda: jedan ured treba koristiti centralnu uslugu i nikad ne pokretati veze prema centru. Ta asimetrija je namjerna odluka o pristupu i tunel radi kako je projektovan. Pročitajte politiku pristupa prije nego promijenite bilo koju postavku tunela. Koji je smjer bio namijenjen kaže dokument, a ne snimka paketa. Snimka može pokazati samo šta se dogodilo, ne šta je bilo odobreno.

Ako je dvosmjerno pokretanje zaista potrebno, dodajte dozvolu za konkretnu uslugu kroz podržani skup pravila platforme. Učiniti svaku podmrežu međusobno povjerljivom da bi se popravila jedna aplikacija pretvara uzak zahtjev u široku dozvolu, a ta razmjena se rijetko kasnije pregleda.

Uporedite prije i poslije na istim hostovima

Gledajte oba kraja istog pokušaja, a ne dva odvojena pokušaja. Snimajte na mrežnom prolazu hosta koji pokreće i na odredištu, pa uporedite šta je ušlo, šta je izašlo i koju je adresu vidjela dalja strana.

tcpdump -ni any host 10.20.30.40 and port 445
conntrack -L | grep 10.20.30.40
ip route get 10.20.30.40
swanctl --list-sas

Ako snimka na odredištu pokazuje zahtjev s neočekivanom izvorišnom adresom, odgovor je u prijevodu ili usmjeravanju, a ne u sigurnosnoj politici tunela. Ako odredište ne pokazuje nikakav zahtjev, paket nikad nije prešao zaštićeni put.

Nakon ispravke ponovite identičan test s identičnog hosta i potvrdite da je nepovezani pristup i dalje odbijen. Status tunela “established” sam po sebi ne podržava nijedan od dva zaključka.