Breek 'n VPN-kliënt op jou webbediener sy antwoorde?

Die webwerf laai vanaf 'n skootrekenaar op dieselfde netwerk en hou op reageer van enige ander plek, en die gasheer hardloop ook 'n VPN-kliënt vir sy eie uitgaande verkeer. Dié kombinasie veroorsaak 'n spesifieke fout: die inkomende verbinding kom aan, die antwoord verlaat die gasheer op die verkeerde pad, en die kliënt buite sien nooit 'n antwoord nie. Albei helftes verskyn in dieselfde pakketopname, so die volgorde van gebeure is die deel wat die moeite werd is om te lees.

'n Brongebaseerde roetereël herstel dikwels die simptoom. Dit maak gewoonlik ook meer verkeer vry as die webwerf wat dit gemotiveer het, en dit is die deel wat jy moet verstaan voordat jy die reël stoor.

Die simptoom: dit antwoord plaaslik en nie van buite nie

Binne die netwerk hoef die antwoord nie deur die tonnel te gaan nie, so die bladsy laai en die diens lyk gesond. Van buite bereik die versoek die gasheer en word die antwoord in die VPN ingeroeteer, waar die verre kant geen rede het om dit te aanvaar nie. Die blaaier sien 'n tydsverloop eerder as 'n weiering, wat die kenmerk is van 'n eenrigtingpad eerder as van 'n geslote poort.

Bevestig die vorm voordat jy roetering verander: die luisteraar is aan, die plaaslike versoek slaag, en die eksterne versoek lewer glad geen antwoord nie. Dié drie waarnemings dui saam op die terugpad eerder as op die webbediener se konfigurasie. So 'n skoon asimmetrie is nuttiger as enige logreël, want dit sluit die luisteraar uit voordat jy 'n enkele foutboodskap lees.

Hou 'n onafhanklike administrasiepad oop terwyl jy werk. 'n Reël wat jou eie SSH-sessie breek, verander 'n regstelling van tien minute in 'n fisiese besoek.

Wat 'n bronkeurder werklik pas

In Linux-beleidsroetering pas 'n reël soos from 192.168.50.2 pakkette wie se bron daardie adres is. Dit kodifiseer nie die feit dat die pakket 'n gesprek voortsit wat deur die tuisroeteerder binnegekom het nie, en dit weet nie watter proses dit geskep het nie. Die adres in daardie voorbeeld is illustratief; vervang dit met die adres wat jou gasheer werklik gebruik. Behandel die reël as 'n stelling oor adresse en niks meer nie.

As die gekose tabel 'n gewone verstekroete verskaf, kan elke pakket met daardie bron dieselfde uitsondering neem. 'n Ander diens wat aan dieselfde adres gebind is, erf dit, en 'n toepassing wat doelbewus aan daardie adres bind, erf dit ook. Die beleidsreëlverwysing lys bron, bestemming, protokol, poort, merk en prioriteit as afsonderlike keurders, wat 'n herinnering is dat die bron alleen die growste een is wat beskikbaar is.

Prioriteit bepaal die uitkoms. Opsoeke loop in volgorde en die eerste tabel wat 'n resultaat lewer, kan die soektog beëindig, so 'n reël wat te vroeg geplaas is, kan 'n meer spesifieke roete verberg wat 'n latere tabel sou verskaf het. Lees die hele geordende lys eerder as die enkele reël wat jy bygevoeg het. 'n Reël wat nooit pas nie, kos niks, terwyl een wat te vroeg pas, alles agter hom stilweg verander.

Kontroleer die terugpad en die verkeer wat jy nie bedoel het nie

Lees die reëls en die tabelle en vra dan die kernel watter roete 'n spesifieke bron- en bestemmingspaar sou neem. Om vanaf die gasheer self te toets is nie dieselfde as om van buite te toets nie, so doen albei.

ip rule show
ip route show table 100
ip route get 203.0.113.44 from 192.168.50.2
ss -ltnp '( sport = :443 )'

Aanvaar dan 'n nuwe eksterne verbinding en, afsonderlik, 'n versoek wat steeds deur die VPN moet vertrek. As die tweede een nou direk uitgaan, is die uitsondering wyer as die probleem wat jy opgelos het, en die toets wat saak maak, is die een wat jy nie bedoel het om te verander nie.

'n Openbare adreskontrole in 'n blaaier rapporteer net die versoeke wat daardie blaaier gemaak het. Dit sê niks oor die webbediener se antwoorde nie, oor 'n ander plaaslike toepassing se bronkeuse nie, of oor wat met bestuursverkeer gebeur ná die volgende VPN-herverbinding nie.

Bepaal hoe smal die uitsondering kan wees

Twee ontwerpe is verdedigbaar en hulle moet doelbewus gekies word. As die gasheer bestaan om hierdie diens te publiseer en sy uitgaande verkeer onbelangrik is, is 'n toegewyde plaaslike adres met 'n slegs-WAN-beleid 'n redelike reëling, mits jy die hele omvang aanvaar. As slegs bepaalde inkomende verbindings moet kwalifiseer, is adreskeuse te grof en hoort 'n verbindingsbewuste ontwerp voor dit.

Teken die kontrak aan waarop jy staatmaak: die openbare kartering, die gasheradres waarheen die versoek afgelewer word, en die pad wat die antwoord behoort te neem. 'n Inkomende diens wat deur 'n VPN-verskaffer gepubliseer word, is 'n ander kontrak as een wat deur 'n tuisroeteerder gepubliseer word, en 'n uitsondering wat uit een voorbeeld gekopieer is, is dikwels verkeerd vir die ander.

Bewaar die beleid in die komponent wat roetering besit eerder as om 'n opdrag in 'n beginlêer te plak. Reëlvolgorde, opruiming ná 'n netwerkverandering en herhaling ná 'n herbegin moet almal oorleef, en 'n ongetoetste beginlêer faal gewoonlik op die oomblik wanneer jy nie kyk nie. Eindig met die aanvaardingsresultaat wat jy kan verdedig: een gepubliseerde webwerf herstel en een onverwante vloei onveranderd.