Site-tot-site-VPN werk net een rigting: twee verskillende foute

Werf A bereik B, B kan nie A bereik nie, en die tonnel lyk in albei rigtings reg. Besluit watter fout jy werklik het voordat jy aan die tonnel raak. ’n Nuwe verbinding wat by B begin en geweier word, en ’n antwoord op ’n verbinding wat by A begin het en nooit aankom nie, lewer soortgelyke klagtes en heeltemal verskillende diagnoses. Een is ’n beleid- of roeteprobleem op die pad; die ander is ’n terugroete- of toestandprobleem vir verkeer wat reeds toegelaat is.

Die onderskeid bepaal watter opdragte die moeite werd is om te loop.

Twee foute wat identies lyk

In die eerste geval stuur B se gasheer ’n SYN na A, en niks kom terug nie. In die tweede open A se gasheer ’n sessie suksesvol en die antwoord verdwyn op pad terug. Albei gebruikers sê die skakel is eenrigting, en albei beskryf ’n pakket wat verdwyn het, so die beskrywing alleen kan hulle nie skei nie.

Vra watter kant die poging begin het wat misluk het. Daardie enkele feit verwyder die helfte van die moontlike oorsake.

Kontroleer dan dat die toets deurgaans dieselfde gashere en diens gebruik het. ’n Ping van een kant en ’n lêerdelingsverbinding van die ander kant toets twee verskillende dinge, en ’n diagnostiek vanuit die poort kan ’n tonneladres kies wat geen gebruikerverkeer ooit gebruik nie.

Geval een: die terugroete ontbreek

’n Afgeleë bediener wat op ’n ander verstekpoort antwoord, kan die versoek ontvang en die antwoord elders heen roeteer. Firewalls wat die toestand byhou, laat dan die asimmetriese antwoord val omdat dit nie by ’n gevestigde vloei pas nie, wat presies soos ’n rigting lyk wat nooit gewerk het nie. Vertaling voeg nog ’n weergawe by: die bestemming sien ’n vertaalde bron en antwoord daarop, so ’n reël wat vir die oorspronklike adres geskryf is, pas nooit nie.

Kontroleer die adres wat die bestemming werklik ná vertaling sien, en kontroleer die terugroete vir daardie adres eerder as vir die oorspronklike subnet.

Geval twee: die beleid het dit nooit toegelaat nie

Die teenoorgestelde geval is eenvoudiger en algemener as wat dit lyk: een kantoor is bedoel om ’n sentrale diens te gebruik en nooit verbindings na die sentrum te begin nie. Daardie asimmetrie is ’n doelbewuste toegangsbesluit, en die tonnel werk soos ontwerp. Lees die toegangsbeleid voordat jy enige tonnelinstelling verander. Die dokument, nie die pakketopname nie, sê watter rigting bedoel was. ’n Opname kan net wys wat gebeur het, nie wat gemagtig was nie.

As tweerigting-inisiasie werklik nodig is, voeg die spesifieke dienstoelating by deur die platform se ondersteunde reëlstel. Om elke subnet wedersyds vertrou te maak om een toepassing reg te maak, verander ’n smal vereiste in ’n breë toelating, en daardie ruil word selde daarna hersien.

Vergelyk voor en ná op dieselfde gashere

Kyk na albei kante van dieselfde poging, nie twee afsonderlike pogings nie. Neem op by die poort van die gasheer wat begin en by die bestemming, en vergelyk dan wat ingegaan het, wat uitgegaan het en watter adres die oorkant gesien het.

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

As die opname by die bestemming die versoek met ’n onverwagte bronadres wys, lê die antwoord in vertaling of roetering eerder as in die tonnel se sekuriteitsbeleid. As die bestemming glad geen versoek wys nie, het die pakket nooit die beskermde pad oorgesteek nie.

Herhaal ná ’n regstelling dieselfde toets vanaf dieselfde gasheer en bevestig dat onverwante toegang steeds geweier word. ’n Tonnelstatus van “established” ondersteun nie een van die twee gevolgtrekkings op sy eie nie.